[146645] in cryptography@c2.net mail archive
Re: [Cryptography] Keeping backups (was Re: Separating concerns
daemon@ATHENA.MIT.EDU (Dirk-Willem van Gulik)
Fri Sep 6 10:09:39 2013
X-Original-To: cryptography@metzdowd.com
From: Dirk-Willem van Gulik <dirkx@webweaving.org>
In-Reply-To: <CAMm+LwhMJGvz80VpWVCp6JAsNy+UkyqYcHhR71OJxAQ3=iLcXw@mail.gmail.com>
Date: Fri, 6 Sep 2013 09:18:34 +0200
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: =?iso-8859-1?Q?Fran=E7ois-Ren=E9_Rideau?= <fahree@gmail.com>,
Perry Metzger <perry@piermont.com>,
"cryptography@metzdowd.com" <cryptography@metzdowd.com>,
Peter Gutmann <pgut001@cs.auckland.ac.nz>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============2062196047009580190==
Content-Type: multipart/alternative; boundary="Apple-Mail=_1C146403-0D82-4E6E-8072-16D799270C10"
--Apple-Mail=_1C146403-0D82-4E6E-8072-16D799270C10
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
Would be interested & interesting. Been doing the same thing with =
on-chipcard generated public keys to to the 'reverse' - be able to wipe =
a part of your off-site backup store by cutting up the secret. So I =
think there is a general case - and I've got a gut feeling that when =
propably analysed some of the usual assumptions around KDFs do not quite =
hold (as in effect one can often cause a lot of known plaintext to be =
passed in).
Dw.
Op 3 sep. 2013, om 17:02 heeft Phillip Hallam-Baker <hallam@gmail.com> =
het volgende geschreven:
> Want to collaborate on an Internet Draft?
>=20
> This is obviously useful but it can only be made useful if everyone =
does it in the same way.
>=20
>=20
> On Tue, Sep 3, 2013 at 10:14 AM, Peter Gutmann =
<pgut001@cs.auckland.ac.nz> wrote:
> Phillip Hallam-Baker <hallam@gmail.com> writes:
>=20
> >To backup the key we tell the device to print out the escrow data on =
paper.
> >Let us imagine that there there is a single sheet of paper which is =
cut into
> >six parts as follows:
>=20
> You read my mind :-). I suggested more or less this to a commercial =
provider
> a month or so back when they were trying to solve the same problem.
> Specifically it was "if you lose your key/password/whatever, you can't =
call
> the helpdesk to get your data back, it's really gone", which was =
causing them
> significant headaches because users just weren't expecting this sort =
of thing.
> My suggestion was to generate a web page in printable format with the =
key
> shares in standard software-serial-number form (XXXXX-XXXXX-XXXXX etc) =
and
> tell people to keep one part at home and one at work, or something =
similar,
> and to treat it like they'd treat their passport or insurance =
documentation.
>=20
> Peter.
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
> _______________________________________________
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
--Apple-Mail=_1C146403-0D82-4E6E-8072-16D799270C10
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=iso-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Would =
be interested & interesting. Been doing the same thing with =
on-chipcard generated public keys to to the 'reverse' - be able to wipe =
a part of your off-site backup store by cutting up the secret. So I =
think there is a general case - and I've got a gut feeling that when =
propably analysed some of the usual assumptions around KDFs do not quite =
hold (as in effect one can often cause a lot of known plaintext to be =
passed in).<div><br></div><div>Dw.</div><div><br><div><div>Op 3 sep. =
2013, om 17:02 heeft Phillip Hallam-Baker <<a =
href=3D"mailto:hallam@gmail.com">hallam@gmail.com</a>> het volgende =
geschreven:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div dir=3D"ltr">Want to collaborate on an Internet =
Draft?<div><br></div><div>This is obviously useful but it can only be =
made useful if everyone does it in the same way.</div></div><div =
class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">
On Tue, Sep 3, 2013 at 10:14 AM, Peter Gutmann <span dir=3D"ltr"><<a =
href=3D"mailto:pgut001@cs.auckland.ac.nz" =
target=3D"_blank">pgut001@cs.auckland.ac.nz</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">Phillip Hallam-Baker <<a =
href=3D"mailto:hallam@gmail.com">hallam@gmail.com</a>> writes:<br>
<br>
>To backup the key we tell the device to print out the escrow data on =
paper.<br>
>Let us imagine that there there is a single sheet of paper which is =
cut into<br>
>six parts as follows:<br>
<br>
</div>You read my mind :-). I suggested more or less this to a =
commercial provider<br>
a month or so back when they were trying to solve the same problem.<br>
Specifically it was "if you lose your key/password/whatever, you can't =
call<br>
the helpdesk to get your data back, it's really gone", which was causing =
them<br>
significant headaches because users just weren't expecting this sort of =
thing.<br>
My suggestion was to generate a web page in printable format with the =
key<br>
shares in standard software-serial-number form (XXXXX-XXXXX-XXXXX etc) =
and<br>
tell people to keep one part at home and one at work, or something =
similar,<br>
and to treat it like they'd treat their passport or insurance =
documentation.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Peter.<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- =
<br>Website: <a =
href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
</div>
_______________________________________________<br>The cryptography =
mailing list<br><a =
href=3D"mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br=
>http://www.metzdowd.com/mailman/listinfo/cryptography</blockquote></div><=
br></div></body></html>=
--Apple-Mail=_1C146403-0D82-4E6E-8072-16D799270C10--
--===============2062196047009580190==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============2062196047009580190==--
