[Cryptography] Key escrow scheme

[Phillip Hallam-Baker]

On Sun, Apr 9, 2017 at 1:51 PM, Jack N. <j.a.w.n at tutanota.com> wrote:

> 9. Apr 2017 15:06 by phill at hallambaker.com:
>
>
>
>
> On Sat, Apr 8, 2017 at 2:01 PM, Harlan Lieberman-Berg <hlieberman at setec.io>
> wrote:
>
>> Phillip Hallam-Baker <phill at hallambaker.com> writes:
>> > Making such a scheme usable is somewhat tricky because we would want to
>> > make the shares used to secure the key to be as small as possible for
>> > convenience which indicates 128 bit work factor for the master key.
>>
>> Why not simply use Shamir's Secret Sharing?  The security properties are
>> much stronger (SSS is information-theoretic secure such that a (k,n)
>> construction reveals no information with k-1 shares known.  The size is
>> fairly minimal too; IIRC, each share is no larger than the key itself
>> (thus, the total construction is n*bit size).
>>
>
> ​I am using Shamir Secret Sharing. But that only gets you from a set of
> key shares to a master secret. You still have to get from the master secret
> to the encryption key.
>
> If you use 256 bits for the master key you end up with 256 bit shares.​
>
>
> Couldn't the SSShares reconstruct the master secret which is the
> encryption key?
>
> the master secret needn't be another step removed from the shares.
>
>
> If you use a 256bit for the master key you dont end have to have 256bit
> shares, or did you mean 256shares?
>
>
> But i believe the normal approach to solving the problem, i think you are
> trying to solve is to use asymmetric encryption where the secret shares
> reconstruct the asymmetric private key info. Tho i fear you may have the
> same problem again if you have a fundamental misunderstanding on shamir
> sharing and prime secret size.
>

No, that is not the problem I am trying to solve.

Lets say we are doing RSA 4096. My scheme still allows me to escrow the key
using a set of 128 bit shares as the only thing the user keeps track of.. I
encrypt the RSA private key in AES 256 and store it on a cloud service as
the first step.

The steps for recovery are thus as follows:

1) Reconstruct the 128 bit master secret from the shares.

2) Take the UDF fingerprint of the master secret, this is the identifier
used to store the recovery blob in the cloud.

3) Use HKDF (RFC 5869) to derive the 256 bit key unwrapping key

​4) Use AES Key wrap (RFC 3394) to recover the ​key used to encrypt the
recovery blob.

The last step is only necessary because my content encryption scheme is
designed to minimize the number of code paths. Since key wrap is needed
sometimes, I require it always so as to simplify implementation.


What I am looking to do is to achieve a brute force work factor of 2^128
but to present the higher 2^256 Work Factor for anything that is faster
than brute force. It seems like to me that anything faster than brute force
is going to depend on some relationship between keys but I can't prove that
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170410/7df4a613/attachment.html>