Re: IBM press release - encryption and authentication
- Original Message - From: "David Wagner" <[EMAIL PROTECTED]> Newsgroups: isaac.lists.cryptography To: <> Sent: Monday, December 18, 2000 9:14 AM Subject: Re: IBM press release - encryption and authentication > Enzo Michelangeli wrote: > >OpenPGP tries to detect such "wrong key" situations for > >symmetrically-encrypted packets in a pretty simplistic way, [...] > > The repetition of 16 bits in the 80 bits of random data prefixed to > > the message allows the receiver to immediately check whether the > > session key is incorrect. > > This does not provide message integrity or message authentication. > It provides a much weaker property: If you've decrypted with the wrong > key, this will let you detect that fact. Why? It will also let you detect if someone has tampered with the ciphertext in a block containing the redundant information (or preceding it, unless ECB is used). Also, if the identity of the sender is proved by the knowledge of the encryption key (which was my assumption in the post you quote) a successful decryption will additionally prove the authenticity of the message. Enzo
Re: IBM press release - encryption and authentication
William Allen Simpson wrote: >As far as I can tell, the only unique element is the mod 2^128 - 159 >function. We just need to use another function. > >My own favorite (in CBCS) has been rotation by the population count [...] The uniquely valuable aspect of Jutla's scheme (and other related schemes, e.g. Gligor's or Rogaway's schemes) is that it comes with a proof of security. History shows that it is extremely easy to propose schemes for encryption-with-integrity that are plausible-looking yet nonetheless entirely broken. At this point, I don't think I would trust very much a proposal without a proof. And I think it would be fair to say that CBCS falls into the camp of plausible but unproven proposals. (Correct me if I'm wrong!)
Re: IBM press release - encryption and authentication
Enzo Michelangeli wrote: >OpenPGP tries to detect such "wrong key" situations for >symmetrically-encrypted packets in a pretty simplistic way, [...] > The repetition of 16 bits in the 80 bits of random data prefixed to > the message allows the receiver to immediately check whether the > session key is incorrect. This does not provide message integrity or message authentication. It provides a much weaker property: If you've decrypted with the wrong key, this will let you detect that fact. For message integrity or authentication, it seems that you need either a full-blown MAC or else some scheme like Charanjit Jutla's.
Re: IBM press release - encryption and authentication
-BEGIN PGP SIGNED MESSAGE- Bruce Schneier wrote (CRYPTO-GRAM, December 15, 2000): > Combining encryption with authentication is not new. The literature has > had algorithms that do both for years. This reearch has a lot in common > with Phillip Rogaway's OCB mode. On the public-key side of things, Y. > Zheng has been working on "signcryption" since 1998. > ... > In the IETF, we discussed this on the IPSec mailing list as early as August 1994. As best I can recall, I first presented Cipher Block CheckSums (CBCS) at the December 1994 meeting, and wrote the first formal draft in February 1995. The last internet-draft was July 1998. The IBM scheme also has somewhat in common with various "enhancements" to DES-XEX that were discussed. I'm not sure when the first draft was written (this laptop only goes back to 1997), but the last internet-draft (draft-simpson-ipsec-enhancement-01.txt) was May 1997. Both efforts used a separate authentication key to generate a sequence that was XOR'd with the plaintext and/or ciphertext. > Unfortunately, IBM is patenting these modes of operation. This makes it > even less likely that anyone will implement it, and very unlikely that NIST > will make it a standard. We've lived under the RSA patents for long > enough; no one will willingly submit themselves to another patent regime > unless there is a clear and compelling advantage. It's just not worth it. > (roar of the crowd in agreement) As far as I can tell, the only unique element is the mod 2^128 - 159 function. We just need to use another function. Greg Rose points out that the function is flawed. My own favorite (in CBCS) has been rotation by the population count (of the number of 1 bits). Very non-linear. Some folks think that's slow, but it's fast compared to MD5 And that's what we used in the old CDC, which had a machine instruction for population count. Bram Cohen wrote: > > There's an improved version of the IBM mode at > http://csrc.nist.gov/encryption/aes/modes/ in the 'OCB mode' paper. > > Clearly, it's a good idea to wait for new developments to stop happening > to use the new modes. > -BEGIN PGP SIGNATURE- Version: PGP 6.5.1 iQCVAwUBOjtqgdm/qMj6R+sxAQGbxgQArF2xcR7elH9GD71KqacgrIakskpnL1nE 7FCVE/kcYCMnc5QhZlr80gdVGFhvMZLgm7wOzRHAgaPM+U//ZWcdfazVuaHHC8kH YYlabqeFpJ2SAP2MRIruJde1fFzatpjb87OimhxRC4NTlsc6UQEqBsqzAB5iEh5r sDNlF5YD+GA= =8Vry -END PGP SIGNATURE-
Re: UK Sunday Times: "Steal the face right off your head"
Ray Dillinger wrote: > Side effect of having very thick dry skin that's not very > conductive electrically. There's purpose in using photoplethysmography/photoxytometry (this gives you oxygenation of the blood plus pressure pulses with a little DSP on NIR/red LED light) together with papillary pattern matching, as this would reject forgery with crude replica. Or amputated limbs. Of course, pure biometrics is cargo cult security.
Re: IBM press release - encryption and authentication
- Original Message - From: "Nikita Borisov" <[EMAIL PROTECTED]> Newsgroups: isaac.lists.cryptography To: <[EMAIL PROTECTED]> Sent: Friday, December 15, 2000 6:56 AM Subject: Re: IBM press release - encryption and authentication > In article <010801c064d0$b64193a0$6000a8c0@em>, > Enzo Michelangeli <[EMAIL PROTECTED]> wrote: > >Apart from the parallelization-friendliness, wouldn't the same result be > >achieved by encrypting the concatenation of the plaintext with a MAC > >implemented through a fast error detection code (say, a sufficiently long > >CRC)? Due to the presence of encryption, the security properties of the > >inner MAC don't appear to really matter (as they would in the "DES-CBC > >first, then HMAC-MD5" scenario mentioned in the draft for comparison). > > I may be misunderstanding what you are suggesting, but the construction > that uses an encrypted CRC as a MAC is insecure. Eg. Stubblebine & > Gligor[1] show attacks on protocols which encrypt the concatenation of a > packet and a CRC-32 using DES-CBC. The properties of the MAC, encrypted > or not, do appear to matter. Unfortunately I have no access to the paper you mention, but I was really thinking more in terms of MIC than MAC. In a scenario purely based on symmetric algorithms, both encryption and authentication rely on the fact that Bob and Alice share a secret (encryption key and key used to compute the MAC). If both operations are performed at the same time, it makes sense to use only one key reducing the MAC to a MIC, as long as the recipient has a way of recognizing the decrypted plaintext as valid, distinguishing it from random garbage produced by an attempt of decryption with the wrong key. In other words, authentication is reduced to integrity check. But now, it seems to me (and I may well be wrong) that the fact that both message and MIC are encrypted makes it impossible for an attacker to play the tricks that normally make a simple CRC insecure requiring the use of secure (but slow) hashes. So, a simple and fast error correction code should do the job. OpenPGP tries to detect such "wrong key" situations for symmetrically-encrypted packets in a pretty simplistic way, by repeating two of the eight random bytes used to prefix the plaintext (incidentally, this means that there is a non negligible chance of these cases going undetected...). From the section 5.7 of RFC2440: [...] The data is encrypted in CFB mode, with a CFB shift size equal to the cipher's block size. The Initial Vector (IV) is specified as all zeros. Instead of using an IV, OpenPGP prefixes a 10-octet string to the data before it is encrypted. The first eight octets are random, and the 9th and 10th octets are copies of the 7th and 8th octets, respectively. After encrypting the first 10 octets, the CFB state is resynchronized if the cipher block size is 8 octets or less. The last 8 octets of ciphertext are passed through the cipher and the block boundary is reset. The repetition of 16 bits in the 80 bits of random data prefixed to the message allows the receiver to immediately check whether the session key is incorrect. [...] Enzo
I can't be the first person to have noticed this, but...
The (now expired) RSA patent number, 4,405,829, is prime. -matt
Big Number Calculator Applet
I've written a number calculator applet as a number theory teaching tool. It exposes most of the functionality in the Java 1.1 (and later) BigInteger package, including prime checking and modular arithmetic. One of its goals is to let people try out various cryptographic calculations by hand. For example, I try to describe a manual D-H key exchange procedure. The applet and documentation is at http://world.std.com/~reinhold/BigNumCalc.html Unfortunately, Netscape 4.7 and earlier do not support Java 1.1, so you will need Internet Explorer 4.5 or later or the new Netscape 6.0. I've tested the applet using IE 5.0 and 5.5 on Windows 98 and IE 4.5 (MRJ) on the Mac. I'd like to get some feedback before I try to distribute the applet more widely. Comments, bug reports and test results on other browser/platform combinations would be most helpful. Also I'd be interested in suggestions as to a suitable open source repository for the Java source code. Enjoy, Arnold Reinhold
snake-oil projects -- 2 University Presidents Will Try to Improve Voting
In http://www.nytimes.com/2000/12/15/politics/15MIT.html "The idea," Dr. Baltimore said, "is to produce a system that is foolproof, secure, simple to operate and affordable so that it can be in every precinct in America. The system should also give everyone a record of their vote, so they know exactly what they have done at the polls." and which allows the voter to prove how he voted (and cash in), might someone add. I guess snake-oil projects are getting a good company. Also, they all seem to like to promise "foolproof, secure, simple to operate and affordable". Cheers, Ed Gerck
Security Against Compelled Disclosure
People may be interested in a paper Ian Brown and I wrote, with the above title, for ACSAC. http://www.apache-ssl.org/disclosure.pdf Cheers, Ben. -- http://www.apache-ssl.org/ben.html "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
