Re: [Cfrg] Threshold signatures

[Phillip Hallam-Baker <[e-mail]>]

OK, right, you can keep your device unlock codes and your device based
biometrics. Let us leverage both.

The reason for focusing on this threshold stuff now is that we can
supplement the data locking capability you are describing with a key
binding capability.

Well over 90% of TLS key breaches are the result of private keys being
recorded to backups. Most of the rest are due to a machine on the network
being compromised and a private key file being found on an accessible
share. CA breaches are close to non existent and which is why we can have
the post mortems and blamestorming sessions.

Binding TLS keys to a key that is embedded in and cannot be extracted from
the Host service without national lab scale tech (and physical access)
would greatly reduce exposure.

Splitting the code signing key for authenticode between a cloud service and
the software provider would only require the CAs to offer the relevant
cloud service. Sure, some enterprises that have legacy KMS software that
would lock them in to the obsolete approach. But that is less than 1% of
the software providers.

Threshold sig was not a priority for me at the start as I thought multisig
would be sufficient. That may well be true. But I think it is going to be
much easier to sell a complete suite of threshold capabilities than
something that looks like a work in progress. Put threshold decryption and
Key generation on the table and people will say 'let me know when you are
finished'. Add threshold sig and there is a complete set.


On Fri, Jan 3, 2020 at 11:14 AM Bill Cox <[e-mail]> wrote:

> 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.
>