Re: Proven Primes
Tom St Denis [EMAIL PROTECTED] has a program that constructs provable primes, by bootstrapping them from smaller proven primes. The trouble is that his stuff is off the air at the moment. You might write to him, though. It's pretty quick, IIRC. Greg. At 06:45 PM 3/8/2003 +, Ben Laurie wrote: Jack Lloyd wrote: I believe the IPSec primes had been proven. All are SG primes with a g=2 Check RFC 2412, draft-ietf-ipsec-ikev2-05.txt, and draft-ietf-ipsec-ike-modp-groups-05.txt However, I don't seen any primality proof certificates included in the texts. RFC 2412 looks good, however, as you say, no certificates are included, nor is it made clear that (p-1)/2 has been proven. I-Ds are less useful to me, since I can't give a long-term reference for them :-( Thanks! Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] 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]
Some good words needed...
After a long effort, I finally got agreement from my company to make our encryption algorithms freely available. (See http://www.qualcomm.com/press/pr/releases2003/press1161.html if you care.) Somewhat unexpectedly, we now have a number of queries saying basically That's unpatriotic, giving it away to the terrorists! Note that they were already *available* to them, it just wasn't free for all uses! So I guess it's unpatriotic to fail to make money from these terrible weapons. I won't even get into the issue of me being a furriner in the first place. Anyway. I'm perfectly capable of writing my own words on the subject, but I also know that they've been written many times before. What are people's favourite, succinct expressions of why it's OK to give away encryption algorithms? To keep the list uncluttered, I suggest people send me suggestions, and I'll compile, collate, and report back to the list. thanks and 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: AES-128 keys unique for fixed plaintext/ciphertext pair?
At 02:06 PM 2/17/2003 +0100, Ralf-Philipp Weinmann wrote: For each AES-128 plaintext/ciphertext (c,p) pair there exists exactly one key k such that c=AES-128-Encrypt(p, k). I'd be very surprised if this were true, and if it was, it might have bad implications for related key attacks and the use of AES for hashing/MACing. Basically, block encryption with a given key should form a pseudo-random permutation of its inputs, but encryption of a constant input with a varying key is usually expected to behave like a pseudo-random *function* instead. 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
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
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: Key Pair Agreement?
At 09:08 PM 1/20/2003 -0500, Radia Perlman - Boston Center for Networking wrote: I was going to suggest something similar to what David Wagner suggested, but with Scott telling Alice the modulus size and the *high* order 64 bits (with the top bit constrained to be 1). I can see how Alice can easily generate two primes whose product will have that *high* order part, but it seems hard to generate an RSA modulus with a specific *low* order 64 bits. This is the essence of the DEADBEEF attack on PGP. PGP used the least significant bits of the modulus as the key ID. If you want to create a key with a particular key ID, you just hack the code so that it checks for primes that end in things which will multiply together to yeild the desired answer; the easy case, of course, is 0x0001 and 0xDEADBEEF, which is what was done to create the Prime Rib Lovers' key as a proof of concept[*]. There does not appear to be any significant erosion of security, although I'm not sure if anyone's thought too seriously about that specific case either. regards, Greg. [*] I note that there are three keys on the us.pgp.net server with 0xDEADBEEF as their key ID (including the one mentioned above), and one of them is even a DSA key! I can only assume this was brute forced through the hash function. 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: Why is RMAC resistant to birthday attacks?
At 03:05 PM 10/22/2002 -0400, Wei Dai wrote: Call the Jan 21 document x, and the Sept 30 document y. Now Bob knows MAC_Alice(x | z) = MAC_Alice(y | z) for all z, because the internal states of the MAC after processing x and y are the same and therefore will remain equal given identical suffixes. So he can get a MAC on x | z and it's also a valid MAC for y | z, which Alice didn't sign. This applies for CBC-MAC, DMAC, HMAC, and any another MAC that is not randomized or maintains state (for example a counter) from message to message. A nit... this isn't *quite* true for HMAC; the collision could have been in the outer hash function evaluation, not the inner. I haven't yet looked at RMAC and don't know what DMAC is, so I can't comment on them. Still, the attack gives a 50% chance of forging an HMAC, so it's a valid attack. 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: [Bruce Schneier schneier@counterpane.com] CRYPTO-GRAM, October 15, 2002
At 10:47 PM 10/15/2002 -0400, Perry E. Metzger wrote: I can say with certainty that no one knows for certain if XLS can break I hate to point this out since it sounds like nitpicking, but it's eXtended Sparse Linearisation (XSL), not the spreadsheet XLS. 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: Optical analog computing?
At 01:30 AM 10/2/2002 -0400, John S. Denker wrote: R. A. Hettinga wrote: ... the first computer to crack enigma was optical 1) Bletchley Park used optical sensors, which were (and still are) the best way to read paper tape at high speed. You can read about it in the standard accounts, e.g. http://www.picotech.com/applications/colossus.html But Colossus was not for Enigma. The bombes used for Enigma were electro-mechanical. I'm not aware of any application of optical techniques to Enigma, unless they were done in the US and are still classified. And clearly, the first bulk breaks of Enigma were done by the bombes, so I guess it depends whether you count bombes as computers or not, whether this statement has any credibility at all. Greg. Williams/Zenon 2004 campaign page: http://www.ben4prez.org 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: RSA's RC5-64 Secret Key Challenge has been solved.
At 01:16 PM 9/27/2002 +0200, Ralf-P. Weinmann wrote: Is A5/3 deployed yet? Kasumi (in the form of f8 (ciphering) and f9 (integrity) is beginning to be deployed in UMTS (WidebandCDMA) mobiles as we speak. But an exact specification of how to use Kasumi as A5/3 has only just been agreed; it will be 6-12 months (at least) before any significant amount of equipment, either fixed or mobile, will be produced and deployed, and it will be a couple more years after that before there will be significant probability that a call is encrypted using A5/3. As for A5/3, I'm not really sure what key length network operators are/will be using, 64-128 bits are allowed in the design requirements documentation. The specification should be available on the 3GPP website. A5/3 is based on Kasumi. A5/3 will be stuck at 64 bit keys for the forseeable future, due to compatibility issues in the protocol. f8 and f9, on the other hand, already use 128-bit keys. 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: building a true RNG
At 03:18 PM 7/29/2002 -0700, David Wagner wrote: I don't even think anyone has analyzed the entropy preservation of a theoretically perfect random oracle Well, I know this particular point wasn't central to your email, but I'm not sure I agree with you on this small point. I believe it should be more or less straightforward to analyze the entropy preservation of a random oracle (alas, so straightforward you probably won't find any paper on it in the literature). Actually, it's covered very well (but briefly) in HAC (in section 2.1.6) and they refer to a seminal work by Flajolet and Odlyzko (Google finds references to it quite easily). 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: RSA getting rid of trusted third parties?
At 11:48 AM 6/21/2002 -0700, Ian Clelland wrote: The trust model doesn't break down just because anyone can create a valid X.509 certificate. There still has to be a valid chain of trust leading back to a trusted party (RSA, in this case). If that trust is abused, then RSA can revoke your cert and break the chain. a) it isn't clear to me that RSA would have the right to revoke the organisations certificate; maybe they build it into their license agreement. b) browsers *don't check* the revocation status on certificates, and the field that points to the server for the revocation list is almost never filled in anyway. 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]
Errors in FIPS 198 (HMAC)
Dear Jim, I wasn't sure who to email this comment to, but have met you a couple of times, so you're it. I trust you'll forward it as required. (To readers of the Cryptography mailing list: please consider Mr Foti if following up.) In the new FIPS 198 specifying HMAC, there is a typographical error in Appendix B which talks about truncating the output HMAC value. In the third paragraph it refers to the block size, b. However, the hash function has two block sizes, an input block size B and an output block size L, and the output of HMAC (before truncation) is of length L, not b or B. A naive reading of the appendix would have us use a minimum of 256 bits to truncate a 160-bit output (referring to SHA-1)! The text in the main body correctly uses L in this context. Also, the reference in Appendix A for SHA-1 is to RFC 2104, which I think is a bit strange given that there is a perfectly good FIPS (180-1) specifying SHA-1. In fact RFC2104 does not specify SHA-1 at all, itself referring to FIPS-180-1. The only example code in RFC2104 is for MD5. Lastly, FIPS-180-1 specifies that the output of SHA-1 is 5 32-bit words, and explicitly does *not* specify an ordering to the bytes of the output words, although common usage is that they should be treated as most-significant-byte-first as is done to create words from the input bytes. I believe that FIPS-198 should specify a word-to-byte-order, otherwise it is impossible to unambiguously truncate the 160-bit output to a size that is not a multiple of 32 bits. (Note: I actually consider this a deficiency in FIPS-180-1, but I assume that it would be preferable to add detail to a new FIPS than to update an old one.) regards, Greg. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: theory: unconditional security
At 10:15 PM 2/16/2002 +, Zefram wrote: I've not been able to find any paper that describes the use of this algorithm to give unconditional secrecy and integrity at once. Nor have I found any paper describing doing this (as MAC or as secrecy-plus-integrity) in GF(2^n), which makes it convenient to operate on bit strings. This seems so stunningly useful that I'm surprised it's not mentioned in AC. Like One-Time Pads, it seems stunningly useful only until you consider the practicalities. You still need key material as long as (in fact, twice as long as) the message, and you still cannot ever reuse the key material. Can anyone point me at references that I'm missing? The sci.crypt FAQ has some material about why OTPs are useless in practice, and might have some references. 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: Welome to the Internet, here's your private key
At 05:55 AM 2/7/2002 +1300, Peter Gutmann wrote: Greg Rose [EMAIL PROTECTED] writes: While priming the RC4 table, I accidentally filled the data buffer instead (D'oh!) with consecutive byte values 0x00, 0x01, ... 0xFF, 0x00, ... This very much passes the FIPS 140 tests for randomness, despite being nothing like it: A generic order-0 entropy estimator (think Huffman coder) will pass this, because each symbol occurs with equal probability. The reason this is a problem is because any introductory information theory text will give the standard formula for entropy estimation (H = -sum(prob(x) * log( prob(x and users will either stop reading there or the text won't go any further. But it is interesting that, had the FIPS test worked on a multiple of 256 bytes, it would have caught it, because it uses a two-sided ChiSquare test. In other words, perfect frequency distribution (of nybbles) is also something it will reject... but it wasn't perfect because a sequence stopped early. 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: Welome to the Internet, here's your private key
And if the runs test in FIPS were slightly extended, your sequence of consecutive 8-bit numbers would have been easily caught too. Here's the full spectrum of runs for your sequence: Run-length # of gaps # of blocks == = === 1 24972529 2 12521255 3 628 621 4 317 307 5 159 152 6 80 75 7 70 0 8 0 74 9-14 0 0 1510 0 16 and up 0 0 That there are 70 gaps of length exactly 7 but no blocks at all of the same length is extremely anomalous behavior for the output of a putative RNG. Extending the runs test from 6 to 8 categories, i.e. counting blocks and gaps for run-lengths of exactly 1 to 7 and for run-lengths of 8 and greater, would easily have caught this. Yes, I agree, but it isn't my test, it's just my code for the FIPS test. As you have noted, simple LFSRs are easily detected by FIPS. LFSRs of longer period can be detected by using both a larger sample and analyzing the full, rather than the truncated, runs spectrum. Alternatively, if you simply want to eliminate any possibility of an LFSR, just apply Berlekamp-Massey. B-M is not something I'd normally recommend to run in power-up tests... 15 multiple runs test failures (byte alignment too good?), but passes poker test You want to recheck your last result.[...] FIPS passes the sequence. Correct, thank you. I've delayed releasing a bunch of my utilities for stuff like this because I hadn't yet had time to clean them all up and make them consistent... and it turned around and bit me. The LFSR program outputs ascii 0 or 1... I then used binbin to turn it into packed bytes, and this program was putting bits into bytes lsb-first. But the FIPS test (which originally did lsb-first too, but I was then convinced msb-first was more conventional) didn't agree. It's interesting (but not worth pursuing) that simply reversing the bits in the bytes makes it fail the test. Anyway, now that I've changed this convention, my results agree with yours. We've probably worn out everyone's interest with this, now. I'm happy to go offline with it though. 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]
URL for fips140.c
At 09:46 AM 2/5/2002 -0500, Arnold G. Reinhold wrote: I couldn't find it. Give me a hint? Sorry, I should have been more specific: http://people.qualcomm.com/ggr/QC/fips140.c goes straight to it. 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: Welome to the Internet, here's your private key
in the standard, you're doing fine. You are quite at liberty to perform the additional tests you've suggested. I was surprised that these simple software bad-generators managed to pass the test, although the point of the test is more to check out hardware failure-modes, like biases or stuck bits. Still. Interesting. 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: Linux-style kernel PRNGs and the FIPS140-2 test
There was an error in the bounds for the runs test specified by NIST; last october they updated FIPS 140-2 to specify new bounds. An updated version of my code can be found at http://people.qualcomm.com/ggr/QC/ (our old web pages are stale, and I'm still trying to have them taken down by our ex-ISP). Here's an excerpt from the comment in the new code: * Version 1.3 -- Bill Chauncey and his colleages pointed out to NIST that * the bounds in the runs test were incorrect. * They issued an update 2001-oct-10. If the new one still shows an anomalous number of runs test failures, there is a real problem. regards, Greg. At 03:23 PM 1/15/2002 -0500, Thor Lancelot Simon wrote: Many operating systems use Linux-style (environmental noise stirred with a hash function) generators to provide random and pseudorandom data on /dev/random and /dev/urandom respectively. A few modify the general Linux design by adding an output buffer which is not stirred so that bits which have already been output are not stirred into the pool of new random data (IMO, not doing this is insane, but that's a different subject). The enclosed implementation of the FIPS140-1/2 statistical test appears to show that such generators fail the runs test quite regularly. Interestingly, the Linux generator seems to do better the longer you let it run (which, perhaps, suggests that quite a bit of data should be run through it at boot time and discarded) but other, related generators do not. The usual failure mode is too many runs of 1 1s. Using MD5 instead of SHA1 as the mixing function, the Linux generator also displays too many runs of 1 0s. I have not yet seen other failure modes from these generators. To reproduce my results, just compile the enclosed and do a.out /dev/urandom on your platform of choice. Thor 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: What's the state of the art in one-pass integrity/encryption?
All of the early schemes were broken, as was the NSA's submission to the AES Modes of Operation workshop. However, three schemes, all similar in principal, have not only survived, but have proofs of correctness. The first was Charanjit Jutla's IAPM mode, another is Rogaway's OCB, and the third is from Gligor and Pompescu but I can't remember its name (I'm passing through SFO as I write this, so forgive me for not having references to hand). Phil Hawkes and I have extended IAPM (and I believe the method is applicable to the other modes too) so that you can authenticate parts of the message that are not encrypted, like IP headers for example. We sent public comments to NIST about this, or I cam post more detail if you need. regards, Greg. At 05:29 PM 11/24/2001 -0500, Radia Perlman - Boston Center for Networking wrote: In the last few years I've heard of some one-pass schemes (schemes that with one cryptographic pass over the data encrypt the data and generate an integrity check), and I've also heard of some schemes being broken. Does anyone know what schemes have been broken and which schemes are still considered secure? Are these schemes mature enough to be considered in standards? And does anyone know about the patent status of these schemes? References to papers would be appreciated. Thanks, Radia - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] 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: NYC events and cell phones
At 01:53 AM 9/17/2001 +0100, Peter Fairbrother wrote: It is possible that damage to basestations or volume of traffic may have caused this failure. Possibly, the telco switched it off to maintain service. Equally, the FBI/NSA etc may have switched it off, but I don't know why they would bother - the encryption is only between the mobile and the basestation, and they could pick up plaintalk there much more easily. There is one very simple reason why they might have wanted the encryption switched off. Wiretapping at the base station requires a wiretap order, whereas sniffing the airwaves in a matter of national security is something the NSA is allowed to do (but they can't get a wiretap order in a hurry). I don't know any facts in this matter at all, but I wouldn't be surprised if someone, somewhere, requested air interface encryption to be turned off. 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: A pattern emerges...
Well, Australia is also looking at (and probably soon to pass) similarly draconian legislation. The EFA is Electronic Frontiers Australia -- see http://www.efa.org.au/Campaigns/cybercrime.html EFA lodged a submission with the Inquiry into The Law Enforcement Implications of New Technology being conducted by the Joint Committee on the National Crime Authority. EFA is very concerned about proposals put forward by several law enforcement agencies for legislation to require Australian ISPs to retain transaction logs of all user activities. We consider the monitoring or data warehousing of Internet traffic or content on a mass scale to be highly privacy-invasive and an infringement of the human rights of Internet users. This proposal, if not strongly opposed by Internet users, is likely to foreshadow a move towards a Bill similar to the draconian Regulation of Investigatory Powers Bill (R.I.P.) recently passed in the U.K. The submission will be made available on EFA's website as soon as the Committee has granted permission for it to be made publicly available (this is normal prodecure in accord with Parliamentary inquiry rules/procedures). The Committee's report is likely to be tabled in the Winter sittings of Parliament. Greg. At 04:35 PM 7/29/2001 -0700, Ray Dillinger wrote: The DMCA and the Terrorism Act appear to provide exactly such laws. What has been passed recently by the other signatories to the UKUSA agreement that created Echelon? 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]
