Re: A-B-a-b encryption
On Nov 16, 2003, at 12:24 PM, lrk wrote: Stupid crypto, probably. Unless I'm missing something, this only works if A(A(M)) = M. Symetric crypto, not just symetric keys. NEVER willingly give the cryptanalyst the same message encrypted with the same system using two different keys. For the simple case, suppose F(X) = X ^ S (exclusive or with a string generated from the key). Then M = A(M) ^ B(M) ^ B(A(M)), right? Probably something similar for other symetric systems. This is Shamir's Three-Pass protocol and it doesn't require a symmetric system, it requires a commutative system. See Schneier p 516 (section 22.3) or [1] for details. so A(A(M)) != M Unless I'm mistaken, this commutative system does not leak information in the same way as XOR does. - Jeremiah [1] http://www.afn.org/~afn21533/keyexchg.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Are there...
(this is a resend, apologies for duplicates) As David Wagner points out, encryption with a public key (for which the private key has been discarded) would seem to work. I think there is a bit more to be said about requirements though. For a one-way encryption algorithm to be injective will also require that the output (nee ciphertext) be at least as long as the input, so unlike a hash function, you can't have a fixed length output for a variable length input (unless the fixed length is larger than the largest input.) One can always invert an injective one-way function by exhaustive search, but do you have a requirement for how difficult it must be to discover the inverse function? If, for example, a public key encryption is used, with the private key thrown away, then we might estimate the work involved in cracking the system. If you want the exhaustive search to be the easiest way to solve the system, then the effective key length of the public key must be at least as large as the message. If the system is to be used for password encoding (as is traditional) then one should also protect against dictionary attacks (precomputation of likely passwords). The usual way to do that is with salt, but if you also wish to avoid someone cracking the whole system, then the encryption key should be generated independently for each encryption and packaged along with the ciphertext. That solves the salt problem and the cracking the system problem in one step. -Larry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clipper for luggage
At 03:00 PM 11/16/03, peter gutmann wrote: Bill Frantz [EMAIL PROTECTED] writes: I usually travel with zipper closed duffel bags. I fasten the zipper closed with a screw link. Anyone can unscrew the link and get into the bag, but it does effectively keep the zipper closed in transit. I suppose it also provides some level of security because someone wanting to do a quick grab from luggage will probably pick a less-secured piece. Whentrue locks are banned, that's actually a rather good protection mechanism, constituting a type of hashcash for luggage. Someone who's looking for targets of opportunity and has a choice between a Clipper-locked container they can get into almost unnoticed in 5 seconds or something where it'll take a minute or two of obvious fiddling will presumably go for the Clipper-lock. Just don't go overboard with those custom foot-long screw machined locks. TSA had been recommending electricians cable ties made of nylon. The 4 (10 cm) or 8 (20 cm) sizes work well in most zipper-type locks. They can't easily be removed without cutting them. I had improved the ties by using colored ones (available at most electrical supply houses and better hardware stores), so that there would be clear evidence of entry. For further security I dropped a bit of colored sealing wax on each cable tie. On a longer trip I have to carry spare cable ties. I made sure not to have spares of the color I used on each leg. I also tried to carry the spare cable ties and spare sealing wax (several colors) in my carry-on (or my pockets). These can easily be cut with fingernail clippers, which are now legal to carry, and which can also be carried in an unlocked pocket on the checked bag. For some years, numbered one-use nylon or plastic ties have been available in luggage supply stores. These also have to be cut or broken to open the suitcase, and they cannot readily be replaced because the serial numbers are unique. None of these totally prevent theft, but any lock that can fit through most zippers can easily be cut with a short 12-inch bolt cutter (30 cm long), that can be bought for $10 at Sears or most hardware stores, and that will fit in the pockets of most work-clothing. (Indeed, it can probably be cut with an 8 (20 cm long) diagonal cutting pliers (or electricians pliers).) Given the lax security in the back areas of the airports, it's easy enough for the baggage handlers to have cutting instruments. But, if the object is to be able to tell immediately that the suitcase has been opened, and so file a claim, they will work. Indeed, if all you have to do is slow down a thief, then a twist tie or the plastic seal from a garbage bag can be used to seal the lock. Hard-sided luggage is more difficult to lock in this way. However, the plastic cable ties are available in lengths up to about 48 (120 cm). These can be passed around the bag and tightened (if necessary, two or more can be linked together). Since these are not available in colors, and are too big to be convenient in carry-ons (and might invite queries since they are the same things that police use as handcuffs), the lock portion should be sealed with sealing wax. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Are there...
As David Wagner points out, encryption with a public key (for which the private key has been discarded) would seem to work. I think there is a bit more to be said about requirements though. For a one-way encryption algorithm to be injective will also require that the output (nee ciphertext) be at least as long as the input, so unlike a hash function, you can't have a fixed length output for a variable length input (unless the fixed length is larger than the largest input.) One can always invert an injective one-way function by exhaustive search, but do you have a requirement for how difficult it must be to discover the inverse function? If, for example, a public key encryption is used, with the private key thrown away, then we might estimate the work involved in cracking the system. If you want the exhaustive search to be the easiest way to solve the system, then the effective key length of the public key must be at least as large as the message. If the system is to be used for password encoding (as is traditional) then one should also protect against dictionary attacks (precomputation of likely passwords). The usual way to do that is with salt, but if you also wish to avoid someone cracking the whole system, then the encryption key should be generated independently for each encryption and packaged along with the ciphertext. That solves the salt problem and the cracking the system problem in one step. -Larry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A-B-a-b encryption
In message [EMAIL PROTECTED], Perry E.Metzger writes: Hmm. You need a cipher such that given B(A(M)) and A you can get B(M). I know of only one with that property -- XOR style stream ciphers. Unfortunately that makes for a big flaw, so I'm not sure we should throw out our Diffie-Hellman implementations yet. I believe that Pohlig-Hellman with the same modulus has this property, too. But I don't recall seeing any analysis if Pohlig-Hellman modulus reuse has the same failings as RSA with modulus reuse. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A-B-a-b encryption
martin f krafft wrote: it came up lately in a discussion, and I couldn't put a name to it: a means to use symmetric crypto without exchanging keys: - Alice encrypts M with key A and sends it to Bob - Bob encrypts A(M) with key B and sends it to Alice - Alice decrypts B(A(M)) with key A, leaving B(M), sends it to Bob - Bob decrypts B(M) with key B leaving him with M. Are there algorithms for this already? What's the scheme called? It's called Pollig-Hellman. It only works if your encryption scheme is commutative. Most symmetric-key encryption schemes aren't commutative, but one scheme that does work is A(M) = M^A mod p. One scheme that doesn't work is A(M) = M xor A; XOR is indeed commutative, but it becomes insecure when used in the above protocol. Anyway, the Pollig-Hellman protocol is no better (and probably no worse) than a straight Diffie-Hellman, so there seems to be little reason to adopt it. Just stick to standard Diffie-Hellman. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: XML-proof UIDs
This is what GUIDs/UUIDs were designed for, and they're used broadly. They're standardized in ISO 11578 [1], although there's a very similar public description in an expired Internet Draft [2]. Microsoft also publishes a description of how they generate their GUIDs, but I can't find it right now. That draft has been replaced by the UUID/URN draft that I mentioned. It includes all of the original text. Actually, I rewrote most of it so it reads better now. It's actually in the final comment period and should show up as an official RFC in few weeks. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Are there...one-way encryption algorithms
Amir and others, First, I'd like to thank all who have taken time to reply, either on- or off-list. All suggestions so far are related to public-key algorithms; I had myself thought about simply raising a generator g to the plaintext, or to a suitable injective function of the plaintext, in a GF(p): that doesn't even require a key to throw away. One drawback is that, with the possible exception of ECC-based methods, the minimum size of the cryptotext becomes larger than I'd like. Anyway, the intended use is for primary keys in transaction databases, in replacement of the PAN (a.k.a. credit card number). Using secure hashes is the usual way of doing such things, but the slight risk of collision, although practically negligible, is a bit irksome (especially considering that the plaintext is of fixed size, and therefore injectivity is not a priori impossible), and I was wondering if something better can be done. Enzo - Original Message - From: Amir Herzberg [EMAIL PROTECTED] To: 'Enzo Michelangeli' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, November 16, 2003 10:44 PM Subject: RE: Are there...one-way encryption algorithms Enzo asked, Are there one-way encryption algorithms guaranteed to be injective (i.e., deterministically collision-free)? Or are there theoretical reasons against their existence? I'm looking for algorithms where every piece of code and data is public, thus excluding conventional enciphering with a secret key. Sounds like you look for One Way Permutations... which of course exist (if one-way functions do). But before we get into details, it'll be useful if you specify your needs more precisely since imprecision is the mother of weaknesses and break-ins. BTW I've updated my foils on encryption and hashing which cover much of this topic (see in site if interested). Best, Amir Herzberg http://amir.herzberg.name - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
