[Autocrypt] usability and passphrase-less keys
look at my.amazin.horse
Thu May 4 03:32:16 EDT 2017
Good summary, thanks for that!
One more point I have in mind is that the current passphrase workflows conflate storage and transfer encryption. In the typical case ("just barely able to remember") , a chosen passphrase will be way overkill for storage protection, and not enough for transfer protection.
It's also worth pointing out that openpgp isn't even particularly good at this mechanism, e.g. none of the available s2k algorithms is memory hard. Local storage encryption doesn't need to be compatible with other imementations, so it would make a lot more sense to use scrypt or argon2 for this purpose.
I have been procrastinating this issue for a while. We decided to demote passphrases to a supported (but not encouraged) workflow in openkeychain a long time ago,and I made some progress with the necessary changes, but it's not done yet.
On May 4, 2017 1:54:25 AM GMT+02:00, Maikel <maikel at email.org.au> wrote:
>This is my first contribution on the list, so tell me if I'm missing
>some conventions here.
>> I eventually perceived us arriving at the conclusion that there is
>> no good reason for defaulting to require passphrases when generating
>> a key.
>You discussed the cases when the key is stored on the user's device.
>I think that the conclusion is reasonable in this passive attack
>But what about the key sharing? Since there is no specification of the
>key sharing yet, we don't know the implications of this. Anyway, any
>sharing should protect the key independently. The docs say:
>> Todo: Crically consider end-to-end encryption for MUAA messages.
>Autocrypt mailing list
>Post: Autocrypt at lists.mayfirst.org
>List info: https://lists.mayfirst.org/mailman/listinfo/autocrypt
> Send email to: Autocrypt-unsubscribe at lists.mayfirst.org
>You are subscribed as: look at my.amazin.horse
(sent from K-9 Mail)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Autocrypt