Timeline for Why is it wrong to *implement* myself a known, published, widely believed to be secure crypto algorithm?
Current License: CC BY-SA 4.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 13, 2019 at 9:57 | comment | added | Murphy | @CortAmmon Cascade cipher and it's very important that the best algorithm go first. link.springer.com/article/10.1007/BF02620231 And yes you must use different keys. If I was some shadowy figure in one of the big gov intelligence agencies I would probably just drop 10 million on subverting each of the top 10 most used crypto libraries then another few million on a PR campaign focusing on crypto discussion telling everyone to to never ever create their own implementations.... and call it a day. | |
| May 10, 2019 at 15:02 | comment | added | Cort Ammon | @Murphy If I'm reading you correctly, you're talking about using multiple encryption? You first encrypt with something "home brew" for diversity, then encrypt with a standard encryption method before sending it out? Hopefully using different keys, of course. | |
| May 10, 2019 at 13:46 | comment | added | iheanyi | @Murphy hahaha, your "framework" apparently is "don't write buggy code or code that does something wrong". | |
| May 10, 2019 at 11:01 | comment | added | Murphy | @iheanyi hence why I mentioned some kind of framework to seperate the other implementation. If you don't re-use keys or do similarly stupid and work with the encrypted block of data then you should no more be able to weaken it than all the other random code running on your server doing tasks or the server transmitting that encrypted block over the network should be able to weaken the encryption. (though it is important that the most solid implementation go first) Monoculture in the crypto library market makes the whole industry vulnerable. | |
| May 9, 2019 at 23:05 | comment | added | iheanyi | @Murphy that seems like a recipe for failure. Encrypt something then let someone else play with the result. Hmm, let me cache the results of this encrypted password and do something special if someone wants it again. You've just proposed a way to weaken encryption. | |
| May 9, 2019 at 14:20 | comment | added | Murphy | @CortAmmon a little. My go-to example is the Underhanded C Contest where the goal is to write code that can pass code review while including something underhanded. I kinda wish there was a framework for making it safer for people to roll their own code. Encrypt with standard library first... then drop it into a sandbox where an amateur can layer on their own random method with separate keys without significant risk of weakening the inner layer. Would defeat tactics targeting standard libraries. | |
| May 9, 2019 at 13:50 | comment | added | Cort Ammon | @Murphy That's conspiracy theory thinking.... which means you fit right in with the crowd =) In all seriousness, that's the idea behind open source. More eyes on the code means more white-hat eyes on the code as well as black-hat eyes. Whether that idea actually works out in our favor is something we will learn (or not learn!) in the coming decades! Good addition to the discussion! (If I may proffer a case study to further your argument, Ken Thompson's login backdoor is an example of this revealed all the way back in 1984) | |
| May 9, 2019 at 12:48 | comment | added | Murphy | Paranoid thought on side effects of having a strong culture discouraging people rolling their own: it guarantees that everyone ends up using a tiny number of libraries for all crypto work... making it vastly more tractable for any capable group to compromise the majority of all communication by targeting about a half dozen libraries. | |
| May 9, 2019 at 12:43 | comment | added | Dohn Joe | With very high risk/high difficulty code you really want to go for a well-vetted, possibly even open source, crypto library. Many pairs of eyes have a higher chance to spot errors, then few. | |
| May 8, 2019 at 21:12 | comment | added | Monty Harder | @CortAmmon Yes, people go after all exploitable software, but crypto is seen as a high-value target because it's used to protect things of value. If an attacker can leverage a flaw in a crypto library that's part of an authentication scheme to gain access to a system, they can do a lot of damage. | |
| May 8, 2019 at 18:16 | comment | added | Alex Reinking | @CortAmmon - That can be reasonable, though I'll caution that there's a difference between UB and implementation-defined behavior. If you take that philosophy, then you must also acknowledge that you are dependent on not just the vendor, but the particular version and patch level. | |
| May 8, 2019 at 16:35 | comment | added | Cort Ammon | @Nelson I've been trying to figure out if that's really a difference or not. I do believe people look very actively at all exploitable software, crypto or not. I think crypto is simply a user-facing library which, if compromised, likely exposes poorly secured software underneath (which depended on the crypto). This is pure conjecture, but I would expect software such as Apache's httpd or the Linux kernel TCP/IP stack are attacked just as brutally as crypto software such as OpenSSL. Then again, I'd also recommend the "do not roll your own" for those sorts of libraries as well! | |
| May 8, 2019 at 16:24 | comment | added | Cort Ammon | @AlexReinking You share an opinion with the GCC devs =) It is true that UB is UB, unless you specifically target a compiler and its particular behaviors (in which case it is UB by the spec, but not UB for that compiler). The point of that section was to show how tremendously subtle these bugs can be. And it can even work for several versions of your compiler, passing your testing, only to crop up when you upgrade compilers later and the compiler responds to the UB differently. | |
| May 8, 2019 at 12:19 | comment | added | Denis de Bernardy | On the topic of compilers, there's also the possibility of it being malware. | |
| May 8, 2019 at 10:21 | comment | added | Alex Reinking | One doesn't fight the compiler when it comes to undefined behavior (that would imply it's misbehaving), one instead fights the C language and the way it makes UB hard to spot. If you don't like C, then either don't use it or formally propose a revision. | |
| May 8, 2019 at 10:19 | comment | added | Alex Reinking | Any code, not just crypto code, that "relies" on undefined behavior can't be trusted, period. Code that invokes UB is essentially meaningless and there's no way to contain the undefinedness. The cases you mention where the compiler "ruins" the code by applying an optimization are an artifact of the illformedness of the source it was given. That's not an error on the part of the compiler, but on the programmer. | |
| May 8, 2019 at 7:36 | comment | added | Nelson | @CortAmmon and the key difference is when crypto is involved, people will very actively look for all your flaws and have good reason to never tell you. They will literally throw every trick that currently exist, then move to things that have not been thought of yet. | |
| May 7, 2019 at 15:42 | comment | added | Cort Ammon | @MartinBonner Agreed, not crypto code, though I did hear that it hit MySQL as a vulnerability years ago. They "properly" checked for a circular buffer overflow, but did so using pointer overflow, which is UB, so the compiler compiled their check out. Not crypto, but one of those little things that you can't afford to get wrong in crypto. | |
| May 7, 2019 at 14:43 | comment | added | Martin Bonner supports Monica | The slightly-out-of-order assignment wasn't in crypto code, and is something all C and C++ developers need to be aware of. (Of course, it's potentially more expensive in crypto code). | |
| May 7, 2019 at 14:18 | history | answered | Cort Ammon | CC BY-SA 4.0 |