[prev in list] [next in list] [prev in thread] [next in thread]
List: cfrg
Subject: Re: [Cfrg] Analysis of ipcrypt?
From: Tim Hollebeek <tim.hollebeek () digicert ! com>
Date: 2018-02-27 19:37:42
Message-ID: MWHPR14MB1376E27D3865C244E5C9F15783C00 () MWHPR14MB1376 ! namprd14 ! prod ! outlook ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Why use a low security toy cipher, when there are high security FPE algorithms \
available, which provide full strength and are reasonably efficient? A number of \
them are being standardized as part of the work by ANSI ASC X9F1.
In particular, output sizes that are 2^n lead to very efficient implementations of \
most FPE algorithms. They're basically just Feistel structures over 32-bit blocks, \
using AES or something similar as the round function.
-Tim
From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Jean-Philippe Aumasson
Sent: Wednesday, February 21, 2018 11:55 PM
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] Analysis of ipcrypt?
Hi!
I designed ipcrypt as a low-security toy cipher to encrypt IPv4 addresses for some \
log analysis application. It may be good enough for this purpose, however it has very \
low security:
* because of 32-bit blocks, a chosen-plaintext codebook attack will work in time 2^32 \
(or much less for specific IP ranges)
* known-plaintext codebook attacks will work similarly but in O(n log n), or 2^37 \
(coupon collector problem)
* there is a generic ~2^16 distinguisher that works by looking for a collision in a \
sequence of blocks
* worse, Jason just found a high-probability differential that seems detectable with \
fewer than 2^24 chosen-plaintext pair, and which may speed up key recovery
On Thu, 22 Feb 2018 at 03:03, Paul Hoffman <paul.hoffman@icann.org \
<mailto:paul.hoffman@icann.org> > wrote:
Greetings. ipcrypt is a format-preserving cipher for IPv4 addresses. It has a 32-bit \
blocksize for input and output, and 128-bit blocksize for the key. It was developed \
by Jean-Philippe Aumasson and is described at: https://github.com/veorq/ipcrypt
There doesn't appear to be any formal paper describing the algorithm, but the Python \
and Go code is trivial to follow.
This algorithm is now being considered by a few different projects that want to \
obfuscate IPv4 addresses. Has anyone analyzed the algorithm? I could not find \
analyses, but certainly could have missed them.
For a project I'm on, ipcrypt is attractive if an attacker cannot derive the 128-bit \
random key without a lot (maybe 2^80ish) effort. For cases in common use, assume that \
the attacker has 2^24 known plaintext/ciphertext pairs under a single 128-bit random \
key. For additional ciphertexts, how much effort must the attacker expend to get the \
key in order to decrypt additional unknown ciphertexts?
(Note that there are other options for this use case, which have different positive \
and negative features. What we'd like to know is how good is ipcrypt if we chose it.)
--Paul Hoffman_______________________________________________
Cfrg mailing list
Cfrg@irtf.org <mailto:Cfrg@irtf.org>
https://www.irtf.org/mailman/listinfo/cfrg
[Attachment #5 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type \
content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 \
(filtered medium)"><style><!-- /* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div \
class=WordSection1><p class=MsoNormal>Why use a low security toy cipher, when there \
are high security FPE algorithms available, which provide full strength and are \
reasonably efficient? A number of them are being standardized as part of the work \
by ANSI ASC X9F1.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p \
class=MsoNormal>In particular, output sizes that are 2^n lead to very efficient \
implementations of most FPE algorithms. They're basically just Feistel structures \
over 32-bit blocks, using AES or something similar as the round \
function.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p \
class=MsoNormal>-Tim<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div \
style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div \
style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p \
class=MsoNormal><b>From:</b> Cfrg [mailto:cfrg-bounces@irtf.org] <b>On Behalf Of \
</b>Jean-Philippe Aumasson<br><b>Sent:</b> Wednesday, February 21, 2018 11:55 \
PM<br><b>To:</b> Paul Hoffman <paul.hoffman@icann.org><br><b>Cc:</b> \
cfrg@irtf.org<br><b>Subject:</b> Re: [Cfrg] Analysis of \
ipcrypt?<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p \
class=MsoNormal style='margin-bottom:12.0pt'>Hi!<o:p></o:p></p><div><p \
class=MsoNormal>I designed ipcrypt as a low-security toy cipher to encrypt IPv4 \
addresses for some log analysis application. It may be good enough for this purpose, \
however it has very low security:<o:p></o:p></p></div></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>* because of \
32-bit blocks, a chosen-plaintext codebook attack will work in time 2^32 (or much \
less for specific IP ranges)<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>* known-plaintext \
codebook attacks will work similarly but in O(n log n), or 2^37 (coupon collector \
problem)<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>* there is a \
generic ~2^16 distinguisher that works by looking for a collision in a sequence of \
blocks<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p \
class=MsoNormal>* worse, Jason just found a high-probability differential that seems \
detectable with fewer than 2^24 chosen-plaintext pair, and which may speed up key \
recovery<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><div><div><p class=MsoNormal>On Thu, \
22 Feb 2018 at 03:03, Paul Hoffman <<a \
href="mailto:paul.hoffman@icann.org">paul.hoffman@icann.org</a>> \
wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC \
1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p \
class=MsoNormal>Greetings. ipcrypt is a format-preserving cipher for IPv4 addresses. \
It has a 32-bit blocksize for input and output, and 128-bit blocksize for the key. It \
was developed by Jean-Philippe Aumasson and is described at:<br> <a \
href="https://github.com/veorq/ipcrypt" \
target="_blank">https://github.com/veorq/ipcrypt</a><br>There doesn't appear to be \
any formal paper describing the algorithm, but the Python and Go code is trivial to \
follow.<br><br>This algorithm is now being considered by a few different projects \
that want to obfuscate IPv4 addresses. Has anyone analyzed the algorithm? I could not \
find analyses, but certainly could have missed them.<br><br>For a project I'm on, \
ipcrypt is attractive if an attacker cannot derive the 128-bit random key without a \
lot (maybe 2^80ish) effort. For cases in common use, assume that the attacker has \
2^24 known plaintext/ciphertext pairs under a single 128-bit random key. For \
additional ciphertexts, how much effort must the attacker expend to get the key in \
order to decrypt additional unknown ciphertexts?<br><br>(Note that there are other \
options for this use case, which have different positive and negative features. What \
we'd like to know is how good is ipcrypt if we chose it.)<br><br>--Paul \
Hoffman_______________________________________________<br>Cfrg mailing list<br><a \
href="mailto:Cfrg@irtf.org" target="_blank">Cfrg@irtf.org</a><br><a \
href="https://www.irtf.org/mailman/listinfo/cfrg" \
target="_blank">https://www.irtf.org/mailman/listinfo/cfrg</a><o:p></o:p></p></blockquote></div></div></div></div></body></html>
["smime.p7s" (application/pkcs7-signature)]
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
--===============0704766567635877001==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic