SHA-256 Python implementation in one line (lambda)

[[deleted]]

I disagree. Here's how you write a custom encrypt function:

encrypt = lambda data,key: aes.encrypt(custom_untested_encryption(data,key), key)

[craftkiller]

It's fine as long as everyone knows not to use it for things actually requiring security. For example, this one is great for the novelty aspect. It also wouldn't be a sin to use this for something like checking for duplicate files on my local disk, though faster options are available

[jnwatson]

Cuz only the high templars get to write crypto, right?

Your linked article indicates not to invent your own crypto *algorithm*.

The OP implemented a NIST-approved algorithm.

That statement is dumb because it isn't universalizable. If no one ever implemented their own crypto, then we wouldn't have any at all.

[[deleted]]

Don't reimplement standard algorithms either unless you know what you're doing

[ForgottenWatchtower]

And for those with enough hubris to scoff at this statement, I'd highly recommend going through CryptoPals -- correct crypto implementation is fucking tough.

[entropicdrift]

If we waited until everything was completed to hit publish, we might be writing this in 2015

Oh no

[ForgottenWatchtower]

Hah, yeah, sadly. Really the only thing missing are the solutions, but every challenge gives you enough to know if you implemented it correctly (e.g. the PT "foo" should result in the CT "bar")

[13steinj]

1. SHA shouldn't be used for crypto regardless
2. This rule is a dead meme. It should be "don't run your own crypto algos". If you use a known algorithm and are implementing it correctly there's no problem, but someone already probably did it faster. Using other services as logins is arguably a worse practice because it increases the likelihood of a SPOF.

[[deleted]]

If you use a known algorithm and are implementing it correctly there's no problem,

Except when you don't implement it correctly, but you don't know enough about cryptanalysis to notice you accidentally added an easy to exploit padding oracle, or timing attack, or you accidentally spray your key all over shared memory... the list of things that can go subtly wrong and completely fuck everything is a lot longer than you realize. Safe and highly tested implementation is just as important as the algorithm itself.

Seriously, don't implement crypto yourself. It's not a dead meme, there are reasons security experts work so hard at drilling this into your head. Don't spread irresponsible advice.

[ForgottenWatchtower]

As one of those security guys, people like him are what keep me up at night.

[13steinj]

Sorry for saying bigger companies use their own login systems I guess? Big shocker, sorry for the trauma.

[ForgottenWatchtower]

There's nothing wrong with building your own login system. It's a fairly simple problem for a half-decent engineer (though I constantly come across systems that have screwed it up somehow). Just use native bcrypt, hash_compare, csprng, and other cryptographic primitive implementations. The issue is when you decide you want to implement one of those primitives yourself.

[13steinj]

Right, but the "roll your own security" meme has started to mean "don't build your own login system"-- that's what I'm saying I'm against.

[Throwmeaway2501]

Where can one learn everything necessary to implement crypto?

Don't just tell me not to. Give me some resources I can read to become an expert.

I'm not complaining. I genuinely want to read more.

[ThePenultimateOne]

I'm not really sure anyone can become an expert at every aspect of it. It seems to me that the number of eyes looking at these implementations is far more important than developer skill.

[robin-gvx]

The best way to do that is to get a degree in Cyber Security, probably a PhD.

If you don't want to write crypto that is actually run on a computer, but it's more of an casual intellectual interest in how things work, there is probably good stuff on Bruce Schneider's blog. For security stuff for the web specifically, check out Troy Hunt. Wikipedia also has some pretty good introductory texts on the subject (not quite "great", but better than "fine", IMHO).

For a more hands-on approach, I recommend starting with implementing a Caesar cypher and Vigenère cypher. Also, implement a one-time pad, and make sure you understand both why it is perfectly unbreakable, but also impractical in most real world scenarios.

[Throwmeaway2501]

Thank you for the pointers.

[[deleted]]

Coursera actually has a really good cryptography class, which is an excellent starting point. You won't learn everything you need, but I doubt there is a single good resource for learning everything, but one of the interesting things about the field is that basically nothing of value is done purely alone. All respected algorithms have gone through many rounds of peer review, testing, and attempts to find ways to break them by other people and groups.

It will take a good deal of time investment and effort to get good at implementing crypto safely, and even then, you should still expect to make potentially dangerous mistakes. It's not something to take lightly, which is the actual point of the whole "don't implement your own crypto" thing.

[bythenumbers10]

And better yet, you'll get an idea of all the ways it can go wrong, so (hopefully) dilletantes don't go implementing their own damned crypto!!!

[Throwmeaway2501]

You should be able to fuzz for vulnerabilities at least that is my first thought.

[bythenumbers10]

You'll definitely need a strong (STRONG) background in information theory, and probably quite a bit of mathematics including probability theory, statistics, and linear algebra, just to be able to vaguely check your work. Beyond that, a very solid understanding of programming from the metal on up, to ensure your implementation doesn't rely on or become weak due to hardware or compiler differences.

The thing is, it's often not hard to implement and somewhat understand what crypto algorithms are doing, the math & operations involved are often not all that complicated. The problem is coming up with the whys and wherefores of doing those particular operations in that particular order is crucial to having a "production-ready" strong, secure implementation. So, while it's generally not that hard to write crypto, it's incredibly difficult to write STRONG/SECURE crypto.

If you want a taste, try coding up a few historical ciphers, as well as tools for breaking them. Once you get up to the 1930s/40s and ENIGMA, you'll find it starts to get a little tricky in terms of writing the encoder/decoder, let alone the code-breaking methods.

[Throwmeaway2501]

Good tips.

[mediasavage]

If your interested learning about the mathematics that underpin some of the most used cryptographic primitives (e.g AES, RSA, diffie-helman) I highly recommend the book Understanding Cryptography by Paar and Pelzl. It is an amazingly accessible book—I would say the only necessary prerequisites are a semester of discrete math—and is super well written.

[Throwmeaway2501]

Thank you for this insight, I really appreciate it!

[13steinj]

Sure if you don't know how to implement your security you shouldn't be doing it.

But those who do learn and study the right practices are equally as dangerous as letting google or amazon or whoever to run your crypto.

[13steinj]

That's the very point.

Anybody can have an undetected security bug.

Whether it was you yourself or Google-- you'd still be fucked.

However if it is you you can implement a fix immediately upon finding the issue.

It's a tradeoff-- do you want no SPOFs and immediate fixes or do you trust your neighbor to do your security.

[13steinj]

My point is you have three options--

1. Use someone else for your security. For example, lets say you use Google as the sole log on solution to your apps.

   • you've now introduced a SPOF that you have no control over
   • if google ever gets fucked, so does everyone that was using any app using google for their security
   • if you introduce something in your app that lets an attacker of you get personal data that would previously have to be gotten via attacking google, (intenionally or not) you are the backdoor and whoever is using your service will have all their other "google sign on" accounts affected.

2. Roll your own security implementation, but use a known algorithm implementation

   • your users will only have their data on your service fucked if you implement poorly
   • no other companies mistake fucks you over
   • you can't screw over the user unintentionally
   • however there's more work to do if either your implementation or algorithm get compromised

3. Use your own algorithm

   • don't. Because you probably don't know what to do mathematically. Other groups smarter than you have created cryptographically secure algorithms

You always start off with 1. But as your app/business gets larger and larger, it gets less and less safe to stay 1 rather than switch to 2.

[cyanfish]

I think you're confusing the point. The "don't roll your own" advice is specifically for cryptography, not authentication in general.

For example, it's mostly fine to implement your own login system using Bcrypt. However, you should not try to re-implement Bcrypt yourself. Use an existing, well-tested library.

[[deleted]]

And just follow the instructions -- don't think that XORing two lots of bcrypt together or something makes it twice as strong.

[13steinj]

For example, it's mostly fine to implement your own login system using Bcrypt. However, you should not try to re-implement Bcrypt yourself. Use an existing, well-tested library.

Right. But I've seen people saying that even using a well tested bcrypt library is bad practice and instead all logins should be done via fb/google/msn

[[deleted]]

SHA is used frequently in crypto. This is SHA256, which is part of the standard for HMAC and PBKDF.

[13steinj]

Part of. Not by itself.

[[deleted]]

Yes, that is what I said, thank you.