Re: [cryptography] data integrity: secret key vs. non-secret verifier; and: are we winning?
On Wed, May 2, 2012 at 5:01 AM, Darren J Moffat darren.mof...@oracle.com wrote: On 05/02/12 06:33, Kevin W. Wall wrote: primitives that do not include *any* AE cipher modes at all. Some great examples are in the standard SunJCE that comes with the JDK (you have to use something like BouncyCastle to get things like GCM or CCM for Java and that's often a hard political sell so most developers won't bother). Another example is with the .NET framework. It too has no authenticated mode. Both Java and .NET only support ECB, CBC, CFB, OFB modes and starting with JDK 1.6, Java also offers CTR mode. (.NET may too; I haven't actually looked in a while.) JEP 115: AEAD CipherSuites http://openjdk.java.net/jeps/115 Darren, Well, that is definitely good news to be sure, but as I read JEP 115, it appears that: 1) The interfaces are only defined in JDK 7. A reference implementation won't come until JDK 8. (Meanwhile, most applications are still on JDK 6 and some even on earlier, unsupported versions.) 2) As I read this, it appears as though the reference implementation is only going to address Java Secure Sockets Extension (JSSE) and for PKCS#11 support. In other words, all they are doing with is adding support for some new cipher suites for TLS.and adding PKCS11 support to NSA's Suite B compliance for TLS. Specifically, from the cited URL, it states: Note that in order to support the GCM AEAD cipher suite in JSSE, the GCM cipher implementation is required in the JCA/JCE PKCS11 provider. So at this point, without having looked at the interfaces in JDK 7, I am not sure that one will be able to use GCM with AES when using the Cipher class. However, I will look more deeply. If nothing else though, it's a step in the right direction, so thanks for the pointer. -kevin -- Blog: http://off-the-wall-security.blogspot.com/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents. -- Nathaniel Borenstein ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] DIAC: Directions in Authenticated Ciphers
The DIAC submission page is now open, with a deadline at the end of Monday 7 May (American Samoa time): http://hyperelliptic.org/conferences/diac/iChair/submit.php DIAC is an ECRYPT-sponsored workshop that will take place 5--6 July in Stockholm, in particular evaluating the idea of a new competition for authenticated ciphers. The call for papers asks for submissions on new components, combinations, attacks, and implementations, but also asks for submissions discussing requirements---what users actually want. Submissions of panel proposals, white papers, lists of desiderata, etc. are encouraged, and there are no particular length requirements. I should emphasize that an authenticated-cipher competition would be much more than an AE mode competition. There are certainly people working on new ways to use AES, but there are many more people working on new authenticators, new block ciphers, new stream ciphers, new ciphers with built-in authentication mechanisms, etc. Zooko Wilcox-O'Hearn writes: authenticated encryption can't satisfy any of my use cases! Of course it can! Evidently you to want to combine it with public-key signatures, which will render the secret-key authenticator useless, so for efficiency you'd like to suppress that authenticator. This doesn't work well with something like AES-OCB3, but it _does_ work well with something like AES-GCM, giving you AES-CTR. There are clear engineering advantages to having an AES-CTR module that's reused by AES-GCM (for applications that want the authentication) and by Tahoe-LAFS. On the other hand, AES-OCB3 encrypts faster. If you help people see Tahoe-LAFS as part of this picture then you have a chance of influencing future work in a way that you'd find useful. Let me again emphasize that these AES modes are only one corner of the authenticated-ciphers topic. If we do in fact end up with hundreds of cryptographers working on authenticated ciphers for years then I wouldn't bet on AES (or GCM, or OCB3) being part of the final result. ianG writes: the cryptographer's push for AE mode is simply the creation of a more perfect hammer, when our real worries are about the building, not the nail. I agree that the building is in sorry shape, but you shouldn't paint an overly positive view of the current hammer. Here are a few recent and ongoing examples of failures of secret-key cryptography: * OpenSSH leaking some plaintext (Albrecht, Paterson, Watson). * OpenSSL DTLS leaking much more plaintext (AlFardan, Paterson). * TLS leaking cookies et al. (Dai, Moeller, Bard, Duong, Rizzo). * EAXprime (Smart Grid) allowing fast forgeries (Minematsu et al.). * Many breaks in encrypt only; authentication is too slow IPsec. * Keeloq door/car/garage RFID completely broken (Eisenbarth et al.). * More broken AES is too big RFID proposals: HB, HB+, etc. To summarize: Yes, non-cryptographic security is a disaster, but cryptography is a disaster too. :-) ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DIAC: Directions in Authenticated Ciphers
On Wed, May 2, 2012 at 8:00 PM, D. J. Bernstein d...@cr.yp.to wrote: I should emphasize that an authenticated-cipher competition would be much more than an AE mode competition. There are certainly people working on new ways to use AES, but there are many more people working on new authenticators, new block ciphers, new stream ciphers, new ciphers with built-in authentication mechanisms, etc. A few years ago Schneier proposed a cipher called Helix that, while broken, has some very interesting properties making it unlike any other cipher or cipher more I'm aware of. Zooko Wilcox-O'Hearn writes: authenticated encryption can't satisfy any of my use cases! Of course it can! Evidently you to want to combine it with public-key signatures, which will render the secret-key authenticator useless, so for efficiency you'd like to suppress that authenticator. This doesn't work well with something like AES-OCB3, but it _does_ work well with something like AES-GCM, giving you AES-CTR. Well, Zooko has an application that uses Merkle hash trees and really wants to authenticate only the roots of the trees, with all the leaves being encrypted without authentication. I think that's a perfectly fine design, assuming a strong enough hash primitive. It *is* AE, in a way, but it's not AE like GCM and it's intimately tied to Tahoe-LAFS' on-disk format. Git is very similar (though there's no built-in head signature scheme, IIRC, but it's perfectly possible to sign git hashes); git does use SHA-1, which is too weak for my taste, but aside from that the design is fine. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PKI in practice: is there a list of (widely deployed) client-certs-issuing CAs?
On 2/05/12 05:18 AM, Martin Paljak wrote: On Sat, Apr 28, 2012 at 05:25, ianGi...@iang.org wrote: Well, to the extent above. My db has a table for all certs, and a table for all users, with a join by cert identifiers between the two tables. I hope you actually bind the actual public key instead of any kind of identifiers? Binding the public key to the user name? No, I use the serial to indicate the cert identity [0] and I use the name to indicate the account. The reason for this is that fundamentally the CA makes a claim. I am sort of expecting that claim to be that the name is right, whatever that means. So, I should rely on that name. And public keys should be replaceable, as are the certs and other fields. In practice, what this means is that when a new cert comes along, I use some basic heuristics to analyse which account it belongs to, by for e.g., relying on the name or email address. However, the CA doesn't claim that the name is unique :) Nor does it claim that the email belongs to that person always, tomorrow, today or even yesterday. Nor does it claim that the person has only one name or one email ... Which brings me to part 2: this whole thing is an experiment in using client cert certificates in code to finesse the whole login experience away. (So, I'm also careful not to have high value data in there ;) ) Or would that not be against the single principle of an enduser controlling a private key, in which case the normal CA guarantee of a unique identifier (serial) under a given CA (which, in practice, should be out of picture) ? CAs are supposed to: * make the serial a unique identifier. Over on Mozilla lists that argument is going on, because the rules have recently shifted from probably serial therefore unique to hopefully unique, and now includes 20 bits of unpredictable uniqueness. I think this might be agreeing with your point - relying on fields written by corporate man might not be the smartest idea. * test for control of private key that matches the public key. * test for control of an email address, and/or holding of some documents that match a human name. Now, all these are part marketing claims, part hopes dreams. Rather than grumble more, what I and others had been doing was experimenting. We had a small community using client certs, and I knocked up a demo site. To test to see how hard or easy it was. In the end it is not hard. But it's not so hugely reliable, because of the inherent limit in PKI/CA claims. Be warned; don't let serious amounts of value ride on this stuff. Great for small / admin sites. And a whole lot easier to administrate than say passwords, once you get the cert into the user's browser. iang [0] Funnily enough, over on Mozilla I just recommended against doing this. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
