Re: Columbia crypto box
On Sun, Mar 02, 2003 at 11:32:36AM -0800, [EMAIL PROTECTED] wrote: Interestingly enough, the public references long ago published the shuttle comm frequencies. Summarizing from: The frequencies have never been secret, but in recent years some or perhaps even almost all of the Ku band TDRSS relayed telemetry and TV and a good bit of the S band relayed traffic has been encrypted. This was, I have been given to understand, part of the upgrades to the comms and TV systems on the shuttle completed in the last few years which converted analog TV transmission to digital TV. This encryption was originally publicly justified in part on the grounds that medical information was passed between crew and physicians on the ground and that federal privacy laws required protection of this information. And as far as I know, NASA while publishing link frequencies (which I have no particular reason to believe are wrong), has never released full details of modulation, multiplexing, error correction coding, randomization, interleaving, frame sync formats, channel assignments and scale factors for the data even for those links and modes that aren't encrypted. And actual link frequencies are but a small part of the data base of information one would need to successfully intercept useful information from the shuttle links - even 1980s to early-90s era digital telemetry signals are pretty complex and non trivial to deal with even if you know the frequency. Finally, the TDRSS spacecraft are also used for relaying information from NRO spacecraft and other classified military missions, and there is a significant chance that at least some of the details of the access protocols and signal formats used with these spacecraft are classified in order to protect sensitive military links. -- Dave Emery N1PRE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass. PGP fingerprint = 2047/4D7B08D1 DE 6E E1 CC 1F 1D 96 E2 5D 27 BD B0 24 88 C3 18 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Columbia crypto box
At 11:08 AM 02/13/2003 -0500, Trei, Peter wrote: Pete Chown[SMTP:[EMAIL PROTECTED]] As a footnote to those times, 2 ** 40 is 1,099,511,627,776. My PC can do 3,400,000 DES encryptions per second (according to openssl). I believe DES key setup is around the same cost as one encryption, so we should halve this if a different key is being used each time. Brute force of a 40-bit DES key will therefore take about a week. In other words 40-bit DES encryption is virtually useless, as brute force would be available to anyone with a modern PC. You can actually do much better that that for key set up. To toot my own horn, one of the critical events in getting software DES crackers running at high speed was my realization that single-bit-set key schedules can be OR'd together to produce any key's schedule. Combining this with the use of Grey Codes to choose the order in which keys were tested (Perry's idea) led to key scheduling taking about 5% of the time budget. But to further toot Peter's horn here (:-), before Peter's discovery, or maybe some work by Biham (?) around that time, at least as far as the public literature knew, DES key scheduling was substantially slower than the S-box phases of DES, so not only were general-purpose-computer attacks Moore'sLawfully slower, but add another factor of 10 or so, and customer hardware crackers would also need to burn resources on both parts of the algorithm and therefore take at least twice as much ASIC space unless extremely carefully managed. So while modern technology has made it severely useless, and while it was crippled back then, it was at least not _as_ crippled as it looks from today's viewpoint. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Columbia crypto box
Pete Chown[SMTP:[EMAIL PROTECTED]] Arnold G. Reinhold wrote: Indeed, but it is important to remember just how thickheaded the anti-crypto effort of the '80s and '90s was and how much damage it did. As a footnote to those times, 2 ** 40 is 1,099,511,627,776. My PC can do 3,400,000 DES encryptions per second (according to openssl). I believe DES key setup is around the same cost as one encryption, so we should halve this if a different key is being used each time. Brute force of a 40-bit DES key will therefore take about a week. In other words 40-bit DES encryption is virtually useless, as brute force would be available to anyone with a modern PC. -- Pete You can actually do much better that that for key set up. To toot my own horn, one of the critical events in getting software DES crackers running at high speed was my realization that single-bit-set key schedules can be OR'd together to produce any key's schedule. Combining this with the use of Grey Codes to choose the order in which keys were tested (Perry's idea) led to key scheduling taking about 5% of the time budget. Peter - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
At 10:43 PM 2/11/2003 -0800, Bill Frantz wrote: I wrote: (IIRC, basically what the device did was reveal 16 bits of a DES key.) It has been pointed out to me that they were even more clever than that. (This technique could allow a dictionary attack on known/probable plain text.) What they did instead was, take a 56 bit DES key through a one way function, zero certain bits so only 40 are variable, take the result through another one way function, and use the result as a DES key for encryption. For details see US patent 5,323,464: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2Sect2=HITOFFp=1u=/netahtml/search-bool.htmlr=47f=Gl=50co1=ANDd=ptxts1=Matyas.INZZ.OS=IN/MatyasRS=IN/Matyas This *still* allows a dictionary attack; in fact, it allows a more powerful one than revealing 16 bits of the key does. If you just reveal 16 bits of the key, then an adversary either needs to store 2^56 dictionary entries, or enumerate 2^40 keys. If you do as CDMF does, there are effectively only 2^40 possible 56-bit keys; these can be precomputed and stored on eg. tape. (7.5 terabytes, well within tape library range 10 years ago.) So you can *still* brute force the keys just as easily, noting that all this really does is avoid two hash function invokations per key. More, though, you can now compute and store (in comparable tape space) the dictionary, so CDMF *does* allow a precomputed dictionary attack that requires only storage for 2^40 dictionary entries (whatever size they are). So CDMF isn't that neat, really... Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/ Gladesville NSW 2111232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Columbia crypto box
Arnold G. Reinhold[SMTP:[EMAIL PROTECTED]] wrote: It's worth remembering that the original WEP used 40 bit keys. For some time, RC4 with 40 bit keys was the only crypto system that could be exported without a license. It's hard for me to believe that export concerns were not the primary factor in the initial choice of RC4. Arnold Reinhold If I recall correctly (dee3: Can you help?) WEP is actually derived from the encryption system used in the Apple Mobile Messaging System, a PCMCIA paging card made for the Newton in the mid-90s. This used 40 bit RC4. Though only a few years have passed, it's difficult to remember now what an encumberance the ITAR export regulations were. Essentially, there was a (very short) list of ciphers and modes you could export. 40-bit RC4 was relatively easy to export. Anything better,or anything which had not been already approved by the NSA, faced a bureaucratic nightmare and huge delays if it was approved at all. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
In message [EMAIL PROTECTED] m, Trei, Peter writes: If I recall correctly (dee3: Can you help?) WEP is actually derived from the encryption system used in the Apple Mobile Messaging System, a PCMCIA paging card made for the Newton in the mid-90s. This used 40 bit RC4. Though only a few years have passed, it's difficult to remember now what an encumberance the ITAR export regulations were. Essentially, there was a (very short) list of ciphers and modes you could export. 40-bit RC4 was relatively easy to export. Anything better,or anything which had not been already approved by the NSA, faced a bureaucratic nightmare and huge delays if it was approved at all. The 40-bit issue is orthogonal to the other problems with WEP. Look at IBM's Commercial Data Masking Facility (CDMF), a way to degrade the strength of DES from 56 bits to 40 bits, while still ensuring that they didn't enable any less-expensive attack. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Columbia crypto box
Steven M. Bellovin[SMTP:[EMAIL PROTECTED]] wrote: In message [EMAIL PROTECTED] m, Trei, Peter writes: If I recall correctly (dee3: Can you help?) WEP is actually derived from the encryption system used in the Apple Mobile Messaging System, a PCMCIA paging card made for the Newton in the mid-90s. This used 40 bit RC4. Though only a few years have passed, it's difficult to remember now what an encumberance the ITAR export regulations were. Essentially, there was a (very short) list of ciphers and modes you could export. 40-bit RC4 was relatively easy to export. Anything better,or anything which had not been already approved by the NSA, faced a bureaucratic nightmare and huge delays if it was approved at all. The 40-bit issue is orthogonal to the other problems with WEP. Look at IBM's Commercial Data Masking Facility (CDMF), a way to degrade the strength of DES from 56 bits to 40 bits, while still ensuring that they didn't enable any less-expensive attack. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) I totally agree that WEP has/had problems well beyond the export issue, but that's not my point. A product which cannot be exported will not be developed, generally speaking. I quote from AC2 (Schneier), page 615 (which was published in 1996): The State Department does not approve of the export of products with strong encryption, even those using DES. [...] The Software Publishers Association (SPA) has been negotiating with the government to ease export license restrictions. A 1992 agreement between them and the State Department eased the export license rules for two algorithms, RC2 and RC4, as long as the key size is 40 bits or less. So, it doesn't matter how espionage-enabled CDMF was, if you wanted to export crypto for general use, you were stuck with RC2 or RC4. This situation eased slightly (to 56 bits) around 1997, but did not reach today's conditions until 2000. The AMMS system cited above dates to 1995. (It feels weird to be citing Schneier as a historical document). Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
At 7:40 AM -0800 2/11/03, Steven M. Bellovin wrote: The 40-bit issue is orthogonal to the other problems with WEP. Look at IBM's Commercial Data Masking Facility (CDMF), a way to degrade the strength of DES from 56 bits to 40 bits, while still ensuring that they didn't enable any less-expensive attack. I have a lot of respect for the way IBM dealt with ITAR in this device. Note that they did not call it secure, they called it the Commercial Data Masking Facility, and did not advertise it as secure against NSA level attackers. As Steven says, the most effective attack is exhaustive search through the 40 bit key space. (IIRC, basically what the device did was reveal 16 bits of a DES key.) Cheers - Bill - Bill Frantz | Due process for all| Periwinkle -- Consulting (408)356-8506 | used to be the Ameican | 16345 Englewood Ave. [EMAIL PROTECTED] | way. | Los Gatos, CA 95032, USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
In message [EMAIL PROTECTED], Pete Chown writes: Bill Stewart wrote: These days nobody *has* a better cryptosystem than you do They might have a cheaper one or a faster one, but for ten years the public's been able to get free planet-sized-computer-proof crypto ... I seem to remember that the Nazis said the same thing about Enigma. Even when evidence began to filter back that it had been broken, they ignored it because they were so confident that a break was impossible. It's true that protocol and programming problems account for the huge majority of security holes. The WEP break, though, was one notable exception. They were using an established cryptosystem (RC4) with a planet sized key (128 bits). However, a weakness in RC4 itself let them down. Actually, that's missing the point. Yes, the cryptanalytic attack on RC4, especially as it's used in WEP, was impressive. But that attack was the least important problem with WEP -- the more serious problems were protocol issues. First, there was no key management. This means that loss of a single unit -- a stolen laptop or a disgruntled (ex-)employee would do -- compromises the entire network, since it's impossible to rekey everything at once in an organization of any size. For most real-world deployments, this is the most serious weakness. Furthermore, if there were real key management, the next two problems couldn't have happened. This was clearly avoidable. The second most serious problem was the set of problems documented by Borisov et al. at Berkeley. These mostly relied on the inappropriate use of a stream cipher, especially with too short an IV. Note that if it were possible to rekey before 2^24 packets were sent under any one key, the attacks mostly wouldn't be possible. The cryptanalytic attack did exploit an unforeseen weakness in RC4. But the attack was a related-key attack, and it required a noticeable amount of traffic. If rekeying had taken place, or if the IV were properly mixed with the seed key, there wouldn't have been a problem here. To be sure, Enigma was largely broken because it wasn't being used properly. As you say, protocol issues are the leading cause of crypto holes. (And, as you note, programming bugs account for *far* more real-world security problems.) --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
While I'm not claiming RC4 is strong, the main problem is that WEP misuses it. At I understand it, the recommendation for a long time has been that you either throw away the first 256 bytes of stream key output or use a different key on every message. WEP does neither. TKIP, the new security mode for 802.11 designed for feeble legacy hardware, still uses RC4 but does change keys on every message. Thanks, Donald == Donald E. Eastlake 3rd [EMAIL PROTECTED] 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA [EMAIL PROTECTED] On Sun, 9 Feb 2003, Pete Chown wrote: Date: Sun, 09 Feb 2003 13:51:07 + From: Pete Chown [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Columbia crypto box Bill Stewart wrote: These days nobody *has* a better cryptosystem than you do They might have a cheaper one or a faster one, but for ten years the public's been able to get free planet-sized-computer-proof crypto ... I seem to remember that the Nazis said the same thing about Enigma. Even when evidence began to filter back that it had been broken, they ignored it because they were so confident that a break was impossible. It's true that protocol and programming problems account for the huge majority of security holes. The WEP break, though, was one notable exception. They were using an established cryptosystem (RC4) with a planet sized key (128 bits). However, a weakness in RC4 itself let them down. ... if you don't like it, you can switch from 3DES and 1024-bit RSA to 5DES and/or 4096-bit RSA. I don't know about 4096-bit, but you should switch to something if you care about security; recent results imply that it may be possible to factor 1024-bit numbers. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
Pete Chown [EMAIL PROTECTED] writes: Bill Stewart wrote: These days nobody *has* a better cryptosystem than you do They might have a cheaper one or a faster one, but for ten years the public's been able to get free planet-sized-computer-proof crypto ... I seem to remember that the Nazis said the same thing about Enigma. Even when evidence began to filter back that it had been broken, they ignored it because they were so confident that a break was impossible. It's true that protocol and programming problems account for the huge majority of security holes. The WEP break, though, was one notable exception. They were using an established cryptosystem (RC4) with a planet sized key (128 bits). However, a weakness in RC4 itself let them down. This isn't 100% true. There were known (less practical but still better than just theoretical) attacks on RC4 as used in WEP even before the RC4 weak key work. WEP was a bad design through and through. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
On Sun, Feb 09, 2003 at 11:34:01PM -0500, Steven M. Bellovin wrote: First, there was no key management. This means that loss of a single unit -- a stolen laptop or a disgruntled (ex-)employee would do -- compromises the entire network, since it's impossible to rekey everything at once in an organization of any size. For most real-world deployments, this is the most serious weakness. Furthermore, if there were real key management, the next two problems couldn't have happened. This was clearly avoidable. Practically, what's the right way to do this? You could do it with a centralized server key that has the ability to broadcast a new shared key to all clients, but then if the server gets compromised you lose control of the entire network (possibly true anyway, for different reasons). From my personal (limited) experience, key management is really hard. I'm curious about potential solutions to this. -- - Adam - Adam Fields, Managing Partner, [EMAIL PROTECTED] Surgam, Inc. is a technology consulting firm with strong background in delivering scalable and robust enterprise web and IT applications. http://www.adamfields.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
On Sun, Feb 09, 2003 at 11:43:55PM -0500, Donald Eastlake 3rd wrote: been that you either throw away the first 256 bytes of stream key output or use a different key on every message. WEP does neither. TKIP, the new You NEVER, EVER, re-use the key for a stream cipher, if you do, you might as well just give up. By re-using the key, I can get plaintext (combinator) plaintext, which is easier to solve than plaintext (combinator) cipherstream. It's one of those things, like re-using a pad. MBM -- Matthew Byng-Maddick [EMAIL PROTECTED] http://colondot.net/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Columbia crypto box
Matthew Byng-Maddick[SMTP:[EMAIL PROTECTED]] writes: On Sun, Feb 09, 2003 at 11:43:55PM -0500, Donald Eastlake 3rd wrote: been that you either throw away the first 256 bytes of stream key output or use a different key on every message. WEP does neither. TKIP, the new You NEVER, EVER, re-use the key for a stream cipher, if you do, you might as well just give up. By re-using the key, I can get plaintext (combinator) plaintext, which is easier to solve than plaintext (combinator) cipherstream. It's one of those things, like re-using a pad. MBM The weird thing about WEP was its choice of cipher. It used RC4, a stream cipher, and re-keyed for every block. . RC4 is not really intended for this application. Today we'd have used a block cipher with varying IVs if neccessary I suspect that RC4 was chosen for other reasons - ease of export, smallness of code, or something like that. It runs fast, but rekeying every block loses most of that advantage. Just my personal musings Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
In message [EMAIL PROTECTED], bear writ es: It's one of those things, like re-using a pad. Actually, it is re-using a pad, exactly. It's just a pseudorandom pad (stream cipher) instead of a one-time pad. And while WEP had problems, it didn't have that particular problem. New messages with the same key would use a later chunk of the cipherstream pad under WEP. That's not correct. Each packet is encrypted with a key consisting of basekey,IV, where IV is a 24-bit counter. It does not use a later part of the stream; each packet starts from the beginning. Note that with a 24-bit key, plus the difficulty of changing the key, there *will* be reuse. It's compounded because (a) everyone has the same key, so there's lots of traffic; (b) both directions use the same key; and (c) some units, when power-cycled, always start the IV at 0, making collisions in that space more likely. Read the Borisov et al. paper for more details on all of these points and more. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
Trei, Peter wrote: The weird thing about WEP was its choice of cipher. It used RC4, a stream cipher, and re-keyed for every block. . RC4 is not really intended for this application. Today we'd have used a block cipher with varying IVs if neccessary I suspect that RC4 was chosen for other reasons - ease of export, smallness of code, or something like that. It runs fast, but rekeying every block loses most of that advantage. It's hard to believe that RC4 was chosen for technical reasons. The huge cost of key setup per packet (equivalent to generating 256 bytes of keystream and then throwing it away) should dominate the other potential advantages of RC4. In any case, WEP would clearly look very different if it had been designed by cryptographers, and it almost certainly wouldn't use RC4. Look at CCMP, for instance: it is 802.11i's chosen successor to, and re-design of, WEP. CCMP uses AES, not RC4, and I think that was a smart move. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
In message b295ds$l66$[EMAIL PROTECTED], David Wagner writes: Trei, Peter wrote: The weird thing about WEP was its choice of cipher. It used RC4, a stream cipher, and re-keyed for every block. . RC4 is not really intended for this application. Today we'd have used a block cipher with varying IVs if neccessary I suspect that RC4 was chosen for other reasons - ease of export, smallness of code, or something like that. It runs fast, but rekeying every block loses most of that advantage. It's hard to believe that RC4 was chosen for technical reasons. The huge cost of key setup per packet (equivalent to generating 256 bytes of keystream and then throwing it away) should dominate the other potential advantages of RC4. I'm not sure you're right. While 40-50% of packets are about 40 bytes long -- see http://www.nlanr.net/NA/Learn/packetsizes.html for some older statistics -- most *bytes* are carried by larger packets. From that same site, about 75% of the bytes are carried by packets over 500 bytes long. A quick awk script suggests that given that packet size distribution, the total workload to use WEP-style encryption is about double the number of bytes. The overhead is thus substantial -- but RC4's cost per byte is quite low, so it was probably a net win. Other studies suggest that LAN packet size distribution is somewhat different, with more large packets; that would lower the overhead. Note that the traffic mix on the Internet has shifted since that data was collected. Audio and video files are large, and hence will use more large packets; that again would lower the overhead. What's unclear is to what extent wireless device traffic differs. Given the increasing deployment of 802.11 in the home, I suspect that there's a lot of big files going to wireless endpoints. In any case, WEP would clearly look very different if it had been designed by cryptographers, and it almost certainly wouldn't use RC4. Look at CCMP, for instance: it is 802.11i's chosen successor to, and re-design of, WEP. CCMP uses AES, not RC4, and I think that was a smart move. A block cipher is clearly a better choice here. But there were some rational reasons for selecting RC4 (even though I think that on balance, the choice was very wrong). --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
At 1:26 PM -0800 2/10/03, David Wagner wrote: It's hard to believe that RC4 was chosen for technical reasons. The huge cost of key setup per packet (equivalent to generating 256 bytes of keystream and then throwing it away) should dominate the other potential advantages of RC4. The technical reasons people might chose RC4 for an embedded application like 802.11 WEP include: * Code size so close to zero as to make no never mind. * Intermediate data size so close to zero as to make no never mind. * Fast key setup (Forget tossing the 256 bytes of key stream. The designers weren't crypto engineers. Personally, I'd toss the first 1024.) * Fast encrypt/decrypt. * Commonly used in respected security applications (e.g. SSL). In any case, WEP would clearly look very different if it had been designed by cryptographers, and it almost certainly wouldn't use RC4. Look at CCMP, for instance: it is 802.11i's chosen successor to, and re-design of, WEP. CCMP uses AES, not RC4, and I think that was a smart move. I agree. WEP is what you get when you don't seek public review. Cheers - Bill - Bill Frantz | Due process for all| Periwinkle -- Consulting (408)356-8506 | used to be the Ameican | 16345 Englewood Ave. [EMAIL PROTECTED] | way. | Los Gatos, CA 95032, USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
At 4:29 PM -0800 2/10/03, Steven M. Bellovin wrote: In message v03110705ba6dec92ddb0@[192.168.1.5], Bill Frantz writes: * Fast key setup (Forget tossing the 256 bytes of key stream. The designers weren't crypto engineers. Personally, I'd toss the first 1024.) ... There may be a cryptographically sound reason to discard that much, but it's not without cost. The reason I would discard so much is that when I did some statistics on RC4 output, I kept getting distribution lumps out to about 1024. They made me worry about what someone who knew what were doing could do. Cheers - Bill - Bill Frantz | Due process for all| Periwinkle -- Consulting (408)356-8506 | used to be the Ameican | 16345 Englewood Ave. [EMAIL PROTECTED] | way. | Los Gatos, CA 95032, USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
In message v03110708ba6df9a4efb3@[192.168.1.5], Bill Frantz writes: At 4:29 PM -0800 2/10/03, Steven M. Bellovin wrote: In message v03110705ba6dec92ddb0@[192.168.1.5], Bill Frantz writes: * Fast key setup (Forget tossing the 256 bytes of key stream. The designers weren't crypto engineers. Personally, I'd toss the first 1024.) ... There may be a cryptographically sound reason to discard that much, but it's not without cost. The reason I would discard so much is that when I did some statistics on RC4 output, I kept getting distribution lumps out to about 1024. They made me worry about what someone who knew what were doing could do. That's a good reason... (At that point, even with older hardware, AES might be better -- and of course, using a block cipher solves lots of other problems, too...) --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
Bill Frantz writes: * Fast key setup (Forget tossing the 256 bytes of key stream. The designers weren't crypto engineers. Personally, I'd toss the first 1024.) Steven M. Bellovin wrote: There may be a cryptographically sound reason to discard that much, but it's not without cost. Bill Frantz wrote: The reason I would discard so much is that when I did some statistics on RC4 output, I kept getting distribution lumps out to about 1024. They made me worry about what someone who knew what were doing could do. See: Ilya Mironov (Stanford), (Not So) Random Shuffles of RC4 Advances in Cryptology - CRYPTO 2002 Proceedings, ed. by Moti Yung. Springer LNCS 2242, 2002. pp. 304-319. http://crypto.stanford.edu/~mironov/papers/rc4full.pdf Abstract. Most guidelines for implementation of the RC4 stream cipher recommend discarding the first 256 bytes of its output. This recommendation is based on the empirical fact that known attacks can either cryptanalyze RC4 starting at any point, or become harmless after these initial bytes are dumped. The motivation for this paper is to find a conservative estimate for the number of bytes that should be discarded in order to be safe. To this end we propose an idealized model of RC4 and analyze it apply- ing the theory of random shuffes. Based on our analysis of the model we recommend dumping at least 512 bytes. ... 7 Conclusion We identified a weakness in RC4 stemming from an imperfect shuffing algorithm used in the key scheduling phase and the pseudo-random number generator. The weakness is noticeable in the first byte but does not disappear until at least the third or the fourth pass (512 or 768 bytes away from the beginning of the output). ... Our most conservative recommendation ... means that discarding the initial 12 * 256 bytes most likely eliminates the possibility of a strong attack. Dumping several times more than 256 bytes from the output stream (twice or three times this number) appears to be just as reasonable a precaution. We recommend doing so in most applications. - - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
At 06:12 PM 2/10/2003 -0500, Steven M. Bellovin wrote: In any case, WEP would clearly look very different if it had been designed by cryptographers, and it almost certainly wouldn't use RC4. Look at CCMP, for instance: it is 802.11i's chosen successor to, and re-design of, WEP. CCMP uses AES, not RC4, and I think that was a smart move. A block cipher is clearly a better choice here. But there were some rational reasons for selecting RC4 (even though I think that on balance, the choice was very wrong). I agree that on balance, the implementation of RC4 for WEP was very wrong. But by your own numbers (and on the assumption that RC4 generates bytes twice as fast as AES and that the cost of keying is equivalent to generating 256 bytes) RC4 should win, computationally, on packets greater than 256 bytes. More modern stream ciphers such as SOBER-t32, SNOW2.0 and Turing, all of which explicitly support Initialisation Vectors to generate distinct streams, perform much better than AES for a job like this. I happen to have the numbers to hand for a comparison of my implementation of Turing vs. Brian Gladman's highly optimised AES (because the paper is being presented in two weeks at FSE), and computationally speaking Turing overtakes at about 100 bytes and generates bytes about 5 times faster from there on. SNOW2.0 overtakes almost straight away, and generates bytes about 3 times faster (haven't measured that myself, but I believe it). The combination of Turing for encryption and HMAC-SHA-1 for MAC outperforms AES even in OCB mode on my laptop. (Lest anyone ask, no, I'm not suggesting adopting Turing or SNOW2.0... they're too new. And I'm not trying to promote my own cipher particularly. But...) You said: A block cipher is clearly a better choice here. This is almost, for me, the canonical case for a stream cipher. What's clear to you isn't clear to me. Can you elucidate, please? regards, Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/ Gladesville NSW 2111232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
In message [EMAIL PROTECTED], Paul A.S. Ward writes: Is it really fair to blame WEP for not using AES when AES wasn't around when WEP was being created? Of course they couldn't have used AES. But there are other block ciphers they could have used. They could have used key management. They could have added a MAC. They could have used a longer IV field, with a random starting point mandated by the spec. Or they could have put a big warning on saying this doesn't protect you from very much. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
Bill Stewart wrote: These days nobody *has* a better cryptosystem than you do They might have a cheaper one or a faster one, but for ten years the public's been able to get free planet-sized-computer-proof crypto ... I seem to remember that the Nazis said the same thing about Enigma. Even when evidence began to filter back that it had been broken, they ignored it because they were so confident that a break was impossible. It's true that protocol and programming problems account for the huge majority of security holes. The WEP break, though, was one notable exception. They were using an established cryptosystem (RC4) with a planet sized key (128 bits). However, a weakness in RC4 itself let them down. ... if you don't like it, you can switch from 3DES and 1024-bit RSA to 5DES and/or 4096-bit RSA. I don't know about 4096-bit, but you should switch to something if you care about security; recent results imply that it may be possible to factor 1024-bit numbers. -- Pete - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Columbia crypto box
On Sat, 8 Feb 2003, Lucky Green wrote: In July of 1997, only days after the Mars Pathfinder mission and its Sojourner Rover successfully landed on Mars, I innocently inquired on the Cypherpunks mailing list if any subscribers happened to know if and how NASA authenticates the command uplink to what at the time was arguably the coolest RC toy in the solar system. ... Apparently, my original inquiry had been copied and forwarded several times. By the time my inquiry had reached the office of the President, just as in a children's' game of telephone, my question of are they using any decent crypto had turned in to hackers ready to take over Mars Rover. ... Needless to say and regardless of anyone's intent, such concern would be entirely unfounded if the uplink were securely authenticated. Which I believes represents an answer to my initial question as to whether the uplink is securely authenticated. Actually, I don't think it does. It's been my experience that the decision-makers never even *KNOW* whether their systems are secure. They've been sold snake-oil claims of security so many times, and, inevitably, seen those systems compromised, that even when responsible and knowledgeable engineers say a system is secure, they have to regard it as just another claim of the same type that's been proven false before. So I can easily imagine them just not knowing whether the link was secure, thinking that the NASA engineer's job of securing uplinks might be no better than Microsoft's job of securing communications or operating systems, because they've had it demonstrated time and again that even when they hear words like secure, the system can be compromised. The fact is that the NASA engineer has a huge advantage; s/he's not working for a marketing department that will toss security for convenience, s/he's not working on something whose code has to be copied a million times and distributed to people with debuggers all over the world, s/he's not trying to hide information from people on their own computer systems, and s/he's not complying with deals made with various people that require backdoors and transparency to law enforcement in every box. So the NASA engineer's actually got a chance of making something secure, where the Microsoft engineer didn't. Microsoft has to claim their junk is secure, but in their case it's just marketing gas. But all this is below the notice of the decision makers; they *LIVE* in a world where marketing gas is indistinguishable from reality, because they don't have the engineer's knowledge of the issues. So having the decision makers get real nervous was likely to happen, whether the link is secure or not. There's no information there except that the decision makers have finally realized they don't really *know* whether the link is secure. That's progress, of a sort. [Remind me to some time recount the tale of my discussing key management with the chief-cryptographer for a battlefield communication system considerably younger than the shuttle fleet. Appalling does not being to describe it]. Battlefield systems have been that way forever. Battlefield information only has to remain secure for a few seconds to a few hours, and they exploit that to the max in making the systems flexible and fast enough for actual use. You want appalling? In the civil war, they used monoalphabetic substitution as a trench code -- on both sides. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
John, Your snipe at NASA is probably uncalled for. A sentence fragment quoted from a spokesperson at press conference almost certainly does not reflect the professional judgment of the people who designed the system. As someone who is occasionally quoted (and just as often misquoted) in the press, I can imagine it was at least as likely that the question was why was encryption used? as why do you want the box back. To say nothing of the popular (and even technical) confusion between encryption and encoding. I can certainly imagine very good reasons that they'd want to keep the encoding and frequencies used to control the shuttle secret; if nothing else, to prevent denial of service. Do you really, honestly belive that none of the people designing a secure communication system for the shuttle were even remotely acquainted with the basic principles of the subject? Or did you just want to make a snide remark at the expense of people who are obviously now the subject of enormous scrutiny? One would think technologists would be wise enough not to assume too much about some sound byte without knowing its context, but personal experience suggests that a substantial number of us just jump at the chance to interpret everything we read in a 500 word article in the popular press as if it reflects the entire body of thought on some subject. For example, I got about a dozen email messages from people complaining about how I obviously advocate security through obscurity after something I wrote was slightly misquoted (in an otherwise carefully written article) as suggesting that people use keys that are hard to get blanks for. Almost everyone complaining had also read the source for that quote (which added a qualification that this is probably doesn't offer much protection), but that didn't matter. People want to believe what they read in the newspaper, even when they know the facts first hand. -matt As reported by AP: | Among the most important [debris] they were seeking was | a device that allows for the encryption of communication | between the shuttle and NASA controllers. A NASA spokesman | in Houston, John Ira Petty, said Friday that NASA feared | the technology could be used to send bogus signals to the | shuttle. Apparently some folks skipped class the day Kerchhoffs' Principle was covered. One wonders what other shuttle systems were designed with comparable disregard of basic principles. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
At 12:41 AM 2/8/2003 -0500, John S. Denker wrote: As reported by AP: | Among the most important [debris] they were seeking was | a device that allows for the encryption of communication | between the shuttle and NASA controllers. A NASA spokesman | in Houston, John Ira Petty, said Friday that NASA feared | the technology could be used to send bogus signals to the | shuttle. Apparently some folks skipped class the day Kerchhoffs' Principle was covered. Here are three valid reasons for NSA (who provides communication security to NASA) to keep crypto algorithms secret: 1. If one has a sufficiently good level of analysis in-house that additional cryptographic analysis has reached the level of diminishing returns, then there's little additional value to be gained from the community input resulting from disclosure. In such a situation, even if a cipher is secure enough to meet its goals based solely on secrecy of the key, the marginal security of keeping the algorithm secret is of value. 2. Keeping an algorithm secret prevents your opponents from using it. If you have better algorithms than your opponents, this is of value. 3. Keeping an algorithm secret may provide protection to design concepts and constraints, which will help you keep secret methods of cryptanalysis with which you are familiar, but that your opponents have not yet discovered (e.g. differential cryptanalysis). There may be more valid reasons for treating the device as secret; some categories that come to mind include protecting non-cryptographic information, such as the capabilities of the communication channel. Also, many systems on the shuttle are obsolete by modern standards, and it's possible that the communications security is similarly aged. - Tim Dierks - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
On Sat, Feb 08, 2003 at 01:24:14PM -0500, Tim Dierks wrote: There may be more valid reasons for treating the device as secret; some categories that come to mind include protecting non-cryptographic information, such as the capabilities of the communication channel. Also, many systems on the shuttle are obsolete by modern standards, and it's possible that the communications security is similarly aged. Isn't it also possible that the device contains a physical key of some kind? -- - Adam - Adam Fields, Managing Partner, [EMAIL PROTECTED] Surgam, Inc. is a technology consulting firm with strong background in delivering scalable and robust enterprise web and IT applications. http://www.adamfields.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
On Sat, Feb 08, 2003 at 01:36:46PM -0500, Adam Fields wrote: On Sat, Feb 08, 2003 at 01:24:14PM -0500, Tim Dierks wrote: There may be more valid reasons for treating the device as secret; some categories that come to mind include protecting non-cryptographic information, such as the capabilities of the communication channel. Also, many systems on the shuttle are obsolete by modern standards, and it's possible that the communications security is similarly aged. Isn't it also possible that the device contains a physical key of some kind? Right, which should be different for each vehicle/flight and if it is used for control of that particular vehicle/flight, is pretty moot now... Having said that, if there was sensitive content in those transmissions that was in addition to real-time control of the vehicle, there would be a significant interest in preventing others from acquiring it. This seems like a weakness of the system. - Adam slainte mhath, RGB -- Richard Guy Briggs --~\ Auto-Free Ottawa! Canada www.TriColour.net--\@ @ www.flora.org/afo/ No Internet Wiretapping!-- _\\/\%___\\/\%Vote! -- Green.ca www.FreeSWAN.org___GTVS6#790__(*)___(*)(*)___www.Marillion.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
Apparently some folks skipped class the day Kerchhoffs' Principle was covered. While this is obvious to the oldtimers, I had to look Kerkhoffs principle ( and found that it is the old injunction against security by obscurity ). So for the benefit of those who are as clueless as me: http://www.counterpane.com/crypto-gram-0205.html A basic rule of cryptography is to use published, public, algorithms and protocols. This principle was first stated in 1883 by Auguste Kerckhoffs: in a well-designed cryptographic system, only the key needs to be secret; there should be no secrecy in the algorithm. Modern cryptographers have embraced this principle, calling anything else security by obscurity. Any system that tries to keep its algorithms secret for security reasons is quickly dismissed by the community, and referred to as snake oil or even worse. This is true for cryptography, but the general relationship between secrecy and security is more complicated than Kerckhoffs' Principle indicates. The reasoning behind Kerckhoffs' Principle is compelling. If the cryptographic algorithm must remain secret in order for the system to be secure, then the system is less secure. The system is less secure, because security is affected if the algorithm falls into enemy hands. It's harder to set up different communications nets, because it would be necessary to change algorithms as well as keys. The resultant system is more fragile, simply because there are more secrets that need to be kept. In a well-designed system, only the key needs to be secret; in fact, everything else should be assumed to be public. Or, to put it another way, if the algorithm or protocol or implementation needs to be kept secret, then it is really part of the key and should be treated as such. Kerckhoffs' Principle doesn't speak to actual publication of the algorithms and protocols, just the requirement to make security independent of their secrecy. In Kerckhoffs' day, there wasn't a large cryptographic community that could analyze and critique cryptographic systems, so there wasn't much benefit in publication. Today, there is considerable benefit in publication, and there is even more benefit from using already published, already analyzed, designs of others. Keeping these designs secret is needless obscurity. Kerckhoffs' Principle says that there should be no security determent from publication; the modern cryptographic community demonstrates again and again that there is enormous benefit to publication. also see: http://www.cs.biu.ac.il/~herzbea/BIU656/index.html Kerckhoffs' principle: Do not assume secret designs and algorithms; only keys can be assumed secret. Kerckhoffs' original concern was that cryptosystems designed under the `security by obscurity' assumption, namely assuming that the adversary would not know their designs, might be easily exposed once the design is revealed. -- natsu-gusa ya / tsuwamono-domo-ga / yume no ato summer grasses / strong ones / dreams site Summer grasses, All that remains Of soldier's dreams (Basho trans. Stryk) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
On Sat, Feb 08, 2003 at 01:36:46PM -0500, Adam Fields wrote: On Sat, Feb 08, 2003 at 01:24:14PM -0500, Tim Dierks wrote: There may be more valid reasons for treating the device as secret; some categories that come to mind include protecting non-cryptographic information, such as the capabilities of the communication channel. Also, many systems on the shuttle are obsolete by modern standards, and it's possible that the communications security is similarly aged. Isn't it also possible that the device contains a physical key of some kind? Mom, can I borrow the keys to the Space Shuttle? From a cryptographic perspective, a physical key is just a ROM containing some bits, or else a smart-card containing some bits it doesn't tell you directly, but either way the only thing magic about the physical container is whether the operator needs to know the bits or not. These days nobody *has* a better cryptosystem than you do. They might have a cheaper one or a faster one, but for ten years the public's been able to get free planet-sized-computer-proof crypto, and if you don't like it, you can switch from 3DES and 1024-bit RSA to 5DES and/or 4096-bit RSA. That doesn't mean that the space shuttle has that quality crypto for its critical operational communications - its computers were antique compared to commercial-off-the-shelf-non-radiation-hardened-non-shock-proofed PCs, so it could be running on really lame 60s NSA hardware crypto. The tradeoff with that kind of equipment was using good key hygiene (doesn't matter too much if the key gets stolen as long as you know, and as long as you can wait for the guy with the briefcase handcuffed to his wrist), but also using Obscurity to make cryptanalysis difficult. So it's possible that they're running some crypto that's lame enough that if somebody recovers it, they'll be able to crack the algorithms, which might let them crack the keys for some other shuttle, or it's possible that it will let them learn enough about old NSA crypto and maybe the KGB can decode some old messages from somebody, which might still have some value to somebody (learning 60s/70s military tactics?) It'd be lame, but it's possible. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
On Sat, Feb 08, 2003 at 03:26:53PM -0800, Bill Stewart wrote: It'd be lame, but it's possible. It's probably just every-day insitutionalised paranoia. It doesn't matter why they care, the sticker on the outside says they have to. -- Dan. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Columbia crypto box
In message [EMAIL PROTECTED], Faust writes: Apparently some folks skipped class the day Kerchhoffs' Principle was covered. While this is obvious to the oldtimers, I had to look Kerkhoffs principle ( and found that it is the old injunction against security by obscurity ). You can find Kerchhoffs' original work at http://www.cl.cam.ac.uk/~fapp2/kerckhoffs , in French and English. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Columbia crypto box
Matt wrote quoting John: Do you really, honestly believe that none of the people designing a secure communication system for the shuttle were even remotely acquainted with the basic principles of the subject? [...] Apparently some folks skipped class the day Kerchhoffs' Principle was covered. One wonders what other shuttle systems were designed with comparable disregard of basic principles. Matt, Based on my experience, I would not be unreasonable to believe that such a disregard to basic security principles indeed took place. Case in point: In July of 1997, only days after the Mars Pathfinder mission and its Sojourner Rover successfully landed on Mars, I innocently inquired on the Cypherpunks mailing list if any subscribers happened to know if and how NASA authenticates the command uplink to what at the time was arguably the coolest RC toy in the solar system. A few days after my initial post, which yielded no substantial replies on the mailing list, I receive a call by a well-known security expert who at that time functioned as an advisor to the office of the President of the United States. Apparently, my original inquiry had been copied and forwarded several times. By the time my inquiry had reached the office of the President, just as in a children's' game of telephone, my question of are they using any decent crypto had turned in to hackers ready to take over Mars Rover. With Sojourner being the U.S. Government's PR darling of the day, the office of the President decided to dispatch the FBI to interdict me from engaging in such a nefarious deed. It was only through chance that the aforementioned advisor got wind of this releasing of the hounds and convinced the decision makers that I was just a harmless researcher who asked an innocent question rather than a threat to national PR objectives. Word has it that the folks in DC were buzzing with fear of what would happen to NASA's image if hackers were to take the Mars Rover for a spin. Needless to say and regardless of anyone's intent, such concern would be entirely unfounded if the uplink were securely authenticated. Which I believes represents an answer to my initial question as to whether the uplink is securely authenticated. Presumably NASA did a better job with the shuttle, but I would not be surprised in the least if all shuttles shared the same key. [Remind me to some time recount the tale of my discussing key management with the chief-cryptographer for a battlefield communication system considerably younger than the shuttle fleet. Appalling does not being to describe it]. --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
