
So you want to roll your own crypto? - wglb
https://vnhacker.blogspot.com/2020/08/so-you-want-to-roll-your-own-crypto.html?m=1
======
lawl
I of course agree with all of this, but as someone pretty much at the bottom
of the food chain who just wants to encrypt some data, there's often no
libraries that safely glue the primitives together in the way that I require.

Granted, this is getting better, for example NaCl's crypto_box[0] is awesome
and very hard to misuse. But say you want forward secrecy now. _chirp_ ,
_tumbleweed_.

I hope this doesn't come off as entitled, but I feel like the best way to get
people to stop rolling their own crypto is to provide more/better libraries.

Say you have a requirement to build some chat somewhere, and it sais somewhere
that it needs to be encrypted, which I think is a reasonably realistic
example. So you use crypto_box, but then you realize you don't have forward
secrecy. Ok, no problem, you remember libotr[1] just use that. Now you realize
that OTR can't do group chats, so figure ok, most group chats are small
everyone can just have an OTR session with everyone else and send their
messages to everyone (which of course means you can give different people
different messages, but let's ignore that). Next you realize people aren't
always online at the same time and you can't send offline messages. So you
remember Signal's double ratchet[2]. But libsignal was just built for signal
and doesn't look easily integratable. Then I guess there's also (Meg)Olm[3]
but that looks like the same story as signal.

[0] [https://nacl.cr.yp.to/box.html](https://nacl.cr.yp.to/box.html)

[1] [https://otr.cypherpunks.ca/](https://otr.cypherpunks.ca/)

[2]
[https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm](https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm)

[3] [https://gitlab.matrix.org/matrix-
org/olm/-/tree/master](https://gitlab.matrix.org/matrix-org/olm/-/tree/master)

~~~
tasn
I couldn't agree more, and it's actually something I've been working on for
the last few months, though in a sense for the last few years. I was going to
do a Show HN in the next few weeks, but heck, may as well mention it now too.

What I'm working on is called Etebase. Etebase makes it easy to build end-to-
end encrypted applications by taking care of the encryption and its related
challenges such as data-integrity, data-deduplication, collaboration and etc.
Everything is open-source, it uses libsodium[0] behind the scenes, and we plan
on releasing a full spec soon as well as formally verify the protocol using
Verifpal[1].

Website: [https://www.etebase.com](https://www.etebase.com)

Docs: [https://docs.etebase.com](https://docs.etebase.com)

It's essentially a spin-off of the next version that powers my other project,
EteSync[2] - a secure, end-to-end encrypted, and privacy respecting sync for
your contacts, calendars and tasks.

Would love to hear your thoughts!

[0] [https://doc.libsodium.org/](https://doc.libsodium.org/)

[1] [https://verifpal.com/](https://verifpal.com/)

[2] [https://www.etesync.com](https://www.etesync.com)

~~~
uryga
i don't wanna sound dismissive, i'm sure Etebase is a good fit for some
things. but GP was asking for a crypto library, not a whole SaaS that will
host all their chat data

~~~
tasn
No worries, you don't sound dismissive, though let me address your points:

First of all, Etebase is not "a whole SaaS", since it's open-source you can
self host it, so the SaaS is optional.

As for what the GP was asking, I disagree. I think it's exactly what he was
asking for. He was lamenting the lack of complete solutions, and having to
figure out things on your own. Without the server part and network protocol,
Etebase is essentially just libsodium, which GP already mentioned.

------
lmilcin
Crypto is hard because you don't get quick feedback on whether you are doing
well. The feedback will only come if somebody hacks it. You need to know what
you are doing and most developers are not at that level. Most development
happens by constantly iterating (write couple lines of code, find if it does
what you expect it to do).

If you want to understand crypto imagine getting requirements and having to
write an app. You can't run it before it goes to production. You need to
understand every detail of the app is correct and you are not going to get any
validation.

I like to think that crypto is not development. Development only happens after
you did crypto (ie. writing down the process) and it is completely different
from development.

I have rolled my own cryptogrophic protocol for transferring keys between
devices that was subsequently approved by PCI. We needed the protocol in order
to work around peculiarities of the particular HSMs we had and it used "funky"
operations like encrypting block of data using 3DES in reverse (ie. using
decrypting operation on plaintext block of data) so that it can be then
digested by the HSM.

Very simple protocol, took a lot of effort to prove why we need it and to
prove we know what we are doing.

~~~
cryptbe
>Crypto is hard because you don't get quick feedback on whether you are doing
well.

Well said.

If you are to implement a sorting algorithm, you'll know immediately whether
it works or is fast enough. Crypto doesn't provide this feedback. It's
important to get help from others, if you can't tell yourself whether your
code works.

------
cortesoft
> Bad crypto code usually looks and produces results indistinguishable from
> good crypto code

This is such a weird part of cryptography... you can have two implementations,
which both always produce the exact same output... and yet, one could be
vulnerable because of side channel or timing attacks.

~~~
ecesena
This is true for every piece of software, isn't it!? You can have 2 identical
websites, one checks your username+password for real, the other always logs
you in. Or even better, one stores bcrypted passwords, then other cleartext
ones...

Use battle tested frameworks. For crypto, for sites, for everything.

~~~
cortesoft
This goes beyond that, though... in your example, the two programs DON’T give
identical output with identical input; one will log you in with a bad
password, one won’t. That is different behavior.

Likewise, with your second example, the storing clear text and bcrypted
passwords are different outputs.

When I say the two pieces of code have identical outputs for identical inputs,
I mean everything, not just what an end user sees.

Here is a toy example to show what I mean: say you have a function that takes
a username and password, and compares it against a stored username and
password (lets ignore the insecurity of storing a plain text password for this
example). Now, you have two implementations of the function, and we know that
both work as desired; they both will accept all correct username/password
combos, and will reject all incorrect username/password combos. We have
exhaustive tests proving that both return the same result when given the same
input.

Normally, this is good enough - both functions are interchangeable, because
they are guaranteed to always output the same data with the same input. You
would probably choose the implementation that is faster, or used less memory,
or whatever.

However, for crypto, this isn’t enough. Lets say in our exmaple, one
implementation starts checking each bit of the password. If the first bit of
the submitted password matches the first bit of the stored password, it moves
to the next bit. If they don't match, it returns false because it knows that
the passwords don't match. What a great optimization! You don't have to keep
checking once you hit the first wrong bit. The second implementation checks
every bit, even after it finds an incorrect match. So inefficient!

However, even though they both work perfectly in the sense that they will
always return the correct result, the one that returns false on the first
mismatched bit is vulnerable to a timing attack. An attacker can keep
submitting passwords, and wait for the response to get a little bit slower...
now they know they have the first bit correct. Repeat this for a while, and
you can figure out all the bits.

This is obviously a toy example, but this technique has been used over and
over again to break crypto implementations. You have to care about more than
just the output when you deal with crypto!

Here is a paper about using this technique to break an earlier version of
OpenSSL: [https://crypto.stanford.edu/~dabo/papers/ssl-
timing.pdf](https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf)

~~~
nbadg
> When I say the two pieces of code have identical outputs for identical
> inputs, I mean everything, not just what an end user sees.

But that's exactly the trouble with side channels: you've just defined
"outputs" and "inputs" in a way that excludes them. If you widen your lens a
bit to include, say, the timing of the code as an output, or even further to
the physical changes of bits in hardware, then the outputs and inputs are no
longer identical.

You can even extend that to the lock metaphor: when you pick a lock, you're
using the tumbler itself as an "extra" input, and the feel of the pins as an
"extra" output, instead of just the position of the pins. The tumbler and the
feeling were there all along; it's not that they're really extra inputs or
outputs, we just don't normally pay attention to them. Unless you take up
lockpicking.

~~~
drewcoo
You're missing the point: in and out data via intended usage. Trying to move
the goalposts afterward doesn't actually change what was intended. Consider
ecesena's examples:

> 2 identical websites, one checks your username+password for real, the other
> always logs you in.

In that case, it's not a side channel. Presumably the intended use of
authentication includes turning away bad credentials.

> one stores bcrypted passwords, then other cleartext ones...

That is an implementation detail. In itself, it's not a side channel because
there's no way in the scenario to get the passwords. That cleartext
implementation would appear at least as tough against timing attacks as
bcrypt, in fact, because it would always decrypt all cleartext passwords in
the same time - no info leak there.

~~~
nbadg
I'm not. I get the distinction. The point I'm trying to make is that only
considering the intended usage is an incorrect approach to design. The
consequences of this constrained thinking can be particularly extreme in
infosec, but it's just as true of software in general, or even, say, consumer
products -- hence seeing all sorts of weird disclaimers on them these days.

------
Animats
It's worth noting that, historically, cryptosystems have more often been
broken through errors in key management than by actually cracking the
encypherment algorithm. Key generation from an untrusted source.[1] Weak
random number generation. Reusing keys. Keys intercepted in transit. Stuff
like that.

[1] [https://www.allkeysgenerator.com/Random/Security-
Encryption-...](https://www.allkeysgenerator.com/Random/Security-Encryption-
Key-Generator.aspx)

~~~
fractionalhare
I agree that modern cryptography isn't usually broken through design
cryptanalysis, but I wouldn't bucket all the ways it usually fails into key
management. There is a lot of misuse and misimplementation which goes beyond
weak keys and key reuse.

I would rather say modern cryptography typically fails in one of three ways:

1\. Incorrect implementation of low level primitives. For example:
implementing textbook RSA (without padding).

2\. Improper composition of correct primitives. For example: implementing an
authenticated encryption construction using CBC mode with a MAC that shares
its key with the CBC secret key, or simply using key = IV.

3\. Incorrect usage of correct primitives. For example: nonce reuse with the
same key, using regular cryptographic hash functions for password hashing,
using an HMAC key larger than the block size, or using unauthenticated
encryption to prevent tampering (e.g. URL parameters).

~~~
HenryBemis
I cannot believe that we are talking about break-in cryptography and there
have already been two XKCD posts but not the one about the reality of
"cracking" cryptography:

[https://xkcd.com/538/](https://xkcd.com/538/)

(apologies for the super obvious cartoon)

------
donw
Cryptography is a little bit like making fireworks.

For most people, and you are most people, you're better off to just buy
fireworks made in a factory.

Follow the instructions, light them, they go bangity-boom-sparkle-puff, and
everybody gets to finish up the evening with the same number of limbs and
eyeballs as they started with.

Make your own, and you had _better_ know what you are doing. Even if you do,
Bad Shit is high on the list of possible outcomes.

Gunpowder may be a "low" explosive, but that doesn't mean it likes you.

Build up too much static and get a spark? Look around your workshop, and
imagine your tools and furniture suddenly coming at you much faster than would
be considered polite for inanimate objects.

Screw up the measurements? Get the fusing wrong? Now not just you, but also
your guests, can experience the fun and excitement of being mortared.

Or you can be sane, and just buy some fireworks from one of those plywood
booths that pop up every June.

tl; dr Don't roll your own crypto.

~~~
hanche
Good analogy. And even factory made fireworks is dangerous if you don’t follow
instructions. And so it is with cryptography.

~~~
bigiain
“Ligh blue touch paper”, ok, got it. “ ... and stand well clear” yeah yeah,
stupid safety advice. What kind of noob do you think I am? I’m a rockstar 10x
ninja! <firework, caring little for egos, explodes as designed>

~~~
tialaramex
Leading to the pun:
[https://www.lightbluetouchpaper.org/](https://www.lightbluetouchpaper.org/)

(Cambridge University is associated with a light blue colour, although exactly
_which_ light blue colour is controversial, its rival Oxford University is
associated with a _dark_ blue - and of course such security research may
sometimes lead to fireworks of a different kind...)

------
jason0597
What I don't like is when I hear people say the phrase "don't roll your own
crypto!", I don't know whether they mean:

"don't use a cryptographic library yourself and build the cryptographic scheme
yourself (HMAC, encryption, signing, etc.)" or "don't write your own
cryptographic library and do all the base crypto functions yourself!"

~~~
jnwatson
It means leave the high templar to write any code that has confidentiality,
integrity, or availability requirements.

~~~
loup-vaillant
I prefer to join the rebels on this one: [http://loup-
vaillant.fr/articles/crypto-is-not-magic](http://loup-
vaillant.fr/articles/crypto-is-not-magic)

------
cryptbe
Author here, ask me anything.

~~~
daenz
For the very example-driven people, can you give a couple of examples of some
of those non-obvious, subtle implementation details that completely destroy
crypto schemes?

~~~
markc
Here's a classic - not understanding the implications of encrypt-then-mac vs
mac-then-encrypt.

[https://crypto.stackexchange.com/questions/202/should-we-
mac...](https://crypto.stackexchange.com/questions/202/should-we-mac-then-
encrypt-or-encrypt-then-mac)

~~~
tzs
If speed was not an issue and you don't mind having to have 3 keys, could you
cover all the bases by doing MAC-then-encrypt, then treat that as cleartext
and do encrypt-and-MAC on that, and finally treat the result of that as
cleartext and do encrypt-then-MAC on that to get the final thing you send?

------
Mc91
I am not a crypto maven, which means my ability to analyze the strength of
various crypo systems is poor, although people say PGP is good at encrypting
files and messages. I also had the thought of encrypting a file with one
encryption scheme on top of another one - encrypting my file with one
encryption scheme, and encrypting that encrypted file with another encryption
scheme - although that idea is so obvious I am sure it is not a novel idea.

What is slightly novel is if I use a system with some tested (but uncertain)
strength like PGP, and within it encrypt something with my own rolled crypto -
this might protect me somewhat. Outside is the battle tested crypto of
something like PGP. Inside is my own crypto system which might have some
weaknesses, but which will probably take some hours of people working and
analyzing it. Even if it can be cracked with 24 hours of analysis by skilled
cryptographers, it still means it is not just spewed out of some computer
somewhere as a trivially cracked message. Skilled cryptographers do not grow
on trees, so my bet is that

#1 - Odds are something like PGP is not cracked, or at least a superpower can
only crack a small percentage of messages a year in terms of computing power,
so I am relying on it not being cracked or being hard enough to crack that my
message is not deemed worthy

#2 - If it turns out PGP is quick and trivial to crack, I am relying on my
message still not being deemed worthy enough to merit a few of the scarce
labor hours of skilled cryptographers.

~~~
loup-vaillant
The consensus is that cryptography _works_. Even the NSA can't get past a
properly encrypted message with PGP (assuming you use PGP correctly, and I've
heard its UX is horrible). So, one layer of encryption is enough. No need to
make your life more complicated.

The biggest fear is not that the crypto itself breaks, but that
_implementations_ don't actually implement the crypto correctly. At this point
it's mostly a matter of being reasonably sure the software is bug free.
Exacting, but not impossible, especially if it's kept simple.

~~~
limcin
"Modern E2E encryption is like sending and receiving messages with a top
security truck, but then on arrival, storing them in a tent."

The biggest problem is security weaknesses at the end-point. Your selfie is
travelling securely over the wire, and then it reaches the end-point device
where there are typically 100's of unfixed vulnerabilities:

[https://www.androidauthority.com/snapdragon-dsp-android-
secu...](https://www.androidauthority.com/snapdragon-dsp-android-security-
flaw-1146291/) [ DSPs in Qualcomm Snapdragon chips reportedly contain over 400
vulnerabilities ]

------
IncRnd
This article is correct. However, it is important to call-out something that
is far too prevalent, much code incorrectly uses correct crypto primitives.
The world is full of calls to CBC with improper IVs, for one simple example.
Another spot-on example mentioned in the article is timing oracles.

Security coding in general, not just crypto, uses an entirely different set of
principles from functional programming. It is for this reason that "security"
cannot be bolted-on, and cryptography cannot just be "dropped into" the code.

------
G4BB3R
I was expecting a kind of rant that one fills the reason why you want to
create a new X. Then after fill the reasons why it wouldn't work. I have seen
with calendars and other things here in hacker news. Someone remember the
links?

~~~
howenterprisey
[https://craphound.com/spamsolutions.txt](https://craphound.com/spamsolutions.txt)

------
blindm
I always wondered, since the NSA has intimate knowledge of the inner workings
of AES, then can we presume they know its weaknesses, or have compromised it
in some way? Excuse my naive question, I'm not a crypto nerd.

~~~
dlubarov
AES has been a major target of cryptanalysis, and it has held up pretty well.
Publicly known key recovery attacks are only slightly faster than brute force,
like [1]. There are some efficient related-key attacks, which might be a
concern in certain applications, but not if keys are chosen randomly.

It's always possible that the NSA has found better attacks, but I don't think
there's anything particularly suspicious about AES compared to other
primitives. (For an example of a highly suspicious primitive, see
Dual_EC_DRBG.)

[1] [https://eprint.iacr.org/2011/449](https://eprint.iacr.org/2011/449)

------
veselin
My understanding is that such tricky side-channel free code ideally should not
be directly written by humans. I know of at least one project that has made a
lot of progress on this idea, although they say the crypto primitives are
still at research level: [https://www.microsoft.com/en-
us/research/blog/project-everes...](https://www.microsoft.com/en-
us/research/blog/project-everest-reaching-greater-heights-in-internet-
communication-security/)

~~~
hansvm
I'm not convinced it should even be written by machines. Even at an assembly
level, removing side-channels depends heavily on implementation choices for a
particular chip. A constant-time (for a given chip) binary targeting some
instruction set very well might turn into a timing side channel when deployed
on a chip with newer/different optimizations, especially with respect to
memory/data dependencies.

------
bob1029
I just use good primitives and glue them together as required in my
application code. The only primitives that I feel safe playing with are: SHA2,
AES, PBKDF2, CSPRNG, and Microsoft's DPAPI (for secret management). I always
use first party implementations where possible. In this case, all of my crypto
primitives are entirely written by Microsoft.

I never really screw with asymmetric crypto primitives directly. The closest
I'll get to that area is stuff like loading a PFX byte array into an
AspNetCore webapp for presenting a TLS cert.

~~~
IncRnd
Un fortunately, there are lots of things to specify in order to properly use
the crypto you mentioned. It sounds as if you are already taking care of those
things.

For people who may not be aware: Which SHA-2? Is it a truncated version? What
encryption mode of AES? Are you using an IV? How is it generated? How is the
key material protected? With PBKDF2, how many iterations, how was the salt
generated, what PRF is used in it? Is DPAPI used in machine or user scope?

------
ChrisMarshallNY
No. Just. No.

I suck at crypto. Others are much better than I, and there's a huge plethora
of really good implementations out there that get hammered by blackhats and
red teams all the time.

There's too much at stake for me to add a naive implementation.

------
tialaramex
>How are people supposed to learn (from mistakes) if they don't roll their own
crypto?

The right answer to this question, and not just on cryptography is: Stop it.
There are _billions_ of humans. They're already making _plenty_ of mistakes,
learn from those. Don't just make more and imagine that helps somehow.

If you feel the need to "learn from mistakes" you can find a healthy supply of
detailed reports about mistakes other people already made and learn from them.

Most often what people _actually_ mean is "I'm pretty sure I am uniquely
brilliant and won't make mistakes" and I think the healthiest response is
probably to laugh until you cry.

~~~
cwyers
I watch a lot of cooking shows. America's Test Kitchen, Cook's Country, Good
Eats, Milk Street, I watch Bon Apetite's YouTube channel, I read dozens
cookbooks, all sorts of things.

Not a single one of them is a substitute for standing there in the kitchen and
cooking. They help, they help a lot, but eventually you have to get hands on
with something to actually gain experience with it.

Now, do you want someone to learn from their (incredibly common) mistakes on
your production crypto system? No. Very Much No. But people learning from
working on side projects and prototypes and whatnot? That's great, so long as
they have a way to get feedback on what they're doing wrong.

~~~
PeterisP
But the thing is, there's no way to get feedback on what they're doing wrong.

If you make bad crypto in your prototype, then to you and most everyone else
it will look just fine, so you'll get no feedback on misleading feedback. You
won't get the chance to learn from your mistakes because you won't know what
was a mistake.

You'll get realistic feedback only if someone skilled spends nontrivial time
to analyze your solution (likely more time than it would take them to just
implement a known good solution) - which will happen only if you hire them for
an in-depth audit, or if you launch a production system where breaking your
crypto will have a big enough impact to motivate someone to break it.

------
ppafin
Crypto is Crypto - but how about platforms you run it. If you share host with
known unknowns - can it be secure?

------
tester756
funniest shit I've seen on the topic of doing your own crypto

Reply1

>The problem with Telegram and why it should be avoided is they tried to roll
their own crypto called MTProto.

>That's is simply what you don't ever do. Encryption is done. There are many
algorithms that are being tested and researched by experts, those are the
algorithms to use. There is simply no need to roll your own.

Reply2

>The lead Telegram dev is a 3x International Math Olympiad gold medalist, won
another gold in the informatiks olympiad, went on to earn two Ph.D.'s in
algebraic geometry, all while working full-time as a programmer?

>Him rolling his own encryption algorithm is not the same as your copy-paste
StackOverflow code monkey who scraped by with C's at his community college
rearranging the alphabet letters in a caesar cipher.

------
1vuio0pswjnm7
[https://github.com/cjdelisle/CryptoSplainers](https://github.com/cjdelisle/CryptoSplainers)

~~~
fractionalhare
_> I'm gonna let you in on a little secret: Crypto is boring. We already know
how to do it, it's been boring for like 20 years and unless you're doing
something massively complicated like an anonymous cryptocurrency or you just
make an enormous mistake, you basically can't mess it up._

I don't know what to make of this, except to say that the author is either
misinformed or trolling.

~~~
raverbashing
Keep reading.

And don't forget about "Rubber Hose crypto attacks"

(But yes, the article needs to be taken with a grain of salt)

------
jassany
not really.

------
loup-vaillant
While I appreciate the links to actual learning material, and though it is
said in the nicest possible way, I get the usual "Crypto is hard, back off"
vibe, without a clear path to victory. Sure it's hard, but it's not magic
either. There are relatively few rules, that when followed give you a working,
_secure_ system. Those rules aren't easy to follow, but they _are_ simple to
know about. [http://loup-vaillant.fr/articles/crypto-is-not-
magic](http://loup-vaillant.fr/articles/crypto-is-not-magic)

About not using your crypto until it's been vetted by professionals… How do
you get those vaunted professionals to even look at your work? For instance,
I've been working on Monocypher for over 3 years, and the only way I could get
professionals to actually look at it was to pay $7.000 (out of the OTF's
pocket, I don't have the money). That's an unrealistic bar to meet, people
need other ways to vet their work.

About CTF (Capture The Flag), and cryptopal challenges, my advice is: don't
waste your time. The penetration testing approach to secure systems _does not
work_. You whack a mole, two more appear. We need ways to prevent whole
classes of errors, like proofs. For instance, tools like
[https://verifpal.com/](https://verifpal.com/) can be a great help when
designing a protocol.

On crypto being deep and vast, it really depends what you're doing. While
perhaps less than 50 people in the world are truly qualified to design a new
cipher, that's not what people need when they "roll their own crypto". Most of
the time they need a new _implementation_ for an existing primitive (embedded
programmers), or they need to invent a new _protocol_. Either is actually
accessible to any professional programmer who actually follow the rules.

Even side effect circumvention. programming without the "if" statement is not
that hard, especially if you stick to constant-time friendly primitives.

~~~
cryptbe
I wrote this article to encourage people to study the field I love. If I
wanted to tell people to back off, why would I bother providing advice,
material and telling people to have fun?

>Those rules aren't easy to follow, but they are simple to know about.

If the rules were so simple, how come your library had a signature bypass
vulnerability that you did NOT understand its root cause until I explained?

The root cause looks deceptively simple, until you take your time to
understand the underlying math. I didn't fully understand it until a professor
at MIT explained it to me. Maybe it's just that I'm stupid, but it is never
simple to me.

>About not using your crypto until it's been vetted by professionals… How do
you get those vaunted professionals to even look at your work?

You can't expect people to pay attention to your work until you earn it. Why
would anyone bother reviewing a random library from a random dude? Frank of
libsodium fame didn't start by writing a brand new library from scratch, but
built it on top of NaCl. If he did that, nobody would take him seriously
either.

>About CTF (Capture The Flag), and cryptopal challenges, my advice is: don't
waste your time. The penetration testing approach to secure systems does not
work. You whack a mole, two more appear. We need ways to prevent whole classes
of errors, like proofs. For instance, tools like
[https://verifpal.com/](https://verifpal.com/) can be a great help when
designing a protocol.

This was how my friends and I got started. Maybe you were right that it isn't
worth it, but it helps get us to where we are, being _paid_ to do security and
crypto.

There are two approaches to learning: top down or bottom up.

The former is what you get at university. If you want to learn crypto, you
have to learn abstract algebra, linear algebra, probability theory, complexity
theory, and computer security. If you want to learn complexity theory, you
want to learn automata theory, computability theory, and algorithms. If you
want to learn computer security, you want to learn computer architecture,
operating systems, networking, etc.

The top down approach is systematic, but it might not prepare you for the real
world. For that, you need internships and CTFs. They are reality checks with a
fast feedback loop, showing you very quickly which skill or knowledge you are
lacking or need improvement. They are also fun.

~~~
tptacek
On the off chance that anyone here isn't familiar with 'cryptbe, he broke the
Flickr URL signing scheme, he and Juliano Rizzo discovered and worked out the
BEAST TLS attack (which, to hear Kenny Paterson describe it, more or less set
the template for the next 10 years of applied TLS attack research), and then
discovered CRIME, which is the first in a line of compression oracle attacks.
He works on Daniel Bleichenbacher's team now doing Tink and and Wycheproof.

