28 ms·
Everything you need to know about cryptography in 1 hour (2010) [pdf]
- sotte 12y agoHere is the video of the talk: http://www.fosslc.org/drupal/content/everything-you-need-know-about-cryptography-1-hour http://www.fosslc.org/drupal/content/everything-you-need-kno...
- afandian 12y agoThe comments say that there's an Ogg download but I can't find it. Any pointers?
- dfc 12y agoSomeone posted the bliptv link above: http://blip.tv/fosslc/everything-you-need-to-know-about-cryptography-in-1-hour-3646795 http://blip.tv/fosslc/everything-you-need-to-know-about-cryp... $ youtube-dl http://blip.tv/blahblah $ ffmpeg -i file.flv file.ogv
- techpeace 12y agoVideo link: http://blip.tv/fosslc/everything-you-need-to-know-about-cryptography-in-1-hour-3646795 http://blip.tv/fosslc/everything-you-need-to-know-about-cryp... Previous discussion here: https://news.ycombinator.com/item?id=1346711 https://news.ycombinator.com/item?id=1346711 And here: https://news.ycombinator.com/item?id=2253336 https://news.ycombinator.com/item?id=2253336
- mmastrac 12y agoHe recommends HMAC-SHA256 in this paper, but I think that AES-GCM is a better construction, as long as you understand the requirements for IV uniqueness. It offers significant improvements on top of the standard HMAC (privacy and additional out-of-band data) without adding much in terms of size.
- zatkin 12y agoWould HMAC-SHA256 been a better recommendation in, the year that this presentation was given, 2010?
- dchest 12y ago"Just reviewed my "crypto in 1 hour" talk slides in preparation for giving this talk on Wednesday. 4 years after writing, no updates needed." -- https://twitter.com/cperciva/status/475359526145646593 https://twitter.com/cperciva/status/475359526145646593
- dchest 12y ago"And I still maintain that recommendation. CTR+HMAC is far more robust against side channel attacks than any AE mode." -- https://twitter.com/cperciva/status/475360367191674881 https://twitter.com/cperciva/status/475360367191674881
- tptacek 12y agoI think Colin has a hard row to hoe with this argument, given how often HMAC implementations cough up timing vulnerabilities. Even if you're stuck with GCM, GCM has the advantage of having mercifully few implementations. Everyone writes their own HMAC verifiers (badly).
- deleted 12y ago[deleted]
- nly 12y agoI think you're confused? AES-GCM is an authenticated encryption mode. HMAC-SHA256 is just a cryptographic MAC. The two only share the same applications when the latter is combined with a non-authenticated encryption mode in an Encrypt-then-MAC construction. The problem with the polynomial AE modes is they are trickier to implement (AES is actually small, as is SHA).
- asciimo 12y agoHere's a provocative gem: > The purpose of cryptography is to force the US government to torture you.
- cperciva 12y agoIt's pretty simple -- if the US government really really wants your secrets, they can kidnap you and torture you until you tell them what they want to know. Cryptography can protect data, but it doesn't protect humans; all it can do is make sure that humans are the only remaining point of attack.
- mseebach 12y agoThat's not entirely true. Proper cryptography can keep them from learning that it's you they'll need to kidnap to get the secret, or even keep them from learning that there is a secret they might care about in the first place. Also, there are plenty of bad guys in the world that can't kidnap and torture you that it's still quite worthwhile to keep your secrets from.
- cperciva 12y agoYou're over-thinking this. The point is simply that no matter how good the cryptography in a system is, if there are humans involved then you need to worry about human factors as well.
- peterwwillis 12y agoThe easiest way to avoid the human factor is to get a scapegoat. You make it seem like someone else is responsible for, or knows about, the crypto or its data payload. They will then torture that individual indefinitely until they confess to something. It's better if they don't know you or anything about your scheme as that way it'll look like they're holding out a really long time on important information. Then the only thing you need to worry about is that person dying, in which case the investigation continues. So similar to upping the number of rounds on PBKDF2 every year, you need a new scapegoat every year, or however long it takes them to break either the crypto or the scapegoat.
- cperciva 12y agoThe reason this is being (re)posted now is that I gave this talk at a Polyglot Vancouver meetup last night. Freed from the constraint of a conference schedule I actually took about 90 minutes to go through this talk this time (followed by another 30 minutes of questions).
- zatkin 12y agoAs someone who is completely new to cryptography and knows very little, where would you recommend I start? I've recently been reading about bitwise operations to become familiar with how to (somewhat) interpret what a cryptograhic algorithm is doing in a program, since bitwise operations seems to be popular in almost all crypto algorithms.
- epsylon 12y agoDan Boneh's free "Crypto 1" on coursera. A new session will be starting on the 30th of June. I've taken it myself and this is hands down one of the best MOOCs (and class overall) I've ever taken.
- uulbiy 12y agoI agree, "Crypto 1" was excellent! On Coursera's website, in the upcoming section, it says that "Crypto 2" starts in 3 months. I hope that's true!
- deleted 12y ago[deleted]
- Tomte 12y agoIt hasn't been the last, oh... four times or so?
- leigh_t 12y agoIt was indeed an excellent course and for any would-be participants I recommend buffing up on discrete mathematics and number theory already if they're not your strong suit. I found the course pretty hard as programmer with a strong interest in crypto, but no formal CS/maths background. The coding pieces were fairly straightforward, but the maths hurt.
- drewcrawford 12y agoWould be interested in hearing more detail about your objections to both Poly1305 and ECC.
- cperciva 12y agoToo many ways to screw things up, not enough decades of cryptographic analysis, and there are simpler tools available which have been around for longer. This is subject to the caveat that ECC offers benefits under certain specific conditions (e.g., you need small signatures or a small ASIC die area); but in those situations you want to talk to a cryptographer anyway. My talk was providing guidelines for software developers who are writing code for general-purpose PC hardware.
- robryk 12y agoWhat are your thoughts on using NaCl? On one hand it gives harder-to-misuse primitives, on the other is uses elliptic curve crypto.
- tptacek 12y agoI'm not sure how anyone can look at OAEP and call RSA "simple". Worse still: very few people will ever implement their own ECC code, but lots of people will use RSA implementations that more or less just expose the RSA primitive and fob "encoding" off on the developer.
- lisper 12y ago> PROBABLY AVOID: Elliptic Curve signature schemes. Including Ed25519?
- cperciva 12y agoProbably. As I said elsewhere, this is subject to the caveat that sometimes you need the performance characteristics of ECC; I'm providing advice for general-purpose computing environments which do not have any such constraints.
- lisper 12y agoNot that I really feel comfortable challenging you on anything crypto related, but it seems to me that Ed25519 is superior to RSA in every conceivable way even for general-purpose computing environments. It's more performant, easier to generate keys, the signatures are shorter, and there are fewer ways to shoot yourself in the foot (e.g. no padding issues). Is there a reason you don't actively advocate it other than the fact that it's not widely used?
- api 12y agoThis PDF is a tiny bit old, so I wonder what they'd say today. I guess it depends on how conservative you want to be. RSA has been through a ton of cryptanalysis and peer review and has stood the test of time. Ed25519 is newer. It's highly regarded but hasn't been analyzed as much or used as heavily so you're taking a bit more of a risk.
- scott_karana 12y agoThere weren't any "Don'ts" about compression. Is that solely an SSL/TLS concern, or is it generally applicable to cryptosystems?
- api 12y agoI used Poly1305, but exactly in the way Daniel J. Bernsetein used it in his NaCl library. I also used his ECC signature scheme, also in exactly the same way. :) As far as I can tell the gotcha with Poly1305 is that you absolutely cannot reuse the same key ever. His construction involves using your keyed cipher to create 32 random bytes by encrypting 32 zero bytes before encrypting the actual message. These random bytes are then used as the one-time-use Poly1305 key. In NaCl he does this with either Salsa20 or AES-CTR, both of which are stream ciphers. (CTR converts a block cipher into a stream cipher.)
- maxtaco 12y agoGood suggestion to avoid PKCS v1.5; sadly PGP requires it: http://tools.ietf.org/html/rfc4880#section-13.1 http://tools.ietf.org/html/rfc4880#section-13.1
- Spearchucker 12y agoThanks for sharing the slides (and techpeace for the links to the video). A question I have though is given that we (those of us who collectively don't identify ourselves as security rocket-surgeons) are always advised to stick with the high-level stuff and to stay away from stuff like AES (ref. slide 16), which nobody does anyway, then why is no mention ever made of established and known protocols? Examples like - Needham-Schroeder (fixed version), http://en.wikipedia.org/wiki/Needham-Schroeder_protocol http://en.wikipedia.org/wiki/Needham-Schroeder_protocol - Otway-Rees, http://en.wikipedia.org/wiki/Otway%E2%80%93Rees_protocol http://en.wikipedia.org/wiki/Otway%E2%80%93Rees_protocol have proven to be really useful. Yes, there's a metric ton of work involved in implementing something like this, but going through it once is amazing practice for getting it right in future (that, at least, is my experience). Why is it that we talk about symmetric and asymmetric encryption, but never go as far as the protocols that provide real context for their uses?
- tptacek 12y agoI disagree with two big points in this talk, but I'm sorry to say they're the same two things I disagreed with last time, so this is going to be a boring comment. First, dedicated AEAD cipher modes are superior to manually composing AES-CTR and HMAC-SHAx. AEAD modes provide both authentication and encryption in a single construction. AES-CTR+HMAC-SHAx involves joining two constructions to do the same thing. Colin points to AES-GCM, the most popular AEAD mode, as an example of how AEAD modes can be more susceptible to side-channel attacks than AES-CTR+HMAC-SHAx. I don't think this is a strong argument for a couple reasons: * AES-GCM is so far as I can tell no practical cryptographer's preferred AEAD mode; "whipping boy" might be a better role to ascribe to it. * AES-GCM's side-channel issues are due principally to a hardware support concern (GMAC, AES-GCM's answer to HMAC, requires modular binary polynomial multiplication, which in pure software is table-driven, which creates a cache timing channel). That hardware support concern might be receding, and platforms that don't have AES-GCM might prefer a different AEAD mode anyways. * Modern AEAD modes, of the sort being entered into CAESAR, have resilience against side channels as a design goal. * But the most important rejoinder to Colin's preference for HMAC-SHAx over AEAD modes is this: HMAC-SHAx is responsible for more side-channel flaws than any other construction. Practically every piece of software that has implemented HMAC-SHAx has managed to introduce the obvious timing channel in comparing the candidate to the true MAC for a message. What's worse is, using AES-CTR+HMAC-SHAx in practice means that the developer has to code the HMAC validation themselves; it's practically an engraved invitation to introduce a new timing leak. Almost nobody codes their own AES-GCM. I also think Colin is wrong about ECC, particular versus RSA. RSA might be the most error prone cryptographic primitive available to developers. There are two big reasons for this: * RSA has fussy padding requirements. The current best practices for RSA encryption and signing are OAEP and PSS (huge credit to Colin for getting this right in 2010). If you want to form an opinion about RSA, go read up on OAEP and ask yourself (honestly) if you would come up with anything resembling OAEP if you were called on to encrypt with RSA. Developers as a rule do not use OAEP; instead, most new software still uses PKCS1v15 padding, which introduces susceptibility to terrible vulnerabilities that can often be easily exploited in the wild. Even better are the Javascript developers who build RSA from first principles and skip the padding altogether (the fact that RSA padding is a requirement and not an annoyance to be avoided is why Nate Lawson says we should call it "RSA armoring" and not "RSA padding"). * RSA easily supports a direct encryption transform, which is widely used in practice. ECC software as a general rule does not synthesize an encryption transform from the ECDLP; instead, ECC software uses the ECDLP to derive a key, and then uses something like AES to actually encrypt data. You might be thinking, "that's how RSA software works too". But RSA in practice is subtly different: you can, for instance, easily encrypt a credit card number directly using RSA, or build a crappy key exchange protocol where the client encrypts (doesn't derive or sign, but encrypts) a key for the server. RSA and conventional DLP crypto therefore offer (encrypt, key-exchange, sign); ECC in practice offers just (key-exchange, sign). That's one less dimension of things developers have to get right in ECC cryptosystems. Colin is smarter than me and much better trained in cryptography than I am. All I do is find and exploit crypto bugs in real software. I am usually as nervous as any of you are to challenge Colin about crypto, but I think I can win these two arguments. (Spoiler alert: Colin doesn't think so).
- graycat 12y agoHe doesn't know how to write even simple mathematics. E.g., he uses symbols n and k without definition. Without careful definitions right there in the context, such symbols mean nothing. He is not clear enough about what he means by x. His lack of precision in his writing lowers confidence in the quality of what he has written.
- cperciva 12y agoHe doesn't know how to write even simple mathematics. Umm...
- graycat 12y agoIf you know how to write math, then do so. In particular, define your symbols. Nearly none of your symbols are defined.
- DanBC 12y agoYou know that this is a presentation, right? And that the symbols will be defined in the talk? There are better ways to ask someone to define their symbols.
- graycat 12y agoIt's simple: Instead of just n, write "For a positive integer n". Instead of just k, write "For a key k". It's simple. Look, guys, 'n' just does not abbreviate 'integer', and 'k' does not abbreviate 'key'. Yes, yes, yes, I know; I know; and we should all know, that while too often people write, say, O(ln(n)) saying nothing about either 'n' or 'O', it's darned bad mathematical writing. If in some context n is a positive integer, then in that context it is just necessary to say so. Read math from calculus to Halmos, Rudin, Dunford and Schwartz, Spivak, Lang, to Bourbaki, and will find that symbols are always defined; good authors just do not have undefined symbols hanging around. It's just not done. Now you have learned something important. Sorry some people didn't know.
- NAFV_P 12y agoDisclaimed: I know sweet f-a about cryptography, and was expecting 100% of this pdf to go straight over my head. On the other hand, why is the author using "i++" in a preamble of a for loop?
- bazzargh 12y agoThat's the style in C-like languages. http://en.wikipedia.org/wiki/For_loop#C.2FC.2B.2B http://en.wikipedia.org/wiki/For_loop#C.2FC.2B.2B ... also used in Java, Javascript, Perl, Php, Bash (and many more I'm sure).
- NAFV_P 12y ago> That's the style in C-like languages. That style is in many cases inefficient. /* summation of successive integers */ /* don't worry, this should not cause overflow in a 32-bit signed integer type */ volatile int i=0; int j=0; for( ; i<65536; i++) /* ++i is better suited to this scenario */ j+=i; Being declared as volatile, the compiler will not attempt to optimise the for loop and change the code that increments i in the preamble from postfix to prefix. I will admit this is an extreme example, but I often see examples on the internet of simple for loops written in this manner when prefix is more suitable and simpler for the cpu to execute. Postfix increments of integer types involve making a local copy (y) of the variable to increment (x), then incrementing x and returning y. Prefix increments merely involve incrementing x. The former method is rather expensive. On the other hand, it would make sense to use postfix on something like [0]. [0] http://en.wikipedia.org/wiki/Duff's_device#Original_version http://en.wikipedia.org/wiki/Duff's_device#Original_version
- pbsd 12y agoHave you actually tried your example? Even at -O0, it results in the exact same code: http://goo.gl/kDEFnU http://goo.gl/kDEFnU
- deleted 12y ago[deleted]
- Nimi 12y ago"""Conventional wisdom: Don't write cryptographic code! Use SSL for transport"" Honest question here: suppose I have a webapp with multiple servers, being load-balanced through Amazon's ELB. This sounds about as standard as it can get. Question is: how does one handle client migration between servers, and client authentication, without writing cryptographic code or knowing anything about cryptography? (apologies if this is trivial)
- aianus 12y agoSSL usually terminates at the load balancer. A quick googling found this guide to setting up SSL on ELB: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/ssl-server-cert.html http://docs.aws.amazon.com/ElasticLoadBalancing/latest/Devel...
- Nimi 12y agoYes, but what happens to the client authentication when it migrates between servers? Do I write a cookie to the client saying "authenticated as user X"? Encrypt the cookie? Sign the cookie? It sounds one would need to write cryptographic code to do that...
- aianus 12y agoYou write a cookie to the client containing some random key and associate that key to the user on your backend in the shared db. Since it's just random data, you don't need to sign or encrypt the cookie and SSL takes care of protecting it in transport.
- Nimi 12y agoDoes this random value need to be unpredictable? And leaving this specific example aside for a moment, I was trying to prove a larger point: people write crypto code for a reason. Some people will write it for no reason at all, yes. A lot of other devs will be dying to save themselves the time it will take to write any type of code, especially if it has to deal with something they aren't experts in, but they just can't. Now, it seems likely you and I can hash out the details of an acceptable solution in this discussion (in fact, I think once you take the steps to make sure the random source isn't predictable, you're good, but even this is slightly crypto-related), but how would the average developer know this? How would he go from "don't write crypto code" to this? In my humble opinion, simply saying "don't write crypto code" isn't a solution, and there are good reasons why this hasn't worked so far.
- drdaeman 12y ago> DON’T: Put FreeBSD-8.0-RELEASE-amd64-disc1.iso and CHECKSUM.SHA256 onto the same FTP server and think that you’ve done something useful. Actually, this is a bit wrong - it's just that this is not cryptography and security-related and doesn't have anything to do with authentication. It's the same reason why some fansubbers still include CRC32 into filename - basic unauthenticated integrity checking. Totally insecure, but still better than nothing. I had case where downloaded file was broken - for some weird case either software, storage or a network had failed but TCP/IP checksumming didn't help and the fact was, I had wrong bits on the hard drive. I hadn't broadband connectivity at home and that cryptographically-pointless CHECKSUM.SHA256 (well, actually it was MD5) helped to find that out before I left the library. And recently, the same concept had helped me to validate files with a faulty cloud storage service that managed to lose some chunks and silently replaced them with zeroes when I tried to download the data back. Obviously, a signed file stored on another server would always be a better idea. Just nitpicking.