Hacker News Reader

Comment by jgrahamc | Hacker News Reader

There ought to be a way for people to get 'writing some crypto code' out of their system without it being a part of a real project. A sort of play area where you can have a go but not harm anything and people can point out your errors.

Every time I write something that involves some crypto I get absolutely terrified of what I'm likely to mess up. For that reason I almost always use an existing system or protocol. For example, on one of the projects I'm working on at CloudFlare we needed a secure connection across the Internet so I went with TLS 1.2. For another I needed the same thing but with better authentication: TLS 1.2 with client and server certificates. If I need to exchange encrypted messages in some store and forward style I'd likely use PGP.

And then for another project I needed to actually get something someone else had encrypted with RSA and decrypt it. Nightmare. If you find yourself calling low-level crypto APIs start to worry.

View on HN

"Every time I write something that involves some crypto I get absolutely terrified of what I'm likely to mess up."

Good!

" For that reason I almost always use an existing system or protocol."

Excellent! If only every was like you we wouldn't have these problems.

The key to understanding this is to understand that cryptography is not 'writing some crypto code'. No part of cryptography has anything to do with the code. Cryptography is about math - feel free to do some cryptography math and work on a mathematical algorithm. Once you have a perfect algorithm that has been peer reviewed, then you can transcribe that mathematical algorithm into code.

Failing to understand the math first means you have already failed and simply should not have even begun.

Cryptography: math first, code later. Failure to follow this sequence means you will be ridiculed and any excuse is simply not good enough.

Thank you for being the voice of reason. It's so easy to get confused, too, because "crypto code" is indistinguishable from "other code", but the implications are much greater. You don't need to peer review a IRC library, but you _need_ to peer review cryptography.

That's just how it is, and if I had to highlight one sentence from your comment it would be "Failing to understand the math first means you have already failed and simply should not have even begun."

I wish people would understand this instead of thinking trial and error works for cryptography. I mean, heck, most of us learned to code through trial and error, and I can understand why people think they can learn cryptography the same way, but that is not true, and a very toxic mindset.

I agree in general, but you are painting with too broad strokes here:

> No part of cryptography has anything to do with the code.

There have been successful attacks against cryptography based on attacking the implementation. For example if two code paths take different time to execute, it is possible that this leaks information.

This is another reason why you should use a well honed library implementation of cryptography, for example OpenSSL.

This does of course not imply that the crypto–the maths of it–is broken. One just needs to be aware that it is not, in fact, sufficient to implement the maths correctly.

You're correct, and I think that means I'm painting my strokes not broad enough. After you get your math peer reviewed, you then need to get your implementation of the math peer reviewed as well - likely by a low-level hardware engineer and not just some web developers.

Generally, however, nearly all failures of security come from misunderstanding the math when creating the implementation. So I'd say that at least ensuring anybody writing crypto has a completely understanding of the crypto math before touching the code is a very good first step in getting somewhere.

So what's the preferred route for an opensource project?

# TODO add crypto

# TODO get someone to review the crypto later

You could use a well established library. GPG or OpenSSL for example.

OpenSSL is fairly low level and still lets you shoot yourself in the foot. You can make the same mistakes as in the OP post.

I recommend Coursera's Crypto 1 course - it walks you through the internals of a lot of the crypto stuff, hammers "Don't do it yourself!" into you and there are programming challenges that involve breaking crypto constructions, finding hash collisions etc etc.

I'm really hoping crypto 2 actually starts in about 10 days as it seems to have been put back a lot.

--edit-- Just to sell it further, it also goes into padding oracles, timing attacks and a variety of clever stuff to show you just how easy it is to screw up :)

Oh, man, that course contained so much of "Do you see any problems with this construction? No? It can't possibly be vulnerable to anything, you say? Boom, here's how to break it completely".

My mind was blown on every course video.

Sadly, Crypto 2 seems to be delayed to Oct 15 now.

Awww, dammit. I was looking forward to that. I only checked a couple of weeks ago.

The Matasano crypto challenges ( http://www.matasano.com/articles/crypto-challenges/ ) are a great way to do this. Not by implementing crypto, but by breaking crypto in ways that will scare you away from ever implementing crypto.

I agree with your points here.

I think a major issue is the lack of understanding of best-practices with regards to security. So we tend to rely on the security of systems that aren't battle-proven. But even battle-proven solutions still have vulnerabilities, so we need to rely on multiple layers of security.

For me at least, this reinforces the lesson to put systems as much as possible behind multiple layers of security such as firewalls and VPN. And I should be careful to architect salt systems in a hub/spoke topology using salt-master and syndics. And encrypt any traffic from the salt-master to groups of servers using ssh tunneling. Looks like pyzmq now supports ssh tunneling, so maybe this would work:

http://zeromq.github.io/pyzmq/ssh.html

> If I need to exchange encrypted messages in some store and forward style I'd likely use PGP.

Do you or others have any recommendations for cross-platform library code (at least OSX, Windows, Android, Linux, Windows 8) for this purpose?

I may have understood incorrectly, but I thought that using gpg from code required launching a sub-process (e.g. via gpgme). That makes me very nervous from a library point of view, perhaps I'm wrong to be nervous.

Is the answer still "use PGP/GPG" or is there somewhere else I could look to avoid home-made cryptosystem here?

GPG actually has a library with all the crytographic primitives in it called libcrypt: https://en.wikipedia.org/wiki/Libgcrypt

If you want the PGP-level stuff then there's GPGME: http://www.gnupg.org/related_software/gpgme/index.en.html

Thanks for that. But afaics, libgcrypt seems to be on a similar level of abstraction as the openssl lib? i.e. implementations of ciphers etc. I then fall into the mistake of http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.h... I think? [linking to berkely.edu because the page seems to have gone from matasano.com?]

And I think GPGME is a lib which "under the hood" spawns a command-line gpg process? http://www.gnupg.org/faq/GnuPG-FAQ.html#cant-we-have-a-gpg-l...

At the moment it looks like my choice is between implementing a cryptosystem on top of crypto primitives (from openssl or libcrypt) or seeing if I can get away with shipping a lib which spawns child processes via gpgme.

Ironically, there is a high-level crypto library with sane defaults that is pronounced "salt" (it's spelled NaCl though)

Reply on news.ycombinator.com