We need better crypto primitives and modules - there are lots of standards out there that are dangerous! Things that seem like they should work, don't and this leaves security holes where they shouldn't be, or creates situations where an application must be implemented with knowledge of the internal features of crypto "primitives". example: length-extention attack on api authentication
What is right about the word primitive: simple api + clear security properties (* this isn't always the case, but it can and should be)
But, there are other great crypto "primitives" (modules) that are made from actual primitives but never the less provide a simple api and clear properties. A good example of this is nacl's crypto_box it has eliptic curves, salsa20 and poly1305 to create a encrypted buffer that can only be decrypted by the intended key.
- hash (except hashes that have length extension attacks)
- digital signatures (but not RSA because it requires padding)
- hmac (though, this is not necessary if you have a hash that doesn't have length extention vuln)
- key exchange (diffie-helman or ecdh)
these are primitives that can be
- symmetric cipher (avoid AES - too many dangerous modes, and difficult to implement safely)
- asymmetric encryption (because you can only encrypt short messages, but especially RSA which also requires random padding)
- symmetrical authenticated encryption (symmetrical cipher + hmac)
- cryptoBox (asymmetrical encryption + authenticated symmetrical encryption + signature)
- content-addressable-store (immutable files keys by their hash)
There are other possible modules that do not exist yet, but should!!! (it sounds like you'd definately want the last one, but I include these all because the earlier ones are much simpler)
-
authenticated encrypted duplex stream, forward secure content, but leaks participant keys.
-
authenticated encrypted duplex stream, forward secure content, participant keys are secure (but not forward secure)
-
authenticated encrypted duplex stream, forward secure -- including participant keys. (http://curvecp.org/ looks close here, but since it goes further and creates a udp protocol it might not be usable in some situations - so I think we need a variety of tools, since security and simplicity are tradeoffs)
-
signed append-only log
-
signed merkel tree (like the log, but can verify subsections of the log - would be useful for streamable, seekable live-video)
-
symmetrically encrypted kv store
encrypted messaging with plausible deniability is all the rage right now... but the demands are so high, most applications would have other vectors that undid the security of the messaging (for example, if messages are stored long term, as in email)
I think this is what djb is doing, but I don't get the impression that the rest of the crypto community has realized this yet... Most crypto text books seem like they spend most of their time explaining bugs and edgecases in crypto standards (AES, RSA, SHA)
i was thinking the same thing earlier this very day. The things you mention are what makes crypto confusing. The gotchas, edge case scares, and awkward APIs.