I don't really understand the threat model in which this provides a real security benefit. If someone can inspect the contents of memory, can't they also recover the encryption key somehow?
Readit Newsswordswinger12 commented on A proposed API for full-memory encryption lwn.net/Articles/776688/... · Posted by u/l2dy
swordswinger12 commented on Zadie Smith’s Varieties of Individuality newrepublic.com/article/1... · Posted by u/samclemens
Zadie Smith's essays are tremendous. I highly recommend her earlier collection "Changing My Mind".
Being offline does not ensure security against unverified plaintext. Imagine a colossal implementation fuckup (e.g., using strncmp to verify tags, ala Nintendo), or perhaps a hardware glitch flipping the verification bit to always return true. Ideally, i.e. with a robust AE scheme, you would hope that an altered ciphertext would result in random plaintext, but in SIV this is not the case.
Alas, there are no standardized robust schemes, with AEZ making it to the CAESAR final portfolio being the most likely scenario of that happening.
AEZ uses a non-standard AES variant in a sui generis fashion; as a result some people have called its security into question: https://eprint.iacr.org/2016/832.pdf
Point being, its inclusion in the final CAESAR portfolio is far from clear at this point.
The plan for online authenticated encryption in Miscreant is to support Rogaway's CHAIN and STREAM constructions:
STREAM: https://github.com/miscreant/miscreant/issues/32
CHAIN: https://github.com/miscreant/miscreant/issues/33
These schemes achieve a security definition called OAE2 (STREAM specifically achieves nOAE, which Rogaway proves equivalent to OAE2) and are robust against reordering and truncation attacks. For more information, please see the paper:
Ah, thanks for the reply Tony. This would indeed prevent the problem I described. Kinda curious about the downvotes, since tptacek's original comment suggested nothing like CHAIN or STREAM, but on crypto HN you gotta roll with the punches.
This library implements a crypto primitive that sacrifices a marginal but measurable amount of performance to avoid a very common user error with crypto primitives --- repeating a nonce (a cryptographic counter). For perspective, this week's KRACK 802.11 bug is an instance of nonce reuse.
The primitive being provided here is an instance of SIV, which is widely considered the most conservative mainstream cipher mode that addresses nonce reuse. SIV is a moral cousin to Deterministic DSA and EdDSA, in that the "nonce" is based on a hash of the message. You can add additional nonce material, and that will improve the security of the system, but even with a constant all-ε stream of additional nonces, for most applications you're fine.
The downsides to AES-SIV are that the mode is "offline" and two-pass. You have to have the whole message available to encrypt with AES-SIV (the state needed for CTR mode comes from processing the whole message). This makes some kinds of streaming interfaces hard to implement. On the other hand, you can almost always delegate that kind of interface up one layer in your application stack and pass AES-SIV chunks of messages.
This library or something like it will eventually hit some kind of "1.0", and, at that point, if you can get away with the performance hit --- and you virtually always can, because bulk encryption isn't a bottleneck in most systems, and on the systems where SIV's performance hit matters you tend not to get much benefits from the "faster" stuff --- you should use this for bulk encryption. (Unfortunately, KRACK is a very good example of a setting that probably couldn't get away with using AES-SIV). As a crypto interface, it's better than NaCL.
>you can almost always delegate that kind of interface up one layer in your application stack and pass AES-SIV chunks of messages.
Without additional precautions this approach is vulnerable to a fairly basic chunk-reordering attack, since any re-ordering of the "chunks" is a valid ciphertext. I strongly recommend against this approach.
EDIT: Unfortunately there is not really a better way to implement a streaming interface on top of a nonce-misuse-resistant encryption scheme: it's fairly easy to prove that any nonce-misuse-resistant construction must necessarily be "offline" in the sense tptacek describes.
swordswinger12 commented on Cryptographic vulnerabilities in IOTA medium.com/@neha/cryptogr... · Posted by u/nehan
Does anyone know if the IOTA devs ever wrote down a justification for using a hand-rolled hash instead of, like, SHA-256? If so, can you link it in a comment?
EDIT: I feel compelled to explicitly say that this was a mind-bogglingly stupid thing to do, and there is almost no way to justify it. I'm just curious what they thought they were accomplishing.
Aren't there MASSIVE (read: showstopper) complications when you want to use FHE for "looping" computations?
I always thought FHE was only good if you can fully unroll your "fixed-length" computation, and even then you can only use each "program" once without compromising security.
The short answer is yes. There are some (slow) ways to fix this: https://people.csail.mit.edu/nickolai/papers/goldwasser-we.p...
Are there any known PHE or FHE schemes that can run a full blown virtual machine ?
All FHE schemes can run a full-blown virtual machine, but you might not live long enough to see Ubuntu finish booting up.
swordswinger12 commented on Decentralized, end-to-end encrypted Cloud Storage storj.io/... · Posted by u/doener
I may have missed something in the whitepaper, but using a confidentiality-only encryption scheme like AES-CTR seems bad because it enables trivial attacks on file integrity (bit-flipping attacks and such). How does Storj protect the integrity of a file? I see that proofs of retrievability are used, but PoRs don't guarantee protection against integrity attacks in general.