Re: What if you had a very good patent lawyer...
It's pretty outrageous that anyone would try to patent rolling barcoded dice to generate random numbers. I've been generating random strings from dice for years. I find that gamers' 20-sided dice are great; each roll gives you a hex digit, and anytime you roll a 17 thru 20, you just roll again. One die will do; you just roll it as many times as you need hex digits. Presumably pointing a camera at ordinary dice could automate the data collection -- hey, wait, let me get my patent lawyer! John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Peter Gutmann wrote: Readers are cordially invited to go to https://edgecastcdn.net and have a look at the subjectAltName extension in the certificate that it presents. An extract is shown at the end of this message, this is just one example of many like it. I'm not picking on Edgecast specifically, I just used this one because it's the most Sybilly certificate I've ever seen. You'll find that this one Sybil certificate, among its hundred-and-seven hostnames, includes everything from Mozilla, Experian, the French postal service, TRUSTe, and the Information Systems Audit and Control Association (ISACA), through to Chainlove, Bonktown, and Dickies Girl (which aren't nearly as titillating as they sound, and QuiteSFW). Still, who needs to compromise a CA when you have these things floating around on multihomed hosts and CDNs. [...] What a mess! A single XSS/XSRF/XS* attack, or just a plain config problem, and the whole house of cards comes down. Please don't mistake the following comment for a defence of any aspect of current PKI practice, but: I'm not seeing how an XSS or XSRF attack on one of the domains named in this certificate would enable attacks on the other domains. IIUC, if you resolve one of the domains that is a client of Edgecast, say www.mozilla.com, then you may get an Edgecast proxy server that will serve content over TLS on behalf of that domain. Clearly if you compromise such a proxy, then you get the ability to spoof any of the domains named in the certificate. But if you do some origin-based web attack on a particular domain, then you can only spoof that domain. And even if you have a full compromise of a server for one of the domains, that doesn't get you the private key for the certificate, which is held only by the proxies. Or am I missing something? -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com signature.asc Description: OpenPGP digital signature
Re: Encryption and authentication modes
* David McGrew: can I ask what your interest in AEAD is? Is there a particular application that you have in mind? I just want to create a generic API which takes a key (most of the time, a randomly generated session key) and can encrypt and decrypt small blobs. Application code should not need to worry about details (except getting key management right, which is difficult enough). More popular modes such as CBC lack this property, it's too easy to misuse them. I suppose a superficially similar primitive is contained in Bernstein's NaCl library. I was intrigued by its simplicity, but the cryptographic algorithms it uses are a bit non-standard. Right now, I would probably use it to forward session state through browser URLs in areas which are not actually security-relevant. Somewhat more sensitive applications are possible in the future. In no case I expect adversaries to actually have access to ciphertext. To some degree, it's about being able to say yes, we use encryption for X, and it's algorithm Y, and I want to do it right without using CMS or modern OpenPGP, with all the complexities that come with that. When I said that CCM wasn't widely implemented, I was referring to the fact that none of the cryptographic libraries on my system supports it directly. This is a pity because once you fix the parameters, it's much simpler to use safely than pure encryption modes. There seems to be one downside with the CCM instance specified towards the end of the NIST standard, though: If you on an architecture where sizeof(size_t) == 8, then your encryption function isn't total because it can't accept the full range of possible input lengths---or you end up with just 64 bit for the tag, which seems to be a bit on the small side. I'm not sure if this is a compelling reason to use EAX or GCM, though---especially since we're strictly limited to 31 bit array length in some places by software and not hardware (so this limitation will be in place for a long time). A mode which does not rely as much on proper randomness for the IV would be somewhat nice to have, but it seems that the only choice there is SIV, which has received less scrutiny than other modes. OCB is very attractive in software, but GCM is more efficient in hardware because it can be implemented without pipeline stalls. GCM can perform well in software, though it can't be as compact as CCM, and it excells with SIMD (http://eprint.iacr.org/2009/129) or modest hardware support like Intel's new PCLMULQDQ instruction (http://www.drdobbs.com/security/218102294;jsessionid=GMTY4RCFLHBMRQE1GHOSKHWATMY32JVN?pgno=3 ). Interesting. But it will take about five years until our crypto code would make use of a new hardware instruction, assuming that we'd implement all the necessary pieces right now (thanks to desynchronized software release cycles at several layers of the software stack). Speed is of no particular concern anyway. Increase in message size is somewhat relevant (think about the URL case I mentioned), but only to up to a degree. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
From an off-list discussion: Can someone who knows more about how these CDNs handle certs provide a brief summary for the list? From looking at Sybil certs grabbed from a few CDN sites there doesn't seem to be any rhyme or reason to them. Also, how and under what conditions can you get access to the CDN as an insider? I'd found ads like http://www.webhostingtalk.com/showthread.php?t=873555, Resell the Edgecast CDN and make a killing!, which seem to imply that anyone with a chequebook can play. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Looks like the CDN certificate is already causing security problems, although not the kind that I was expecting: While trying to import a server certificate for a CDN service, a segv bug was found in [PKI app]. It is likely that this bug is exploitable by sending a special crafted signed message and having a user verify the signature. Hmm, I wonder if this particular certificate happened to be one with 107 subjectAltName entries? Description Importing a certificate with more than 98 Subject Alternate Names via import command or implicitly while verifying a signature causes [...]. Yup :-). So if nothing else it's a good stress test for your certificate- parsing code... Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
