Re: 3DES key-length for data authentication

Quoting Hari-Isoft (hari@isofttechindia.com):

> I would like to know the key-length used for 3DES data encryption in
> openssh. I thought that it should be 192 (3 * 64) bits, but the sshd
> man page states 128 bit key used for 3DES.

An old set of notes I have says single DES starts out with 64-bit keys, but it's 56-bit when you account for the parity bit. Thus the raw key-length of 3DES is 56 * 3 = 168 bit. The _effective_ length as implemented (3DES-CBC algorithm?) may be less: Maybe one of the real crypto people will comment.

> Also, I am interested in the export regulations concerning openssh in USA.

Quoting from a post I made elsewhere on that subject, two years ago:

---<snip>---

The January [2000] regulations were semi-clued in an interesting manner. Quoting the revision to Export Administration Regulations published in the January 14, 2000 _Federal Register_ (Vol. 65, No. 10, page 2492):

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

  Also in section 740.13, to, in part, take into account the "open   source" approach to software development, unrestricted encryption   source code not subject to an express agreement for the payment of   a licensing fee or royalty for commercial production or sale of any   product developed using the source code can, without preview, be   released from "EI" [encryption items] controls and exported and   re-exported under License Exception TSU. Intellectual property   protection (e.g., copyright, patent, or trademark) would not, by   itself, be construed as an express agreement for the payment of   a licensing fee or royalty for commercial production or sale of any   product developed using the source code. To qualify, exporters   must notify BXA [Bureau of Export Administration] of the Internet   location (e.g., URL or Internet address) or provide a copy of the   source code by the time of export. These notifications are only   required for the initial export; there are no notification   requirements for end-users subsequently using the source code.   Notification can be made by e-mail to crypt@bxa.doc.gov . [...]

This is at http://www.bxa.doc.gov/Encryption/regs.htm .

Cryptographer Matt Blaze has set up a remailer alias at "exports@crypto.com". Anyone wanting to send the BXA notice under "15 CFR Part 734, as revised on January 14, 2000" is invited to use that alias, which auto-appends your text to a public archive of such posts at http://www.crypto.com/exports/, in addition to sending them to the BXA.

Just for fun, I have my own alias, "nsa@linuxmafia.com", which remails to Blaze's alias. Pro bono publico.

---<snip>---

And from a note I wrote to Rolf Braun, author of Better Telnet for MacOS (whose beta supports SSH):

---<snip>---

http://www.bxa.doc.gov/Encryption/EncryptionRuleOct2K.html or http://www.bxa.doc.gov/Encryption/pdfs/EncryptionRuleOct2K.pdf has the text of the Oct. 19 regulation revision, which amends Sec. 740.13 covering the TSU (Technology and Software Unrestricted) exception to EI (encryption items) export controls. The new addition says that, if a codebase's source code meets the provisions of the TSU exception -- no fee or payment required other than resaonable and customary fees for reproduction and distribution, and crypt@bxa.doc.gov has been notified about the planned public availability -- then object code compiled from that source code may be exported under the same terms.

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

IANAL, but I estimate as you do that your SSH-enabled BetterTelnet source code qualifies for exception BXA (given notification to the crypt e-mail address). Therefore, your binary code does likewise. Which I believe clears the last obstacle out of your way.

If you give e-mail notice to BXA, I'd urge you to do so through Matt Blaze's mechanism for same. It's explained at http://www.crypto.com/exports/ .

---<snip>---

Again, I am not a lawyer, and this message is not legal advice. Businesses contemplating export of strong cryptographic code under the TSU exception to EI export controls should consult competent legal counsel. For one thing, the regulatory category that BXA considers to apply to you may depend on matters external to the nature of your code, e.g., what sort of business you are. I can't predict what these considerations might be, but a good attorney presumably could.

-- 
Cheers,                        Open-source SourceForge retakes the lead:
Rick Moen                      
http://gforge.org/  Thank you, Tim Perdue.
rick@linuxmafia.com