Hacker News new | ask | show | jobs
by jen729w 2470 days ago
Same way I feel about security domains at work: you either have to trust encryption, or never use any network. It’s that binary.

At work I’ll see people — the security team, usually — taking some already-encrypted thing and re-hardening it to the nth degree. I think that’s stupid. If you don’t trust your encryption, don’t bother using it. If you do trust it, stop there. It’s maths. It’s proven.

I feel the same about 1Password. I trust that they encrypt my stuff with trusted encryption. That’s it.

3 comments

It's not about trusting the encryption, it's about trusting who does the encryption.

If you are encrypting a password store and using the cloud only for sync, you're trusting an encryption standard.

If you are using a cloud based password manager from a service provider, they may be using encryption, but your trust has to be in the company and their employees.

It's a rather large distinction.

>maths. It’s proven.

No they are not. That’s one of the things that makes designing correct crypto systems difficult. Going the wrong way through most cryptographic trap doors is conjectured to be difficult but I’m unaware of a single one that’s proven.

The one-time pad has been proven to have perfect secrecy.

Given a ciphertext, the only information available is its length.

This makes a lot of assumptions:

You have a way to securely exchange or store the one time pad (at that point just use slices of the pad as passwords)

The pad is sufficiently random

This was how RC4 was used to encrypt things; RC4 is fundamentally a random number generator. To use it you throw away the first so many bytes (because they could be used to recover the state of the machine.) and then the rest was used as a pad. Unfortunetly patterns in the data can make it easy to recover the raw RC4 pad (uncompressed blank bitmaps for example) and this can be used (again) to recover the state of the machine generating the numbers. On top of that it turns out RC4 is a lot more predictable than people originally thought.

Essentially all a one time pad does is move the problem somewhere else, often that other place isn't great.

Lots of truth there, but there is an argument to be made about layers of security. If the second level of encryption is of very different kind than the first (different encryption library made by different people), sometimes the hassle with it may be worth it.

For example, some backup providers will encrypt your data for transport to their machines and then reencrypt them for storage. Would you trust TLS implementations in the path and provider's application to protect your data? Or would you rather encrypt yourself and only then let the provider handle it?