Live data from Hacker News

So, you want to crypto

blog.existentialize.com

31–40 of 75 posts

Re: So, you want to crypto

#31
post #26

I'm taking an Intro to Crypto course this spring. What's interesting is that it's offered through the Math department, and assumed it was a CS class. We'll be using this text: http://www.amazon.com/Introduction-Cryptography-Coding-Theor... Is this any good? Apparently a best seller in the "Software Coding Theory" category on Amazon.

I took an Intro to Crypto course offered through my University's Mathematics department and we used that exact text. I'm the kind of person that requires a very good text in order to do well in a course, and the book in question was of high enough quality that I did quite well. Although I thoroughly enjoyed the Mathematical focus of the course, my particular teacher spent a good deal of the course discussing semi-rel…

Mathematica can feel a bit clunky at first, but if Python comes with batteries included, then Mathematica brings its own power plant…

Re: So, you want to crypto

#32
post #10
post #3

>Do not let users use your product until it's been vetted. Its OK to let them use it so you can have a large user-base to test with, you just need to explain to them that it isn't proven secure. As in, explicitly tell them that they are under no circumstances to use it with sensitive information. Playing around with cryptography is the only way to learn it, you just have to remember to tell people that playing is exa…

Two things. First, while "playing around with cryptography" may be the only way to learn it, building cryptographic systems is just about the worst way to learn. Professional cryptographers start by cryptanalyzing targets and use that experience to inform their future designs. On the other hand, veteran implementors who have never taken the time to learn how to break crypto turn out protocols and designs that are rep…

You can see that right now with TLS and the TLS working group, which still hasn't fixed MtE block ciphersuites because veteran implementors can't get it through their heads that MtE is a design flaw.

Can't get it through their heads that MtE is a design flaw? You're more generous than I would be. At this point I'd assume that everybody knows that MtE is a design flaw, and anyone designing a protocol which uses MtE has made a deliberate decision to design a weak protocol.

Re: So, you want to crypto

#33

I think this quote from the article perfectly sums up the dangers of amateur cryptography: " Cryptography isn't something you can iterate on until you get it right, because you'll never know if you do. "

I feel like it's quoted from somewhere else, but the reference escapes me. At any rate, it's a great quote.

People who try the iterated design approach are especially frustrating. It ends up becoming a game of whack-a-mole with vulnerabilities, wherein an experienced cryptanalyst will point out an issue, the designer will say "oh! of course! let me apply a patch!", and then this continues to infinity. (This scenario doesn't necessarily indicate a bad approach, but it's certainly a symptom of iterated design.)

There's a particularly lovely story in Schneier's "Memo to the Amateur Cipher Designer" [1]:

> A cryptographer friend tells the story of an amateur who kept bothering him with the cipher he invented. The cryptographer would break the cipher, the amateur would make a change to "fix" it, and the cryptographer would break it again. This exchange went on a few times until the cryptographer became fed up. When the amateur visited him to hear what the cryptographer thought, the cryptographer put three envelopes face down on the table. "In each of these envelopes is an attack against your cipher. Take one and read it. Don't come back until you've discovered the other two attacks." The amateur was never heard from again.

Part of what makes it so frustrating, though, is that usually we want to be genuinely helpful. Building cryptosystems is fun (dangerously so!), and it's really crappy to end up saying "just scrap the whole thing" or what have you. But if you want to keep your sanity...

[1] https://www.schneier.com/crypto-gram-9810.html#cipherdesign

Re: So, you want to crypto

#34

Surely the correct answer is "just use keyczar"? At least 99% of the time.

Keyczar --- and other cryptographic libraries, mostly --- don't solve the issue of protocol design. They do let you choose the primitive you want, but it's still up to you to pick a mode of operation, make sure you use authentication (AEAD mode / MAC), initialize IVs/nonces/counters correctly, etc.

NaCl is very much a step in the right direction, but it's not an end-all solution either. Key management alone is a huge issue, for example, but virtually no library helps you out there beyond providing a basic toolkit. Of course, key management is very much in the realm of policy, so that's to be expected.

Re: So, you want to crypto

#35

>Both Applied Cryptography and the Handbook of Applied Cryptography are great resources, although they're a little dated now. ... Step one is to read Cryptography Engineering. This is not optional. Read it. It is a fantastic book that details how to use cryptographic primitives. It seems kinda superfluous to mention Applied Crypto when the real reco is to read Cryptography Engineering. I'd almost wonder if it would b…

Yes. Recommending Applied Cryptography is usually a warning sign that the person doesn't know what they are talking about. In this case the rest of the advice is reasonably sound for an engineer that wants to start learning the fundamentals of modern cryptography.

Re: So, you want to crypto

#36
post #19

The Matasano crypto challenges are a great place to start getting your feet wet and your hands dirty. http://www.matasano.com/articles/crypto-challenges/ Myself, I'm trying them in ANSI C

This is a good choice. One of the challenges had me stuck for months because I hadn't realised that you really need fine-grained control over bitshifting that e.g. Ruby doesn't appear to give you. Taking twenty minutes to re-write my solution to that challenge in C sorted it out straight away.

Re: So, you want to crypto

#37
post #19

The Matasano crypto challenges are a great place to start getting your feet wet and your hands dirty. http://www.matasano.com/articles/crypto-challenges/ Myself, I'm trying them in ANSI C

This is a good choice. One of the challenges had me stuck for months because I hadn't realised that you really need fine-grained control over bitshifting that e.g. Ruby doesn't appear to give you. Taking twenty minutes to re-write my solution to that challenge in C sorted it out straight away.

I'm presently stuck on #6 in problem set 1...

Re: So, you want to crypto

#38
> And don't make your cryptography project sound like snake oil. Saying military grade encryption or N-bits of security makes you sound like you don't know what you're talking about.

Interesting to contrast this with patio11's statement from just a few days ago (https://training.kalzumeus.com/newsletters/archive/sco_remin...):

> People are better at remembering images than they are remembering claims or facts. "256-bit SSL encryption" is a true fact about your software product, but for most customers it goes in one ear and out the other. "Bank-grade encryption" is an image -- people can envision the vault -- and is vastly more likely to be recalled favorably when someone is worried about security.

Re: So, you want to crypto

#39
post #19

The Matasano crypto challenges are a great place to start getting your feet wet and your hands dirty. http://www.matasano.com/articles/crypto-challenges/ Myself, I'm trying them in ANSI C

Well, it would be, except the pipeline seems to be clogged. I'm waiting weeks and months to get a response. Which is frustrating because the early problems are already really interesting, and I want more!

Re: So, you want to crypto

#40
I'm curious to hear people's thoughts about git. Git is "crypto" to some extent, Linus does not appear to have tons of crypto expertise, and it uses SHA1 as a MAC AFAICT (which according to tptacek's earlier comment is invalid). And yet I've never heard about attacks on its crypto.

This was interesting for me to think about because it seems like a counterpoint to the article, in that it is a very successful project that came about in a very "quick and dirty" way as opposed to starting with formal protocol design.

--

I see that Linus disclaims the idea that SHA1 is about security: "Git uses SHA-1 in a way which has nothing at all to do with security.... It's just the best hash you can get.... It's about the ability to trust your data. I guarantee you, if you put your data in Git, you can trust the fact that five years later, after it was converted from a hard disk to a DVD to whatever new technology and you copied it, five years later you can verify that the data that you get back out is the exact same data you put in."

But it seems like avoiding attacks like this must also be a goal: http://lkml.indiana.edu/hypermail/linux/kernel/0311.0/0621.h...

Post reply on HN