swordswinger12

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?

Zadie Smith's essays are tremendous. I highly recommend her earlier collection "Changing My Mind".

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.

The short answer is yes. There are some (slow) ways to fix this: https://people.csail.mit.edu/nickolai/papers/goldwasser-we.p...

All FHE schemes can run a full-blown virtual machine, but you might not live long enough to see Ubuntu finish booting up.

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.

There needs to be a word to describe the practice of arrogantly explaining a researcher's own results back to them on HN. Maybe HNsplaining?

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.

If your threat model is having a hard disk stolen, simply using full-disk encryption or whatever Redis offers is probably fine. Fair warning, though: this is a really weak threat model and won't do anything to protect the data against any stronger attacks.

It's worth pointing out that trusted execution for individual queries does not, in general, rule out the attacks discussed in this paper. If the database collects (for example) frequency information about queries, inference attacks can still be used to recover plaintext.

EDIT: The fundamental problem is that trusted hardware doesn't hide the access pattern by itself. Trusted hardware can be used to hide some kinds of access patterns, but it's highly nontrivial and has only been demonstrated in some limited settings. For example, there was a paper at NSDI this year called "Opaque" which showed how to use SGX to hide access patterns for some kinds of Spark queries.

The original goal of the academic "encrypted database" proposals like CryptDB was security against this kind of adversary. The idea was that if all the data is encrypted even when you're querying it, you get some security against a compromised OS. Unfortunately, in this paper we showed even this "always encrypted" approach has many subtle flaws that leave the data vulnerable to inference attacks.

To protect against an attacker with physical access to a machine may indeed be futile, but it should be possible to provide some measure of security against a malicious process running on the machine.

Defending sensitive data if the DB process itself is compromised, again, seems pretty difficult. That was the original goal of the academic proposals like CryptDB or Cipherbase - defense even against a fully malicious database server.

Whoa, really? Is this analysis available publicly somewhere? It would be really useful for further research on this topic.

Some IC3 people at Cornell have been looking at this in the context of smart contracts: http://www.initc3.org/files/Gyges.pdf

There is a lower bound by Bennett et al. ("Strengths and weaknesses of quantum computing", SIAM JoComputing 1997) that shows Grover's algorithm is optimal for the generic search problem, so further lowering the asymptotic runtime is probably impossible.

EDIT: Also note that quantum cryptanalytic attacks may be able to break specific symmetric ciphers by exploiting some structure specific to the cipher. But you're correct that QCs don't generically break symmetric cryptography.

THIS PAPER IS:

a nice, thought-provoking paper that is nevertheless purely speculative, and also more than a little tongue-in-cheek in parts. (Note that one of the keywords is "Make RSA Great Again".) It's basically pointing out that there is a small gap between the costs of legitimately using RSA and factoring via Shor's algorithm. With truly massive keys, this gap can be exploited to provide concrete security guarantees for RSA even in the presence of fast quantum computers.

THIS PAPER IS NOT:

a revolutionary new quantum factoring algorithm. They show how to apply quantum Grover search to a particular step of a known factorization algorithm based on elliptic curves.

QUANTUM COMPUTING DOES:

break public-key cryptosystems based on the hardness of factoring and finding discrete logarithms. Additionally, it gives a quadratic speedup in generic search problems (via Grover search) which effectively halves the key size of symmetric encryption schemes and yields faster algorithms for things like finding collisions in hash functions.

QUANTUM COMPUTING (PROBABLY) DOES NOT:

break all asymmetric cryptography. There is no known proof of this, but it's widely believed that asymmetric cryptosystems based on different hardness assumptions are not vulnerable to (non-generic) attacks by quantum computers.

It absolutely is - one of the keywords is "Make RSA Great Again", ffs.

>"ZKP is a new technology, with deep roots in the Israeli academic world."

This is false - zero-knowledge proofs were invented in 1985 by an Israeli professor working at MIT along with an Italian MIT professor and an American professor at Toronto.