Re: [Cfrg] Threshold signatures

[Bill Cox <[e-mail]>]

On Fri, Jan 3, 2020 at 7:04 AM Phillip Hallam-Baker <[e-mail]>
wrote:

>
> What is unclear to me is whether these schemes are generally useful
>> because:
>>
>> 1) It is important for the server to know whether the password guess was
>> correct, which is a key signal in rate-limiting.
>> 2) Secret shares can only migrate to new HSMs/cloud providers when the
>> user re-enters their password.
>>
>> More traditional threshold password-protected secret sharing schemes
>> address these issues, at the cost of higher complexity and more
>> communication rounds.  Which way should the world go?
>>
>
> Lets make it easy to use public key authentication across devices and
> forget about passwords altogether.
>

Yes, kill passwords, but please don't disable  my device unlock secret.

Both Apple and Google use secure hardware to protect your phone unlock
secret, and these HSMs (Titan chips in Google's case) will restore your
data to your new device if you first login, and then prove you know the
unlock secret.  Neither Google nor Apple can trivially decrypt your data
due to hardware rate-limiting.  I would guestimate that about 100M people
per year are currently making use of these features.  Can we ignore 100M
data recoveries per year?  Most users around the world still only have only
one device running Android or IOs.  Running a Mesh protocol on a USB key
for $15 would be great, but we're finding that users don't want hardware
keys.  It might be simple to replace all the crypto protocols currently
baked into all the world's devices, than to change user behavior.

When I want to recover my data on a new device after hot-tubbing for an
hour with my only Android device (happened to me 2 years ago), what is the
right protocol?  There are two main threshold schemes, OPRF-based, and
traditional pasword-protected secret sharing.  Honestly, I'd be interested
in any good insight into which way to go.