Re: small crypto that isn't predictable
Bill Stewart [EMAIL PROTECTED] writes: If you've got room for an IV, you _could_ do something like XORing the IV with the key, not the data stream - that means that it isn't really using the same algorithm for the IV as for the rest of the data stream, but you may not care. With RC4, it's better simply to append the IV to the key rather than XORing it. It sounds like the RC4-based CipherSaber is exactly the algorithm you want: http://ciphersaber.gurus.com/ CipherSaber prepends a 10-byte IV to the ciphertext, so your ciphertext is 10 bytes longer than the plaintext, and you have to generate an expected 2^40 or so ciphertexts with the same key before you get a disastrous IV collision. Nitpick: here I'm using "IV" to mean "any nonce for a randomized stream cipher". A purist might restrict the meaning to mean an initial state for a block cipher chaining mode. -- __ \/ o\ [EMAIL PROTECTED] /\__/ http://www.cluefactory.org.uk/paul/
Re: Perfect compression and true randomness
"Arnold G. Reinhold" [EMAIL PROTECTED] writes: In any case, as I tried to point out before, perfect compression, what ever it may be, does not prevent a know-plaintext attack. Actually it does: if the compression is perfect with respect to the document model of the attacker, and the plaintext is known, then it compresses down to zero bits so the attacker learns nothing. This supports your main point: perfect compression is a *much* less realistic idea than true randomness! -- __ \/ o\ [EMAIL PROTECTED] /\__/ http://www.cluefactory.org.uk/paul/
Re: Cryptographic Algorithm Metrics
Peter Fairbrother [EMAIL PROTECTED] writes: Not so. Perfect compression with encryption works too. Er, does it? I get a 1k message from you, perfectly compressed and then encrypted with some strong algorithm and a 128-bit key. As a godlike being unhindered by constraints of computational power, I try all 2^128 possible keys, and find due to the perfect compression that each of the 2^128 plaintexts is equally likely. From an information theoretic point of view, I'm much better off than I was before: I used to be missing 8192 bits of entropy, but now I'm only missing 128 - the space of possible messages has been vastly reduced. Put it this way, if all I want to know is whether you're asking for a ticket to the dance, I might well learn the answer since I might find that none of the candidate messages include that request. A 1k message encrypted with OTP, however, tells me nothing whatsoever. -- __ \/ o\ [EMAIL PROTECTED] /\__/ http://www.cluefactory.org.uk/paul/
Re: copy protection
"Perry E. Metzger" [EMAIL PROTECTED] writes: Getting around the license stuff will always be trivial, however, in spite of the pipe dreams of fools. If the software can be read by the user's computer, it can be copied. If it can be copied, automated tools will be developed to permit it. "Trivial" is overstating it, I think. I've seen dongle-based license code designed such that if you tried modifying the code to skip the dongle check, the program's pointer arithmetic would go screwy and it would crash in horrible ways. It was a damn clever design, which I can't say much about here except that it depended on a fairly detailed understanding of the innards of several parts of a large and complex program, and so making the appropriate fix would be a sizeable job for a very skilled and patient hacker; for example, it did not depend on branches that were only taken when the dongle was absent. Of course, it could be cracked, but it wouldn't have been trivial. -- __ \/ o\ [EMAIL PROTECTED] /\__/ http://www.cluefactory.org.uk/paul/
Re: IBM press release - encryption and authentication
Rich Salz [EMAIL PROTECTED] writes: No word, of course, on how the thing actually works, or whether they intend to patent it. Not so. Search your nearest IETF internet-drafts repository for draft-jutla-ietf-ipsec-esp-iapm-00.txt Eh? It would be bad if a patented system became an IETF standard. And if we could make such a standard, it should almost certainly be one of the other proposals heard by NIST, Galois-field OCB. [A draft does not imply an IETF standard in the making. Anyone can publish a draft, or even an RFC. --Perry] -- __ \/ o\ [EMAIL PROTECTED] /\__/ http://www.cluefactory.org.uk/paul/
Re: migration paradigm (was: Is PGP broken?)
Rick Smith at Secure Computing [EMAIL PROTECTED] writes: Now, just how do we intend to address such concerns in our memory-based authentication systems? Our whole technology for using memorized secrets is built on the belief that people will remember and recite these secrets perfectly. Some applications could take more of a 'biometric pattern matching' strategy that measures the distance between the actual passphrase and a stored pattern. But this won't provide us with a secret we can use in crypto applications like PGP. There has been some work on addressing this issue. See http://www.counterpane.com/personal-entropy.html -- __ \/ o\ [EMAIL PROTECTED] /\__/ http://www.cluefactory.org.uk/paul/
Re: migration paradigm (was: Is PGP broken?)
Bram Cohen [EMAIL PROTECTED] writes: Is there a reason not to use AES block cipher in a hashing mode if you need a secure digest of some data? Hashing modes of block ciphers require a re-key for every block, and hence are really, really slow. Well, Rijndael can re-key faster than it can encrypt, so it's less of a problem than with other block ciphers. Of course, there are not unrelated worries that Rijndael's key schedule may not offer the strength required for hashing modes, though the designers are confident that the strength of the round function ensures everything will be OK. -- __ \/ o\ [EMAIL PROTECTED] /\__/ http://www.cluefactory.org.uk/paul/
Re: Lots of random numbers
Bill Sommerfeld [EMAIL PROTECTED] writes: Eh? You should *never* need to encrypt information before shoving it in the pool. If you've got a secret you could use for such encryption, shove it in the pool and then forget about it - it will do precisely as much good. I'm inclined to agree with Don here, from principles of conservative cryptographic engineering. By using a keyed one-way function before adding data to the pool, you add an additional layer of defense against an attacker guessing the pool contents. If you want to design a new kind of pool based on encrypting the incoming data, that could be an effective way to do it, but it will be part of the pool. If you start doing that sort of thing outside the pool, you're just building a bigger pool around the pool you've already got. If the pool is Yarrow, then you will be very hard pressed to build a better pool than the Yarrow designers, by this strategy or any other. Conservative cryptographic engineering says complexity is the enemy of security. Once you've chosen your components, trust them to do the job they're designed for - don't pre-encrypt your encrypted data, and don't build a randomness pool around your randomness pool. -- __ \/ o\ [EMAIL PROTECTED] /\__/ http://www.cluefactory.org.uk/paul/
Re: Lots of random numbers
Don Davis [EMAIL PROTECTED] writes: perhaps surprisingly, i disagree with the other respondents. as long as you encrypt or MAC the incoming packets ( their interarrival times), with a closely-guarded secret key, before you stuff the bits into your entropy pool, then you should do fine. Eh? You should *never* need to encrypt information before shoving it in the pool. If you've got a secret you could use for such encryption, shove it in the pool and then forget about it - it will do precisely as much good. I'm tempted to agree with the thrust of what you're saying, though - I'm not as convinced as everyone else that Rich's idea is without merit. However, I wouldn't bother putting in the packet contents, just the arrival times. As you say, I wouldn't use it as your only entropy source - the Pentium RNG would make a good primary source - and once you've got enough entropy in the pool you can pull out all the keys you like without worrying the pool will "run out" of entropy. The Yarrow paper is great for this: http://www.counterpane.com/yarrow.html -- __ \/ o\ [EMAIL PROTECTED] /\__/ http://www.cluefactory.org.uk/paul/
Re: Lots of random numbers
[EMAIL PROTECTED] writes: Why don't you stick a sound card (the noisier, the better) into each node, and dump /dev/dsp (LSB) input at max amplification into the randomness pool? There's no reason to put only the LSBs in the randomness pool, if the pool is properly designed. Put all the data in. Has any research gone into estimating the entropy from such a source? -- __ \/ o\ [EMAIL PROTECTED] /\__/ http://www.cluefactory.org.uk/paul/
Re: Multi-part security solutions (Was: Re: Rijndael Hitachi)
Meyer Wolfsheim [EMAIL PROTECTED] writes: The only reasons I see for having a security system (be it an encryption product, or a physical access device) with a large discrepancy in the level of security that the individual components provide is either: [snip reasons a, b and c] I'm sure you've thought of this, but there's also a reason (d): because the most convenient component for a particular application is vastly more secure than you need. When using a cipher as a component, you might as well use a ludicrously strong one like Rijndael or Blowfish, because there's nothing to be gained from using a weaker one. Good locks are more expensive than bad ones, but strong crypto is free. -- __ \/ o\ Employ me! Cryptology, security, Perl, Linux, TCP/IP, and smarts. /\__/ [EMAIL PROTECTED]http://www.cluefactory.org.uk/paul/cv/
NIST, modes of operation and patents.
NIST is running a Modes of Operation workshop on Friday 20th. See http://csrc.nist.gov/encryption/aes/modes/ It seems likely that NIST will demand the same licensing conditions from anyone proposing a mode of operation for standardisation that they did for the AES cipher itself. Does anyone know for sure? I ask because one of the papers listed for discussion at the modes of operation workshop is a very cute technique for doing authentication at little extra cost over encryption, but it's patented by IBM, so it'd be good to see the world get a royalty-free license for this one. -- __ \/ o\ Employ me! Cryptology, security, Perl, Linux, TCP/IP, and smarts. /\__/ [EMAIL PROTECTED]http://www.cluefactory.org.uk/paul/cv/
Re: reflecting on PGP, keyservers, and the Web of Trust
I'm still far from convinced that the Web of Trust achieves what it's supposed to achieve, even when used correctly. Consider this question: what do you need to know about a person in order to feel confident that they are the intended recipient of your secure communication? Because I bet the answer is hardly ever "their legal name". I recently exchanged some email with a Ruediger Weis I met at a conference. When verifying his signature, I wanted to be sure that it was sent by the person I met. It would *not* have satisfied me to know that it was sent by someone of that name, since there are probably hundreds of people with that name. And conversely, I don't actually care if that's his real name - his real legal name can be Jurgen Schmidt for all I care. I used the business card he beamed me to check out his PGP fingerprint, and could therefore be confident that I was corresponding with the person I met. If you use this technique, make sure it's difficult to plant business cards into your pockets. I know that the signed information includes an email address as well as a name. I'm ignoring that and everyone else should too - there's no burden on the signer of a key to verify the email address, only the name. I can turn up to a keysigning party with my passport and get my key signed as "Paul Crowley [EMAIL PROTECTED]", because no-one's expected to check that part. I think it appears as an ineffective fix to the problems I'm trying to highlight here. Note that it does make sense to sign your *own* key with your email address, so that once your correspondents decide your key is the right one, they can be confident of which email address to correspond with! I don't think the idea of key signing is fundamentally flawed, but I think we need far more flexibility on what information we bind to a public key. I'd like a way of saying "this is the John Smith that I know, not just any John Smith, and if you've met my friend John Smith then this is his public key". I want to bind photographs to keys. I'd like to say "This is John Smith the famous author", or "This is the John Smith from the famous case Smith v. Justice 1992". Are there any commonplace circumstances where confidence in someone's legal name is enough? -- __ \/ o\ Employ me! Cryptology, security, Perl, Linux, TCP/IP, and smarts. /\__/ [EMAIL PROTECTED]http://www.cluefactory.org.uk/paul/cv/
Re: Tipster voluntary payment protocol
"Fred Hapgood" [EMAIL PROTECTED] writes: Stick *what* into a standard contract? What would that provision look like? "Artist agrees not to accept gifts from fans?" "Artist agrees not to possess or publicize public key or digital signature?" "Artist shall not in any way participate in any system designed to assist recipients of digitally copied music to reward the artist directly." -- __ \/ o\ Employ me! Cryptology, security, Perl, Linux, TCP/IP, and smarts. /\__/ [EMAIL PROTECTED]http://www.cluefactory.org.uk/paul/cv/
Re: Extracting Entropy?
A variant on this question that we might see for lots of questions soon: what's the best way to do this given only AES as a primitive? Here's a simple way that uses all of the passphrase to control a cryptographic PRNG that can be used to generate keys or whatever: use the passphrase as the key to the block cipher, and run it in counter mode. If the passphrase is less than 256 bits (32 characters), this works directly. If it's less than 64 characters, use Triple-AES. In general, I assume that to use a key n times longer than the native key length of the block cipher, you need to run it in 2n-1 mode; I'm pretty sure this is so if the meet-in-the-middle attack is the only one you have to worry about. Append a 1 bit to the passphrase, then fill to the next key boundary with zeroes as usual. This takes O(mn) time, where n is the passphrase length and m is the number of key bits you need. I suspect any good solution will have this property. Still, you only have to keyschedule n times and things should be pretty fast after that. Any thoughts on the security or efficiency of this proposal? -- __ \/ o\ [EMAIL PROTECTED] *NOTE NEW EMAIL ADDRESS* \ / /\__/ Paul Crowley http://www.cluefactory.org.uk/paul/ /~\
Re: FYI: Intelectual property discussion on AES
"Heyman, Michael" [EMAIL PROTECTED] writes: Mentioning Dan Bernstein, does anyone know the license that twofish will be under? I think Bernstein was one of the orginal authors. The Twofish team was Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall, and Niels Ferguson. Since then the team has grown to the "extended Twofish team", which includes Mike Stay and Tadayoshi Kohno. Perhaps others, I forget... Twofish is a (the?) leading contestant for the Advanced Encryption Standard (AES) to be chosen by NIST. There are five remaining candidates for the AES. Twofish and Rijndael have always been explicitly free from any patent restrictions and accompanied by liberally-licensed source code. Serpent was at one stage going to be patented, but the authors changed their minds and it is now unencumbered. RC6 and Mars are patented and defended, but (as with all AES entrants) the authors have signed a waiver granting the world a royalty-free license in perpituity should their cipher be an AES winner. Recently NIST asked for, and received, a further waiver that authors would license all of their patents for use with whichever cipher wins the AES. Going by the summary of the feedback forms from the AES 3 conference on NIST's web pages (as well as by the "buzz" at the conference itself), the three unencumbered ciphers are the most popular on technical grounds. In fact, the final submission from the Twofish authors argues that any of those three would make excellent winners; FWIW I agree. It's far from clear that Twofish is ahead of the other two. That the three best-regarded ciphers should be the unpatented ones should be of interest to patent watchers. -- __ \/ o\ [EMAIL PROTECTED] *NOTE NEW EMAIL ADDRESS* \ / /\__/ Paul Crowley http://www.cluefactory.org.uk/paul/ /~\
Re: Extracting Entropy?
John Kelsey [EMAIL PROTECTED] writes: If you don't mind the limitation of 1k of internal state, then Panama could be used directly; push in your salt and passphrase, padding to the edge of the block with one followed by zeroes, then do 32 blank pulls and start pulling out your key. A generalization of this idea is: S(K,len) is stream cipher output with key K and length of output len. hash(X) is hash function output of same size as K. Key = S(hash(passphrase),desired key length) I don't think I see how this is a generalisation; what are you identifying with "K" in my description? It's not the output from Panama after hashing the input; that's "Key" itself. It can't be the internal state before the blank pulls, that would make "hash(X)" a bad hash function, and I think if it were the internal state after the blank pulls then that would make "S(K,len)" a bad stream cipher. So I'm not sure that using Panama directly fits the model you describe. Of course, you could use Panama in the mode you describe, but I'm not sure I see much advantage to that; you have to make K as long as min(desired key length, passphrase length, internal state size) in order not to waste entropy, and in any of these cases the second hashing pass doesn't seem to do you much good; it just loses you half a bit of entropy to collisions. I've been trying to think about how you might use a primitive like Panama in combination with real entropy sources to provide a /dev/random type thing, but I've hit a problem in how to think about it. For some appropriate value of N based on the computational resources of your attacker, you have to take in at least N bits of entropy before generating a single bit of output, or fall foul of an iterative guessing attack. The problem I have is that once you've got N bits of entropy, you really don't need any more! You could merrily ignore all the rest of the entropy at your disposal, and (if your components are secure) your attacker will never be any better off than they were when you first started producing output. Given this, what theory can you use to determine if you're using those subsequent bits of entropy appropriately? -- __ \/ o\ [EMAIL PROTECTED] *NOTE NEW EMAIL ADDRESS* \ / /\__/ Paul Crowley http://www.cluefactory.org.uk/paul/ /~\
Re: Critics blast Windows 2000's quiet use of DES instead of 3DES
"L. Sassaman" [EMAIL PROTECTED] writes: Frankly, I can't understand why the IPsec protocol still allows DES. We are waiting for AES. So am I correct in assuming you are saying that DES will be disallowed as part of the IPsec protocol when AES is finalized? This would be good. I still think that DES should be dropped immediately, however. I'm guessing that they have to have a MUST cipher, and they don't want to change twice, so it makes sense to wait until September and then make AES (or AES primary) the only MUST cipher. -- __ \/ o\ [EMAIL PROTECTED] *NOTE NEW EMAIL ADDRESS* \ / /\__/ Paul Crowley http://www.cluefactory.org.uk/paul/ /~\
Re: legal status of RC4
Vin McLellan [EMAIL PROTECTED] writes: I suspect that RSA did send out more than a few nastygrams to OEMs or other mass marketeers about "illicit use" of RC4, but -- at least in recent years -- its complaints probably went to commercial enterprises which both (a) sought to resell the algorithm in the US, and (b) blatently used the RC4 label in a way that is likely to confuse many people as to the source of the RC4 implementation code. Not so. I know of a firm that paid hundreds of thousands of dollars to RSADSI in order to use their own entirely original implementation of RC4, under direct threat of a bogus copyright lawsuit. They knew, I think, that if RSADSI sued they'd lose, but they didn't fancy being dragged into court. This wasn't a crypto product, just an implementation of a standard whose encryption option mandated RC4. I doubt any mention of RC4 would have been made in either the advertising or the documentation. -- __ \/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
Re: Blue Spike and Digital Watermarking with Giovanni
Eugene Leitl [EMAIL PROTECTED] writes: Well, the deformations must be smooth, so this just describes an attack against a certain type of watermarks. Yes. They found that there was one watermarking product on the market that was not defeated by their standard mechanism, and developed a new mechanism that defeated that one too. Of course, the state of the art in watermarking may have moved on since that paper was written, but if anyone knows of a watermarking product for images that has not already been defeated I'd be interested to know. -- __ \/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
Re: Blue Spike and Digital Watermarking with Giovanni
As far as I know, all fielded watermarking schemes can be defeated with simple, invisible distortions of the image - see http://www.cl.cam.ac.uk/~fapp2/steganography/ for work done by Fabien Petitcolas and Ross Anderson. You don't even have to have more than one copy of the picture or know very much about the scheme in use. -- __ \/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet
"William H. Geiger III" [EMAIL PROTECTED] writes: IMHO hardware based crypto is dangerous especially from a company like Intel that will not allow it's designs to be peer reviewed. Their entire attitude is "trust us we are Intel". Well sorry I don't. Intel's RNG and now it's IPSEC accelerator are to ripe of a target for TLA's to trust without complete, open, peer review. Until this happens, IMHO, it is as trustworthy as CAPI. [MODERATOR's NOTE: I'm sorry, but I find this totally wrongheaded. A 3DES ethernet card need not be "trusted" -- if the thing interoperates with other IPSec implementations, its correct, pure and simple. Indeed, the slightest flaw and it would not interoperate. Perhaps they could rig it to leak too much in the RF spectrum, but they could do that with the rest of the chipset, too, and you are using *that*. If the thing has an RNG on board for any reason, that might not be trusted, but I guess in practice it'll only use keys provided from outside the card. I suppose you could rig it to return the secret key in response to some secret "backdoor packet", but you'd be utterly destroyed if you were caught, and you might well be caught. It's not as easy as introducing an "accidental" flaw in an RNG. But if PCK has looked at their RNGs and thinks they're good then I suspect they are. I agree this is most likely a non-issue, I'm just wondering what the theoretical possibilities are. -- __ \/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
