[146820] in cryptography@c2.net mail archive
Re: [Cryptography] Trapdoor symmetric key
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Sun Sep 8 13:20:54 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <CAN7nBXfmXy_N5BSJpbS9C1+78MKuWd+q8NMpmkavJU8hazRHZQ@mail.gmail.com>
Date: Sun, 8 Sep 2013 13:18:53 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: =?ISO-8859-1?Q?Far=E9?= <fahree@gmail.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============3694164665482001906==
Content-Type: multipart/alternative; boundary=001a11c37a084b7b0304e5e277c4
--001a11c37a084b7b0304e5e277c4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sun, Sep 8, 2013 at 12:19 PM, Far=E9 <fahree@gmail.com> wrote:
> On Sun, Sep 8, 2013 at 9:42 AM, Phillip Hallam-Baker <hallam@gmail.com>
> wrote:
> > Two caveats on the commentary about a symmetric key algorithm with a
> > trapdoor being a public key algorithm.
> >
> > 1) The trapdoor need not be a good public key algorithm, it can be
> flawed in
> > ways that would make it unsuited for use as a public key algorithm. For
> > instance being able to compute the private key from the public or deduc=
e
> the
> > private key from multiple messages.
> >
> Then it's not a symmetric key algorithm with a trapdoor, it's just a
> broken algorithm.
But the compromise may only be visible if you have access to some
cryptographic technique which we don't currently have.
The point I am making is that a backdoor in a symmetric function need not
be a secure public key system, it could be a breakable one. And that is a
much wider class of function than public key cryptosystems. There are many
approaches that were tried before RSA and ECC were settled on.
> > 2) The trapdoor need not be a perfect decrypt. A trapdoor that reduced
> the
> > search space for brute force search from 128 bits to 64 or only worked =
on
> > some messages would be enough leverage for intercept purposes but make =
it
> > useless as a public key system.
> >
> I suppose the idea is that by using the same trapdoor algorithm or
> algorithm family
> and doubling the key size (e.g. 3DES style), you get a 256-bit
> symmetric key system
> that can be broken in 2^128 attempts by someone with the system's private
> key
> but 2^256 by someone without. If in your message you then communicate 128
> bits
> of information about your symmetric key, the guy with the private key
> can easily crack your symmetric key, whereas others just can't.
> Therefore that's a great public key cryptography system.
>
2^128 is still beyond the reach of brute force.
2^64 and a 128 bit key which is the one we usually use on the other hand...
Perhaps we should do a test, move to 256 bits on a specific date across the
net and see if the power consumption rises near the NSA data centers.
--=20
Website: http://hallambaker.com/
--001a11c37a084b7b0304e5e277c4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sun, Sep 8, 2013 at 12:19 PM, Far=E9 <span dir=3D"ltr"><<a hr=
ef=3D"mailto:fahree@gmail.com" target=3D"_blank">fahree@gmail.com</a>></=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Sun, Sep 8, 2013 at 9:4=
2 AM, Phillip Hallam-Baker <<a href=3D"mailto:hallam@gmail.com">hallam@g=
mail.com</a>> wrote:<br>
> Two caveats on the commentary about a symmetric key algorithm with a<b=
r>
> trapdoor being a public key algorithm.<br>
><br>
> 1) The trapdoor need not be a good public key algorithm, it can be fla=
wed in<br>
> ways that would make it unsuited for use as a public key algorithm. Fo=
r<br>
> instance being able to compute the private key from the public or dedu=
ce the<br>
> private key from multiple messages.<br>
><br>
</div>Then it's not a symmetric key algorithm with a trapdoor, it's=
just a<br>
broken algorithm.</blockquote><div><br></div><div>But the compromise may on=
ly be visible if you have access to some cryptographic technique which we d=
on't currently have.=A0</div><div><br></div><div>The point I am making =
is that a backdoor in a symmetric function need not be a secure public key =
system, it could be a breakable one. And that is a much wider class of func=
tion than public key cryptosystems. There are many approaches that were tri=
ed before RSA and ECC were settled on.</div>
<div><br></div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div class=3D"im">
> 2) The trapdoor need not be a perfect decrypt. A trapdoor that reduced=
the<br>
> search space for brute force search from 128 bits to 64 or only worked=
on<br>
> some messages would be enough leverage for intercept purposes but make=
it<br>
> useless as a public key system.<br>
><br>
</div>I suppose the idea is that by using the same trapdoor algorithm or<br=
>
algorithm family<br>
and doubling the key size (e.g. 3DES style), you get a 256-bit<br>
symmetric key system<br>
that can be broken in 2^128 attempts by someone with the system's priva=
te key<br>
but 2^256 by someone without. If in your message you then communicate 128 b=
its<br>
of information about your symmetric key, the guy with the private key<br>
can easily crack your symmetric key, whereas others just can't.<br>
Therefore that's a great public key cryptography system.<br></blockquot=
e><div><br></div><div>2^128 is still beyond the reach of brute force.=A0</d=
iv><div><br></div><div>2^64 and a 128 bit key which is the one we usually u=
se on the other hand... =A0</div>
</div><br clear=3D"all"><div><br></div><div>Perhaps we should do a test, mo=
ve to 256 bits on a specific date across the net and see if the power consu=
mption rises near the NSA data centers.</div><div><br></div>-- <br>Website:=
<a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>
--001a11c37a084b7b0304e5e277c4--
--===============3694164665482001906==
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
--===============3694164665482001906==--
