14 ms·
So you want to roll your own crypto?
- IncRnd 6y agoThis 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.
- cortesoft 6y ago> 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.
- stouset 6y agoNot just that but something like AES using ECB is indistinguishable from random to the casual observer. Only when you’re aware of why ECB is bad will you understand what to look for to defeat it.
- andrewnicolalde 6y agoI actually have a sticker of ECB Tux[1] on my laptop to serve as a fun reminder :P [1] https://filippo.io/images/Tux-ECB.png https://filippo.io/images/Tux-ECB.png
- nmadden 6y agoWhich is the classic illustration that ECB is _not_ indistinguishable from random, even to a casual observer.
- tialaramex 6y agoI think "casual observer" and "shove deliberately patterned data through the system then render it so that I can see if the patterns show through" aren't the same thing. In the Tux data maybe 03038F12128F0303 turns into 49DC195026F3300A and that looks pretty random. It's only visible as the Tux image because every 03038F12128F0303 turns into 49DC195026F3300A, thus preserving the very bold overall pattern of the image. If you shove a photograph of a kitten through it, that looks like noise, but Tux is made of these big bold shapes and so the resulting pattern is big enough to "show through" the ECB encryption.
- nmadden 6y agoThese kinds of patterns are present in input data quite often - eg fixed headers, markup etc. As usual, there’s even an xkcd on it: https://xkcd.com/1286/ https://xkcd.com/1286/
- Dylan16807 6y agoYou're basically implying that a casual observer would look at AES all by itself and then say things are good. And I think you're correct to imply that. But that means that ECB isn't actually passing the smoke test, because the casual observer isn't analyzing AES+ECB. They're only analyzing AES.
- tzs 6y agoI think when people say that a block cipher is indistinguishable from random they mean that for a given key k, the permutation 0 -> cipher(0, k), 1 -> cipher(1, k), ..., 2^n-1 -> cipher(2^n-1, k) where n is the block length in bits is indistinguishable from a random permutation of (0, 1, 2, ..., 2^n-1).
- nmadden 6y agoThat’s an ok(ish) definition of indistinguishability for a block cipher, but not for a mode of operation like ECB.
- mhe 6y agoIn case anyone wants to create a similar reminder for a specific image, a while ago I created a small utility that does just that: https://github.com/mhe/visualmoo https://github.com/mhe/visualmoo
- andrewnicolalde 6y agoThis is very cool, thanks for sharing!
- betterunix2 6y agoActually a casual observer can distinguish ECB from random, though they may not realize that is what they are doing. For example if you manage to compress the ciphertext -- random data should not compress by much so if you can do any significant compression on ciphertext then you are distinguishing it from random bits. ECB should be compressable if the plaintext is compressable (though probably not as well as the plaintext do to the way ECB is divided into blocks). Recognizing that this is a problem is another matter.
- ecesena 6y agoThis 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 6y agoThis 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
- G4BB3R 6y agoI 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 6y agohttps://craphound.com/spamsolutions.txt https://craphound.com/spamsolutions.txt
- cryptbe 6y agoAuthor here, ask me anything.
- bumblebritches5 6y agoCan you elaborate on the details that makes crypto insecure? I'm writing a library called CryptographyIO and I want it to be secure.
- baby 6y agowhy "cryptbe"? It sounds like you're from belgium
- xuki 6y agoHe's from Vietnam, the blog title gave it away without reading the about section.
- Animats 6y agoIt'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-Key-Generator.aspx https://www.allkeysgenerator.com/Random/Security-Encryption-...
- garmaine 6y agoThose count as the “crypto” in “don’t roll your own crypto”
- fractionalhare 6y agoI 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 6y agoI 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)
- deleted 6y ago[deleted]
- 6y ago
- 1vuio0pswjnm7 6y agohttps://github.com/cjdelisle/CryptoSplainers https://github.com/cjdelisle/CryptoSplainers
- fractionalhare 6y ago> 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 6y agoKeep reading. And don't forget about "Rubber Hose crypto attacks" (But yes, the article needs to be taken with a grain of salt)
- 1vuio0pswjnm7 6y agoAlso by this author: https://github.com/cjdelisle/cjdns https://github.com/cjdelisle/cjdns cjdns was one of the early adopters of NaCl https://nacl.cr.yp.to https://nacl.cr.yp.to https://ianix.com/pub/curve25519-deployment.html https://ianix.com/pub/curve25519-deployment.html
- tialaramex 6y ago>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.
- filleduchaos 6y agoEvery time I read comments like this, I'm left wondering the author thinks of the people who are actually doing the work in question - here it's crypto, in other cases it's new operating systems or game engines or programming languages or what have you. This is what I think: those people are not some non-human species beyond the comprehension of mere mortals, nor did they crawl into the world already knowing everything in their fields. We need more people experimenting and learning outside the boundaries of staid, safe product development, not less.
- tialaramex 6y agoPeople actually doing good work get to make new and interesting mistakes. They hope not to of course, but that's just how it goes. But what you and so many people want is permission to go on "experimenting and learning" by making the same mistakes the previous cohort of people "experimenting and learning" made, and those before them, and so on ad infinitum. That's futile. Stop it. Since the horizon of your imagination seems to be computer software let me expand a little bit with an example from a quite different discipline which is entirely illustrative of my point. Some years ago, an elderly couple were struck and seriously injured (one of them died I think) by a speeding tram. The accident investigation report found as you would expect a long list of causes, but one of them is particularly relevant to us here. On the _mainline railways_ subject to oversight from the same authorities and investigations by the same team, it had for many years been the practice to require Compliance as a psychological trait of drivers. Compliant people are inclined to obey rules, all else being equal. If you tell a Compliant person that the speed limit is 45mph they will tend to go no faster than 45mph whereas people who are less compliant might ask "Why?" or just decide it seems safe to do 55mph instead since what could go wrong? The driver of the tram was not tested for Compliance, his employers hadn't picked up on this requirement, and their drivers hadn't ever killed anybody by speeding before. Sure enough during the accident he was driving the tram faster than the maximum speed shown and was unable to stop it striking the elderly victims. You don't need to make your own mistakes to learn from other people's. Stop it.
- donw 6y agoCryptography 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.
- bigiain 6y agoI used to lurk on alt.pyrotechnics - where I learnt “The Pyrotechnicians Salute”. Where you hold up both hands and wave all ten fingers in the air. To prove you still have them...
- hanche 6y agoGood analogy. And even factory made fireworks is dangerous if you don’t follow instructions. And so it is with cryptography.
- bigiain 6y ago“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 6y agoLeading 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...)
- ppafin 6y agoCrypto is Crypto - but how about platforms you run it. If you share host with known unknowns - can it be secure?
- jassany 6y agonot really.
- lawl 6y agoI 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 6y agoI 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
- veselin 6y agoMy 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-everest-reaching-greater-heights-in-internet-communication-security/ https://www.microsoft.com/en-us/research/blog/project-everes...
- hansvm 6y agoI'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 6y agoI 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.
- fanf2 6y agoAES by itself is not very useful. What block cipher mode(s) do you use?
- IncRnd 6y agoUn 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?
- betterunix2 6y ago"glue them together as required in my application code" This can easily be the source of problems. Bad compositions of crypto primitives are a common source of vulnerabilities in cryptosystems. A textbook example is MAC-then-ENCRYPT, which is not secure in general. Another common example is over-use of a cryptographic key, which can easily happen when underlying primitives are composed badly (asking for too many bytes from a PRG, or encrypting too much data in GCM mode, etc.). "never really screw with asymmetric crypto primitives directly" You might not be matching your crypto to your application requirements if you can write off a whole swath of primitives like that, or else you only deal with a very specific setting in which symmetric cryptography is sufficient.
- tptacek 6y agoAlmost every crypto vulnerability I have ever found in production code came from systems designed with good primitives. It's not like we generally break systems by doing block cipher round function cryptanalysis.
- lmilcin 6y agoCrypto 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.
- AnonHP 6y ago> 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. Not necessarily (for the part marked in italics). See all the grief that Telegram gets here in every post about it or related to it. Feedback on certain implementations does come from well known people in crypto.
- lmilcin 6y agoFor starters, for most applications there is no feedback because they are not popular enough for somebody to care to take a close look and publish results. Also, details regarding security are not usually made available for public which does not help. The protocol I worked on is used to bootstrap security for credit card terminals used for hundreds of millions of transactions and yet about 2 people ever looked at it really closely (my boss and another colleague mathematician). For some applications you might get an outside opinion (audit or certification) but these are not typically aimed at checking if you did your job well, rather they check if you meet some kind of requirements. For PCI, for example, there is a questionnaire. Also the feedback of this kind comes for really egregious mistakes, but the devil is usually in the details.
- tester756 6y agofunniest 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.
- jason0597 6y agoWhat 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!"
- PeterisP 6y agoBoth. The former is just as tricky and prone to seemingly innocent but fatal mistakes as the latter.
- jnwatson 6y agoIt means leave the high templar to write any code that has confidentiality, integrity, or availability requirements.
- loup-vaillant 6y agoI 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
- ChrisMarshallNY 6y agoNo. 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.
- blindm 6y agoI 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.
- andrewnicolalde 6y agoWe have no real way of knowing. AES is considered secure because, as far as is publicly known, it has sufficiently withstood attacks performed by many, many skilled cryptanalysts. As far as I am aware there is no reason to believe that AES provides anything less than its stated level of security. But again that isn’t to say it’s impossible.
- dlubarov 6y agoAES 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
- Mc91 6y agoI 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 6y agoThe 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 6y ago"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-security-flaw-1146291/ https://www.androidauthority.com/snapdragon-dsp-android-secu... [ DSPs in Qualcomm Snapdragon chips reportedly contain over 400 vulnerabilities ]
- loup-vaillant 6y agoWhile 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.
- tptacek 6y agoIt's easy to write this when the safety of your users is both an abstraction and an externality; it's a lot tougher when you have to own your mistakes.
- loup-vaillant 6y agoPlease don't presume. I do care about my users. Their safety is not an abstraction. You personally made sure it wouldn't be an externality either. I can count on you to make me pay for any mistake I make (only one of any consequence so far, and it was over 2 years ago: https://monocypher.org/quality-assurance/disclosures https://monocypher.org/quality-assurance/disclosures). I know exactly how tough it is to own up to my mistakes.