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?
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.
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.
>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.
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.
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.
The author incorrectly calling them "elliptical curves" is like nails on a chalkboard. An "elliptical" is an exercise machine or an adjective used to describe something shaped like an ellipse. The set of points in a field satisfying an equation of the form y^2 = x^3 + ax + b (which set, when enlarged to include the point at infinity and associated with the point addition group law, forms an abelian group) is an "elliptic curve".
You're letting your modern biases color how you view Tacitus' writings. Most people educated in the last ~hundred years or so were taught "history" as you understand it - an impartial account of the facts of an actual event or person. This view of history is actually pretty recent, and it's widely understood that ancient historians did _not_ practice what we would consider the modern discipline of history. For example, Herodotus is considered the historian ne plus ultra of the ancient world, but he still wrote about lots of weird shit like zombies and races of headless people.
It's not so much that modern historians think Tacitus was too "biased" to "record history accurately"; they read his works critically because they know he wasn't really even trying to record history accurately in the way we think about doing that today.
EDIT: Another good example of ancient versus modern history is Pericles' Funeral Oration, as related to us by Thucydides:
https://en.wikipedia.org/wiki/Pericles%27_Funeral_Oration
Thucydides probably edited the speech heavily (even by adding or removing content), and may have even combined multiple different speeches to create what we know as the speech. A modern historian would most likely blanch at the thought of doing this, but Thucydides was fine with it because he wasn't even trying to relay an impartial and 100% accurate account of the events of the Peloponnesian War (as a modern historian would).
Can you explain how you would use FHE instead of garbled circuits in the Arx range query data structure? I don't see how that would work - wouldn't you have to (re-)introduce interaction to let the server learn intermediate results?
TFHE is not even in the same galaxy as CryptDB. Comparing the two is like comparing an apple and a 2007 Honda Civic. They're polar opposite approaches to executing queries on encrypted databases.
Fully homomorphic encryption isn't tremendously useful for database queries - you end up having to put the entire database in a massive FHE ciphertext, then expressing the query as a circuit which requires time linear in the size of the database to return a result.
This paper is a fairly convincing counter-argument to another recent work (https://arxiv.org/abs/1707.03501) on physical adversarial examples for autonomous vehicles. The other paper argued there was "no need to worry" about such physical attacks.
This isn't for lack of trying on the part of cryptographers - unconditional proofs of security for most modern cryptosystems would imply that P and NP are separate. For example, a direct proof that SHA-256 is collision-resistant would imply that one-way functions exist unconditionally.
The failures of the academic cryptography community to provide solutions to real-world problems in general are well-documented, and I will not belabor them here (q.v. Rogaway's "The Moral Character of Cryptographic Work").
I will only say that I don't think this problem (strong security + performance) has been on the minds of very many people for very long, and this work is really still in its infancy.
Another really interesting potential benefit of this work is enabling users to create longer, more complicated passwords. The idea is that if users are less encumbered by typos and small errors, they'll be able to use stronger passwords while devoting the same amount of "brain space" (so to speak) to correctly using them.
EDIT: The authors are probably too modest to tout this, so I'll do it for them: this work won "Best Student Paper" at IEEE Security and Privacy last year.
To be clear: nowhere in this paper did we claim any particular solution is useless. However, the degree to which these systems are useful, and what situations they are useful for, is not well-understood. Prior work has shown that the encryption used in many of these systems is breakable (i.e. the plaintext is recoverable with near-perfect accuracy) with simple attacks. See, for example, this recent paper (https://eprint.iacr.org/2016/895) on cryptanalysis of order-revealing encryption.
Respectfully, I find this "more secure stuff is slow so we have to live with what we've got" argument to be specious. There simply is no evidence that a fast encrypted database must also provide very weak confidentiality guarantees.