It never meant "don't implement AES/RSA yourself". Nobody sane does that; there has never been a need to convince people not to write their own implementations of AES. Ironically, doing your own AES is one of the less-scary freelancing projects you can undertake. Don't do it, but the vulnerabilities you'll introduce are lower-tier than the ones you get using OpenSSL's AES.
It has, always, mean "don't try to compose new systems using things like AES and RSA as your primitives". The serious vulnerabilities in cryptosystems are, and always have been, in the joinery (you can probably search the word "joinery" on HN to get a bunch of different fun crypto vulnerabilities here I've commented on).
Yes: in the example provided, you rolled your own cryptography. The track record of people building cryptosystems on top of basic signature constructions is awful.
I assume you've never seen AES written in vbscript? Generally, the thought process goes: This thing needs AES, I want to talk to it, I know $language, and wikipedia has the algorithm. The idea that AES is there for a reason ( like security) never enters the thought process.
Someone is building a shed, not a whole building, and stopped listening to real builders with their nitpicky rules long ago. It works great, until the shed has grown into a skyscraper without anybody noticing, and an unexpected and painfull lesson about 'load bearing' appears.
I ran the Cryptopals challenges. I have been sent AES implemented in 4 different assemblies, Julia before it was launched, pure Excel spreadsheet formulae, and a Postscript file.
There must be beauties in there;-). Even so, the fact that it's called Cryptopals indicates a public having some basic level of care about crypto. The non-it person hacking an excel macro together to get some job done has a very different attitude, and they do run their stuff in production.
The public should have a basic level of understanding and care of crypto. The logic of those challenges is that encouraging people to break cryptography is always prosocial; building it is a little more complicated, in the same sense as surgery.
I want to roll my own variant of AES (I know, I know!) CTR mode for appendable (append-only) files that does not require a key change or reencrypting any full AES block. Big caveat, this design doesn't have a MAC, with all the associated problems (it's competing against alternatives like AES-XTS, not authenticated modes).
Partial blocks are represented by stealing 4 bits of counter space to represent the length mod block size. This restricts us to 2^28 blocks or about 4GB, but that's an ok limitation for this use.
So say you initially write a file of 33 bytes: two full blocks A and B, and a partial block C. A and B get counter values 0 (len) || 0 (ctr) and 0 (len) || 1 (ctr). C is encrypted by XORing the plaintext with AES(k, IV || 1 (len) || 2 (ctr)).
You can append a byte to get a length of 34 bytes. Encrypted A/B don't change. C_2 is encrypted by XORing plaintext_2 with AES(k, IV || 2 (len) || 2 (ctr)). Since the output of AES on different inputs is essentially a PRF, this seems... ok?
Finally if you append enough bytes to fill C, it gets to len=0 mod 16. So the long and short if it is: no partial or full block will ever reuse the same k+iv+len+ctr, even rewriting it for an append.
> I want to roll my own variant of AES (I know, I know!) CTR mode for appendable (append-only) files that does not require a key change or reencrypting any full AES block.
I want the contents to be unreadable to an attacker who is able to steal a disk. I want to be able to append to files but not overwrite them in place, and do partial reads without decrypting the entire file.
So... you've pointed out the problems, what are the solutions?
What am I allowed to use as primitives to compose systems that require cryptographic functionality? If I'm writing medical device software and the hospitals I'm selling to say I can't store files in plaintext on disk, but also some security expert on HN says I shouldn't use AES as a piece of the solution because that's "rolling my own crypto" and too dangerous, what should I do? Mandate that postgres configured with encryption be used (even if the application is simple and doesn't require a full db)? That will almost certainly harm the prospect of the sale because having to get hospital IT involved introduces a lot of friction. Or are you saying "use sodium to encrypt the file, don't try to do it yourself with AES"?
There's a subtext here of "what do I do when the high-level libraries like Sodium don't do exactly what I need", and the frank answer to that is: "well, you're in trouble, because consulting expertise for this work is extraordinarily expensive".
We have an SCW episode coming out† next week about cryptographic remote filesystems (think: Dropbox, but E2E) with a research team that reviewed 6 different projects, several of them with substantial resources. The vulnerabilities were pretty surprising, and in some cases pretty dire. Complaining that it's hard to solve these problems is a little like being irritated that brain surgery is expensive. I mean, it's good to want things.
> There's a subtext here of "what do I do when the high-level libraries like Sodium don't do exactly what I need", and the frank answer to that is: "well, you're in trouble, because consulting expertise for this work is extraordinarily expensive".
...which is exactly why people roll their own crypto. Security folks don't seem to realize/care that money is a real constraint at most companies (esp. startups) and security can easily become a money furnace. When the only two options are: "use sodium" and "extraordinarily expensive consultant" then devs turn to the third option: https://pkg.go.dev/crypto/aes
Boom, file encrypted, requirement fulfilled, money saved, sale made. Perfectly secure? Probably not. The docs even say "The AES operations in this package are not implemented using constant-time algorithms". But maybe that's an acceptable tradeoff for your target risk profile.
Second class sodium is still a hell of a lot better than setting up your own. For go in particular, writing your own wrapper is a reasonable option. It's a handful of lines of code per function used.
I don't have a full guide for identifying a proper equivalent, but "constant time" is a requirement.
It might be in many cases, but not every language it seems has explicit sodium support. Golang for example, has this not-widely-used wrapper (https://github.com/jamesruan/sodium) maintained by some random guy which might not be desirable to use for a variety of reasons.
Want a specific solution for your specific use case? Talk to an expert to guide you through the design and/or implementation of a tool for solving your specific problem. But don't expect everyone writing for a general audience (read: Hacker News comments) to roll out a bespoke solution for your specific use case.
It has, always, mean "don't try to compose new systems using things like AES and RSA as your primitives". The serious vulnerabilities in cryptosystems are, and always have been, in the joinery (you can probably search the word "joinery" on HN to get a bunch of different fun crypto vulnerabilities here I've commented on).
Yes: in the example provided, you rolled your own cryptography. The track record of people building cryptosystems on top of basic signature constructions is awful.