Re:Show HN: Puree – Password-based Uniform-Random-Equivalent...
by tempay on Sunday June 07, 2020 @07:30PM
(#23452023)
> 1. Are key-based (e.g., require a 128-bit or 256-bit key) rather than password based, in which case, the key must stored elsewhere. (Where do you store the key?)
Is there a reason why this is notably different? Why can't the password be hashed to get the fixed length key?
Re:Show HN: Puree – Password-based Uniform-Random-Equivalent...
by viraptor on Sunday June 07, 2020 @08:08PM
(#23452263)
Yes, it's a pretty standard approach. I can't even recall anything that uses passwords directly these days. Mostly due to world relying mainly on aes where you have to derive the key.
Re:Show HN: Puree – Password-based Uniform-Random-Equivalent...
by jcynix on Monday June 08, 2020 @03:41AM
(#23454455)
> 2. Ask the user to store a (non-random-looking) disk-encryption header elsewhere (i.e., “detached header mode”). (Where do you store the header?)
If the header isn't needed on a daily basis, storing it as a QR-Code on paper would be a possibility.
> To be fair, some tools do support support completely-random-looking disk layouts, but in most cases, they either:
> 1. Are key-based (e.g., require a 128-bit or 256-bit key) rather than password based, in which case, the key must stored elsewhere. (Where do you store the key?)
> 2. Ask the user to store a (non-random-looking) disk-encryption header elsewhere (i.e., “detached header mode”). (Where do you store the header?)