6 ms·
If you set up your own CA and you distribute a CA keyring with only that CA key, you avoid the what-about-China problem. But you still have a heck of a lot of m
by smanek 17y ago
If you set up your own CA and you distribute a CA keyring with only that CA key, you avoid the what-about-China problem. But you still have a heck of a lot of moving parts which can break.
It's not fun - but I have done it before. I would still contend that setting up a CA and distributing a keyring is easier and less likely to be insecure than trying to write actual secure crypto code (at least for most normal coders like myself - people like djb or cperciva are excluded ;-)).
You should come to my conference talk, "everything you need to know about crypto in 1 hour". :-)
Boy, I wish something like that existed. Every time I'm starting to feel like I know something, I learn about a new type of attack (a side-channel that leaks more than I thought possible, a length-extension that apparently violates the oversimplified hash properties I knew, etc) that makes me feel like an idiot.
- cperciva 17y agoYou should come to my conference talk, "everything you need to know about crypto in 1 hour". :-) Boy, I wish something like that existed It does! I'm giving that talk at BSDCan'10 in May: http://news.ycombinator.com/item?id=1179569 http://news.ycombinator.com/item?id=1179569
- smanek 17y agoNice - I thought you were being sarcastic! I don't know if I can make it in person, but I sure hope they tape it and put it online :-D
- cperciva 17y agoIf nothing else, I'll put my slides online -- but coming in person would give you the opportunity to hear me speak and ask questions at the talk, too.
- iamwil 17y agoSweet. I'll be looking forward to the slides, or if there's a video of the talk. I feel like I don't know enough at all about security.
- khafra 17y agoIf you can make it in person and record the talk, I hope you put it on line. BTW, an intelink search didn't return anything for "postabon" except a soft drink firm.
- wizard_2 17y agoWish I could make that too, but Ottawa is a little out of my travel budget this year. Also, I'm only going to get to goto one or two conferences this year and I'm not that interested in BSDCan since I don't use free BSD beyond my wireless router. I enjoy reading your writings, so I'm looking forward to your video/slides. =)
- briansmith 17y agoIs the content going to be much different than your "Cryptographic right answers" post?: http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html http://www.daemonology.net/blog/2009-06-11-cryptographic-rig...
- cperciva 17y agoMy talk is basically an expansion of that blog post.
- briansmith 17y agoIt would be cool if you would expand more on your preference for RSA and AES-CTR-HMAC instead of ECC and AES-GCM. Since ECC and AES-GCM are in NSA Suite B, I expect that eventually they will replace RSA and AES-*-HMAC, so why shouldn't applications start using ECC and AES-GCM now?
- cperciva 17y agoRSA vs. ECC: This basically comes down to "ECC is complicated and you're going to screw it up". AES-CTR-HMAC vs. AES-GCM: While GCM is better than some of the other combined authenticated-encryption algorithms, it's (a) rather complex (128-bit finite field math is messy), (b) exposes you slightly to a side channel attack on your block cipher, and (c) is no faster than AES-CTR-HMAC, so why bother?
- briansmith 17y agoThe arguments for ECC are (a) it is much more efficient than RSA so you can use stronger keys at less cost, (b) ECDHE is so much faster than DHE (over the integers mod Z) that ECDHE becomes practical in situations where DHE wasn't, (c) it is in NSA Suite B, (d) the major crypto libraries already implement it. The arguments for AES-GCM: (a) AES-GCM and AES-CCM are the only standardized CTR modes in TLS, (b) you can implement AES-GCM efficiently in constant time (see http://www.cryptojedi.org/papers/aesbs-20090616.pdf http://www.cryptojedi.org/papers/aesbs-20090616.pdf), (c) it is the NSA suite B cipher mode, (d) the alternate mode for AES in TLS (AES-CBC-SHA) requires a new initialization vector for every TLS record, which means that you need to get 128 bits of from your PRNG for every 16KB of data transfered, whereas AES-GCM mode only requires 128 bits total per connection. A strong argument against GCM mode is that OpenSSL, NSS, and the Windows CryptoAPI (prior to Windows 7/2008R2) do not implement it yet. Do you have a link to something that shows that AES-CTR-HMAC-SHA-256 is really faster than AES-GCM? That is something I've always wondered about. Since you'll be at a BSD conference, I bet you won't get too many people questioning your suggestion to use OpenSSL. But, in the Linux world it seems there's a big push by Red Hat, SuSe, and other enterprise Linux vendors to replace OpenSSL with NSS in every application they support, because of NSS's huge advantages over OpenSSL w.r.t. FIPS-140 validation.
- weihan 17y agoNice! I like your post Colin and will try to attend the conf and shoot the video for those who can't make it, if the conf doesn't make the video for you (hope there isn't copyright infringement though)