Hacker News Reader

Comment by analogist | Hacker News Reader

Inside of TLS, 1Password uses an additional SRP handshake that negotiates a static secret (like a DHE), which 1Password uses to both authenticate the user and set up an additional AES-GCM transport encryption.

So even a full memory dump of what's transported in TLS should, as long as it's properly implemented, only reveal an SRP authentication session and subsequently symmetrically encrypted data.

(And inside that SRP-negotiated encryption should only be more symmetrically encrypted vault items, and RSA-encrypted vault keys. If properly implemented even complete TLS breaks do not break 1Password at all, even the cloud version. Properly implemented being the key words of course.)

View on HN

I typically think of "encryption inside of encryption" as a boondoggle more likely to somehow break things than make things stronger.

My confidence in that has dropped slightly in the past day.

I'm no expert, but intuitively it would seem that encryption-inside-encryption would be snake oil when they're meant to guard against the same layer/attack vector/threat model: for example, if you nest Serpent inside AES for a single local file encryption operation (ahem, TrueCrypt), that seems very gimmicky.

But if the encryption are supposed to protect separate and independent OSI layers or operation steps, then it would seem to me it's fully valid - specifically, in this case: - TLS dissolves inside HTTP-HTTPd endpoints or any reverse proxies, if used - additional SRP-negotiated AES dissolves inside client to the process doing key handling - final "actual" key encryption, handling at-rest encryption, and to make sure it's zero-knowledge to the storage handler

They seem to me to be guarding information leakage against very different parts of the key mangement process (storage, manipulation, http transport), and that doesn't seem to be snake oil to me.

>for example, if you nest Serpent inside AES for a single local file encryption operation (ahem, TrueCrypt), that seems very gimmicky.

I take it to be insurance against a future vulnerablility discovered in one of the algorithms. For some scenarios it seems like the cost can be worth it.

On the other hand, nested hashing has always seemed counter productive as it seems plausible that nesting hash functions can decrease the randomness of the image.

PGP email sent over TLS would be an example of nested encryption that people take for granted. So would E2E encrypted chat systems like iMessage, Signal, and WhatsApp, which encrypt each message on the machine, then use TLS to communicate with servers.

Interesting, thanks for the reply.

I wonder which password manager the original Project Zero thread referred to then if not 1Password.

It could be that it was 1password, but the only clear text was URL parameter names or JSON keys, with the values as encrypted strings in base64 or similar.

Reply on news.ycombinator.com