If part of your software product is developing a new database, your product is now a database
Or, if part of your astrophysics experiment involves developing a new launch vehicle, you're now a launch vehicle project (forget what I'm poorly paraphrasing here, maybe https://spacecraft.ssl.umd.edu/akins_laws.html )
So for example, they'll feel they are abiding by that rule by not implementing SHA256 themselves while also creating a novel cryptographic high level protocol (like TLS or SSH). The advice was more originally meant for people cooking up their on novel ciphers, but its applied more often today against reimplementing standard ones.
Though it's still best to not implement SHA256 yourself-- and generally pointless, it's extremely unlikely that someone who does would get it substantially wrong with even a normal amount of effort... you're still way better off implementing SHA256 and AES (which is difficult to make sidechannel free) and whatever yourself than constructing some a novel high level protocol.
If there is cryptography in your product the boundary probably doesn't just magically stop at the functional call into AES. Your entire product is to some degree "cryptography"-- though how much depends on the details.
And this is where "abstinence only" cryptographic education really fails: By saying _never do it_ we encourage an extremely narrow definition of "it" that often gets limited to "don't implement your own standard blockcipher" or "don't cook up your own blockcipher" and ignores all the higher layer stuff, where you often can't avoid engaging in a bit of crypto development.
... and, of course, most of the meaningful vulnerabilities end up in those higher layers. The implementations you might find are also not always very good but unfortunately it can be hard to tell which are and which aren't.
Don't roll your own crypto if you are releasing a product or if you are working on critical software.
DO roll your own crypto [1] for learning, messing around if you enjoy recreational programming. It's an awesome topic to play with and rolling your own crypto can give you an appreciation for the solid algorithms that survived being cracked for a long time.
It is very sad there there are corners of computer science that are "forbidden" when the whole field should be about learning.
I've encountered important professionally produced pieces of software using 'crypto' code that was just whatever google turned up on github and was actually a student work from a student that didn't have it sufficiently right.
Unfortunately there is also plenty of bad stuff that explicitly claims that it is good, but at least we can make people's lives a little easier by labelling learning experiments as such. :)
Sadly, writing something is only so informative. Everyone can write a cryptosystem that they themselves can't break. :)
Creating something that you think is secure and have other people break it is much more informative, but review is so costly that most people that get these lessons get them too late. Similarly, breaking someone elses system is extremely informative, but it has an extremely steep learning curve!
Reproducing common tools is a common exercise when you are learning.
A school, we rewrote a significant part of libc, a unix shell, a FTP server, a compiler, etc... Of course, our work was inferior to anything on the market and no sane person would use it in production, but it wasn't the point. We learned a lot doing that and that's the important thing. The code itself got lost like as old exercise books.
A lot of anti-patterns are actually good when you are learning, and reinventing the wheel is the best example.
I think it was Bruce Schneir in the Cryptonomicon appendix (someone correct me if I'm wrong) who said something along the lines of "anyone can come up with a cipher that they couldn't imagine breaking, and then think it's unbreakable". That captures it so well.
The story about the Crystalline author reminds me of of this thread where someone turns up to the C++ standard proposals group with some mildly cockamamie data structure he has invented:
This is a brand new thing of unclear utility, so after some discussion, Bryce Adelstein Lelbach, chair of the library evolution working group, writes:
> I'd suggest moving this discussion to the Boost mailing list, which would be closer to a good fit for this work than the standard.
To which the author replies:
> I don't think so, sorry!
I still laugh out loud when i think about this, two years later. I've even started using that phrase as a response to reasonable requests i just don't want to comply with.
That’s possibly one of the nicest mailing list threads I’ve read in a long time. The responses have constructive feedback and people even went into the code and evaluated it when others would have brushed the entire thread off as a crackpot submission.
Unfortunately crypto is one of those fields where Brandolini's law applies very strongly: it takes at least an order of magnitude more effort to refute bullshit than to create it.
I coined the nickname "Deep Crack" for the of EFF's DES cracker that John Gilmore developed (which was agitprop intended to expose a deep crack in the US government's export control policies, with a nod to Deep Blue and Deep Thought):
Sorry for the off-topic comment, but since you are here and we are talking about names... Do you know why did John Gilmore name his server "toad.com"? Is there any special meaning in the name? In the past it was used to host many projects like the Cypherpunk mailing list, and its domain name is a question that has been puzzling me for many years, I'd love the know the answer. Thanks.
It's short for "Hoptoad" (which was also its uucp address), from Kenneth Grahame's book "Wind in the Willows". His house in the San Francisco Haight is known as "Toad Hall", of course!
However his nickname is not "Toad" but "Gnu" (his ITS account was GNU@AI), before project Gnu adopted the same three letters as a recursive acronym.
John Gilmore also used to have "Jesus.com", but he let Jesus.com expire. But after it died and came back from the dead many times, the Metropolitan Community Churches finally ended up with it. They're pretty cool as far as Jesus freaks go, so you can rest assured that Jesus.com is in good hands.
I wonder what the whole story is behind Jesus.com's journey? It's probably more twisted than sex.com.
Thanks for this great article. I can't stop laughing.
Yesterday, I was completely puzzled by Terra Quantum's claims, their press release was written in an extremely confident tone and it almost fooled me (I didn't realize they "worked on" on MD5 or Quantum Demon...).
> the company said its research found that even the strongest versions of AES encryption may be decipherable by quantum computers that could be available in a few years from now.
Everyone knows 256-bit symmetric ciphers in general are post-quantum secure, I had a discussion a week ago (and someone also reminded me about the caveat of block size, the blog author also commented [0]). Then, yesterday the news hype sounded like they've discovered an efficient quantum algorithm to attack the internal structure of AES, and it can break even AES-256 (despite 20 years of research in post-quantum cryptography, nobody found one).
I said "big if true..." when I read it. Unsurprisingly, it turned out that it isn't just not true, but not even wrong. The company doesn't even understand the basic of cryptography.
the conclusion really drives home the point of crackpot cryptography being especially common in cryptocurrencies.
the IOTA devs also doubled down after being called out that their Kerl-hash function being utter garbage. After various very angry people showed proof that it was broken @c___f___b started claiming "collision-resistance wasn't really required in their case".
there was also the Voatz blockchain fiasco, the bitfi wallet scams, and many others.
As Dan Guido said:
"... It’s ok to get angry at someone trying to harm people. I was shocked that more people haven’t done the same"
so I will never not call them out. On the other hand calling them out also creates a dilemma because it gives these imposters and their scams even more oxygen and eyeballs. The best way to fight them I have actually found is not twitter but LinkedIn. On LN it pisses these people off a lot more if you fight their PR campaigns there, because they worry about how they're seen (while on twotter nobody cares). Also since most of them are sales/marketing oriented scammers that use Tech-jargon as a front for their scams you actually fight them on their turf ...
Reminds me of a scheme someone showed me once; not only was it "perfectly secure crypography" it also made the data more compressible according to their pitch. I was surprised they didnt advocate multiple runs; eventually all knowledge could be represented in one unquantifiable byte.
Getting crypto/signing correct is kind of a pain. Has been for years. I personally have been noodling with with it for a personal project. There are probably at least a couple dozen different hashes and crypto libs to use. Make sure you pick the right one for the job speed/secureness. Make sure you do not pick one that is out of date and any old chromebook can crack it in 10 mins. Make sure the library you are using is not out of date but best practice from 15 years ago (that blog from 15 years ago was really nice) and you really should be using something else now. Then even if you are using the right stuff make sure you are using it correctly. Do not expose this bit or that bit or it does not work. Make sure you picked one that does not allow for known plain text attacks or if it does it does not matter depending on use case. Is your entropy for your key creation good, is it really random? How is your salt pattern created/stored?
Crypto bits make me feel like I have an iphone 4 and I am holding it wrong.
> I was surprised they didnt advocate multiple runs; eventually all knowledge could be represented in one unquantifiable byte.
I've seen many proofs that this is impossible. Usually they use a counting argument such as the pigeonhole principle, and show that you cannot have a compression function C and matching decompression function U with all the following properties:
1. U(C(f)) == f for any file f of at least one byte. I.e., compression is always reversible.
2. C(f) is never larger than f.
3. C(f) is sometimes smaller than f.
4. For any file f larger that one byte, iterating C a sufficient number of times will result in a file of exactly one byte. Iterating U a sufficient number of times on that one byte will produce f.
Many of the proofs are a little sloppy in how they define or specify things, making it easy to give a counterexample. Here is such a counterexample:
1. Order all possible files of at least one byte as follows:
1a. All n-byte files come before any m-byte file for all m > n.
1b. Order all n-byte files by treating them as 8n-bit unsigned binary numbers and ordering them by ascending numerical value.
2. Let I(f) be the index of file f in that ordered list of all >= 1 byte files. Let F(i) be the file whose index is i. Let Z = the one-byte file whose bits are all 0s. Let E be an empty file.
3. The compression function C(f) is as follows:
C(Z) = E
C(f) = F(I(f)-1) if f != Z
4. The uncompression function U(f) is as follows:
U(E) = Z
U(f) = F(I(f)+1) if f != E
So what's the catch?
Here is the catch. Suppose f1, f2, f3, ... are a bunch of n-byte files. It is true that iterating U enough times on any of them will result in a one-byte file. In fact you can iterate to get each down to a file consisting of a single null byte.
So now you have a bunch of files f1', f2', f3', ... each consisting of a single byte. Imagine you need to get f1 back. OK, you iterate U on f1'.
But how many times do you have to iterate? It will be around 2^(8n) iterations. Get the number of iterations wrong and you'll end up with a different n-byte file.
To make sure that uncompressed f1' gives you f1, not f2, f3, ... or some other n-byte file, you have to remember exactly how many times you iterated C when you compressed f1.
That essentially requires storing an n-byte random integer somewhere. So yeah, you compressed your n-byte f1 down to a 1-byte f1', but a byproduct of that was n bytes of metadata you have to store somewhere. Oops.
I was looking at commercial encryption and compression libraries (when that wasn't even black magic yet but more kooks and woo, obviously), for a "fax on computers" text messaging over modems thing. DOS TSR days.
We eventually wound up using LZ-like dictionary / codebook data for the various peers which provided compression, and "encoding" obfuscation that was "even better" than encryption; tho we had that too (with fixed/predictable keys).
Real key exchange was a user impossibility. Keeping a dictionary wound up being an incredible win because our target market's data was enormously redundant. I was using random usenet text as test data and the real users saw 80% better performance than my tests led me to expect.
I was under the impression it was a king kong like monster with at least one of its dimensions being several hundred kilometers in size. Luckily the brilliant minds at Terra Quantum set me straight.
This motto should be read in the same vein as:
If part of your software product is developing a new database, your product is now a database
Or, if part of your astrophysics experiment involves developing a new launch vehicle, you're now a launch vehicle project (forget what I'm poorly paraphrasing here, maybe https://spacecraft.ssl.umd.edu/akins_laws.html )