From paul at ciphergoth.org Tue May 3 12:27:12 2011
From: paul at ciphergoth.org (Paul Crowley)
Date: Tue, 03 May 2011 17:27:12 +0100
Subject: [cryptography] Point compression prior art?
Message-ID: <4DC02CE0.6070900@ciphergoth.org>
Is there a way of doing elliptic curve point compression for curves in
GF(p) which does not fall foul of patents? Of course point compression
in GF(p) is blindingly obvious, but as we know that doesn't always help.
This message, by Bodo Moeller in 2005, suggests there is:
> The idea to use one bit to
> compress a specific y-coordinate is newer -- it appears in Harper,
> Menezes, Vanstone, "Public-Key Cryptosystems with Very Small Key
> Lengths", EUROCRYPT '92 (LNCS 658). The technique for the GF(p) case
> is described here. The printed proceedings for this conference (held
> in May 1992) were published by Springer-Verlag in February 1993, so
> this case is quite clear.
>
> For the GF(2^m) case, however, I am not aware of prior art. Hence,
> point compression for binary curves is not available in standard
> compilations of OpenSSL.
http://www.mail-archive.com/cryptography at metzdowd.com/msg04970.html
The paper is here:
http://oberon.postech.ac.kr/bibliography/springer-verlag/HTML/PDF/E92/163.PDF
However, contrary to the above, AFAICT the paper describes point
compression for a GF(2^n) elliptic curve. Page 164 of the paper (the
first page is numbered 163) says "We will be concerned here with
elliptic curves over fields of characteristic 2", and gives the elliptic
curve equation in the form "y^2 + xy = x^3 + ax^2 + b" (1). It is this
equation which is then transformed on page 1 into equation (3) which is
designed for efficient point compression.
And indeed the OpenSSL sources now discuss that patent in a comment
above the GF(2^n) point compression implementation in ec2_smpl.c.
There's no similar comment above the GF(p) implementation in ecp_smpl.c.
Can anyone shed any light? Thanks!
--
__
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/
From zooko at zooko.com Tue May 3 14:59:35 2011
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Tue, 3 May 2011 12:59:35 -0600
Subject: [cryptography] Point compression prior art?
In-Reply-To: <4DC02CE0.6070900@ciphergoth.org>
References: <4DC02CE0.6070900@ciphergoth.org>
Message-ID:
Have you seen DJB's "Irrelevant patents on elliptic-curve cryptography"
http://cr.yp.to/ecdh/patents.html
The section on "Point Compression" says:
"""
Miller in 1986, in the paper that introduced elliptic-curve
cryptography, suggested compressing a public key (x,y) to simply x:
``Finally, it should be remarked, that even though we have phrased
everything in terms of points on an elliptic curve, that, for the key
exchange protocol (and other uses as one-way functions), that only the
x-coordinate needs to be transmitted. The formulas for multiples of a
point cited in the first section make it clear that the x-coordinate
of a multiple depends only on the x-coordinate of the original
point.'' This is exactly the compression method that I use.
Popular rumor states that point compression is covered by a subsequent
Vanstone-Mullin-Agnew patent: US patent 6141420, filed 1994.07.29,
granted 2000.10.31. What the patent actually claims are (1--28)
encryption using an elliptic curve over a finite field of
characteristic 2 with elements represented on a normal basis; (29, 36)
communicating (x,y) on a curve by communicating x and having the
receiver somehow compute y; (30--35, 37--41) communicating x and
``identifying information'' of y, such as one bit; and (42--52) some
secret-key encryption mechanisms.
My Curve25519 software never computes y, so it is not covered by the
patent. It should, in any case, be obvious to the reader that a patent
cannot cover compression mechanisms published seven years before the
patent was filed.
"""
DJB also has this page, which goes into more detail about 6141420:
http://cr.yp.to/patents/us/6141420.html
Contrary to the "filed 1994.07.29" above, the patent was actually
filed January 29, 1997:
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=6,141,420.PN.&OS=PN/6,141,420&RS=PN/6,141,420
Which means it expires January 29, 2017.
Regards,
Zooko
From paul at ciphergoth.org Wed May 4 04:33:05 2011
From: paul at ciphergoth.org (Paul Crowley)
Date: Wed, 04 May 2011 09:33:05 +0100
Subject: [cryptography] Point compression prior art?
In-Reply-To:
References: <4DC02CE0.6070900@ciphergoth.org>
Message-ID: <4DC10F41.2090807@ciphergoth.org>
On 03/05/11 19:59, Zooko O'Whielacronx wrote:
> Have you seen DJB's "Irrelevant patents on elliptic-curve cryptography"
Yep. DJB uses "discard y" point compression in Curve25519, which works
with ECDH for the reasons he gives but does not work in many other
applications, such as ECDSA.
> DJB also has this page, which goes into more detail about 6141420:
>
> http://cr.yp.to/patents/us/6141420.html
This discusses "discard y" and the Eurocrypt '92 paper describing point
compression in GF(2^m) I discussed in my earlier email. The implication
is that at least some of claims 30 to 41 are invalidated by that paper,
but I'm not sure I can infer from this a specific technique for GF(p)
point compression that the patent cannot cover.
Thanks!
--
__
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/
From paul at ciphergoth.org Tue May 10 07:45:25 2011
From: paul at ciphergoth.org (Paul Crowley)
Date: Tue, 10 May 2011 12:45:25 +0100
Subject: [cryptography] Message encryption standards?
In-Reply-To: <4DC10F41.2090807@ciphergoth.org>
References: <4DC02CE0.6070900@ciphergoth.org>
<4DC10F41.2090807@ciphergoth.org>
Message-ID: <4DC92555.40406@ciphergoth.org>
Most standards that include encryption are to do with transport-level
encryption (SSL, SSH, IPSec/IKE, WPA etc). However, OpenPGP, XML
encryption, and CMS all offer a mode of operation more like this:
- Bob sends Alice a packet that includes a public key for encryption
- Offline, Alice can take this packet and a message and generate an
encrypted message
- The message reaches Bob by whatever means
- Bob decrypts it
Are there other standards of this shape that I've left out here? Thanks!
--
__
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/
From lodewijkadlp at gmail.com Tue May 10 08:06:10 2011
From: lodewijkadlp at gmail.com (=?UTF-8?Q?lodewijk_andr=C3=A9_de_la_porte?=)
Date: Tue, 10 May 2011 14:06:10 +0200
Subject: [cryptography] Message encryption standards?
In-Reply-To: <4DC92555.40406@ciphergoth.org>
References: <4DC02CE0.6070900@ciphergoth.org>
<4DC10F41.2090807@ciphergoth.org> <4DC92555.40406@ciphergoth.org>
Message-ID:
Rot13 (or any other number) and many other pre-digital era message
encription methods. What is for you the advantage of this kind of
encription?
2011/5/10 Paul Crowley :
> Most standards that include encryption are to do with transport-level
> encryption (SSL, SSH, IPSec/IKE, WPA etc). However, OpenPGP, XML encryption,
> and CMS all offer a mode of operation more like this:
>
> - Bob sends Alice a packet that includes a public key for encryption
> - Offline, Alice can take this packet and a message and generate an
> encrypted message
> - The message reaches Bob by whatever means
> - Bob decrypts it
>
> Are there other standards of this shape that I've left out here? ?Thanks!
> --
> ?__
> \/ o\ Paul Crowley, paul at ciphergoth.org
> /\__/ http://www.ciphergoth.org/
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
From johnl at iecc.com Tue May 10 08:15:10 2011
From: johnl at iecc.com (John R. Levine)
Date: 10 May 2011 08:15:10 -0400
Subject: [cryptography] Message encryption standards?
In-Reply-To: <4DC92555.40406@ciphergoth.org>
References: <4DC10F41.2090807@ciphergoth.org>
<4DC02CE0.6070900@ciphergoth.org> <4DC92555.40406@ciphergoth.org>
Message-ID:
> Are there other standards of this shape that I've left out here? Thanks!
Yes.
Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2304 bytes
Desc: S/MIME Cryptographic Signature
URL:
From david-sarah at jacaranda.org Mon May 16 18:55:14 2011
From: david-sarah at jacaranda.org (David-Sarah Hopwood)
Date: Mon, 16 May 2011 23:55:14 +0100
Subject: [cryptography] Point compression prior art?
In-Reply-To:
References: <4DC02CE0.6070900@ciphergoth.org>
Message-ID: <4DD1AB52.4070008@jacaranda.org>
On 03/05/11 19:59, Zooko O'Whielacronx wrote:
> Have you seen DJB's "Irrelevant patents on elliptic-curve cryptography"
>
> http://cr.yp.to/ecdh/patents.html
>
[...]
> My Curve25519 software never computes y, so it is not covered by the
> patent. It should, in any case, be obvious to the reader that a patent
> cannot cover compression mechanisms published seven years before the
> patent was filed.
> """
>
> DJB also has this page, which goes into more detail about 6141420:
>
> http://cr.yp.to/patents/us/6141420.html
>
> Contrary to the "filed 1994.07.29" above, the patent was actually
> filed January 29, 1997:
>
> http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=6,141,420.PN.&OS=PN/6,141,420&RS=PN/6,141,420
True, but it has the "related U.S. patent document" with application number
282263, which was filed in July 1994. That date is what is most relevant
for the "published seven years before the patent was filed" comment.
> Which means it expires January 29, 2017.
If a granted patent has prior art for a given claim, then it is invalid
for that claim, and cannot be infringed, so its expiration date is not
important. (The holder can of course claim that it is infringed, but they
could do that for any random patent they hold, regardless of relevance.)
--
David-Sarah Hopwood ? http://davidsarah.livejournal.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 294 bytes
Desc: OpenPGP digital signature
URL:
From smb at cs.columbia.edu Mon May 16 20:40:04 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Mon, 16 May 2011 20:40:04 -0400
Subject: [cryptography] M-94 wheel cipher on EBay
Message-ID: <4DAD95FD-1D27-4922-8E05-B1DB98C10FB1@cs.columbia.edu>
http://cgi.ebay.com/Model-M-94-Cipher-Device-U-S-Army-Signal-Corps-WWII-/220784760519
I'd love it, but the bidding is already over US$1000 so I'll pass...
Sent from my iPad
From thierry.moreau at connotech.com Mon May 16 23:37:56 2011
From: thierry.moreau at connotech.com (Thierry Moreau)
Date: Mon, 16 May 2011 23:37:56 -0400
Subject: [cryptography] Point compression prior art?
In-Reply-To:
References: <4DC02CE0.6070900@ciphergoth.org>
Message-ID: <4DD1ED94.5060401@connotech.com>
Zooko O'Whielacronx wrote:
> Have you seen DJB's "Irrelevant patents on elliptic-curve cryptography"
>
> http://cr.yp.to/ecdh/patents.html
>
> The section on "Point Compression" says:
>
> """
> Miller in 1986, in the paper that introduced elliptic-curve
> cryptography, suggested compressing a public key (x,y) to simply x:
> ``Finally, it should be remarked, that even though we have phrased
> everything in terms of points on an elliptic curve, that, for the key
> exchange protocol (and other uses as one-way functions), that only the
> x-coordinate needs to be transmitted. The formulas for multiples of a
> point cited in the first section make it clear that the x-coordinate
> of a multiple depends only on the x-coordinate of the original
> point.'' This is exactly the compression method that I use.
>
> Popular rumor states that point compression is covered by a subsequent
> Vanstone-Mullin-Agnew patent: US patent 6141420, filed 1994.07.29,
> granted 2000.10.31. What the patent actually claims are (1--28)
> encryption using an elliptic curve over a finite field of
> characteristic 2 with elements represented on a normal basis; (29, 36)
> communicating (x,y) on a curve by communicating x and having the
> receiver somehow compute y; (30--35, 37--41) communicating x and
> ``identifying information'' of y, such as one bit; and (42--52) some
> secret-key encryption mechanisms.
>
> My Curve25519 software never computes y, so it is not covered by the
> patent. It should, in any case, be obvious to the reader that a patent
> cannot cover compression mechanisms published seven years before the
> patent was filed.
> """
>
> DJB also has this page, which goes into more detail about 6141420:
>
> http://cr.yp.to/patents/us/6141420.html
>
> Contrary to the "filed 1994.07.29" above, the patent was actually
> filed January 29, 1997:
>
> http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=6,141,420.PN.&OS=PN/6,141,420&RS=PN/6,141,420
>
> Which means it expires January 29, 2017.
>
The 1994.07.29 filing was followed by the PCT/CA95/00452 filed on
1995.07.31 which starts the 20 years patent term for the US patent
6141420. This is what I infer from looking at the first page of the
patent image.
> Regards,
>
same
--
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1
Tel. +1-514-385-5691
From jamesd at echeque.com Tue May 17 21:52:19 2011
From: jamesd at echeque.com (James A. Donald)
Date: Wed, 18 May 2011 11:52:19 +1000
Subject: [cryptography] Point compression prior art?
In-Reply-To: <4DD1AB52.4070008@jacaranda.org>
References: <4DC02CE0.6070900@ciphergoth.org>
<4DD1AB52.4070008@jacaranda.org>
Message-ID: <4DD32653.6010401@echeque.com>
http://cr.yp.to/patents/us/6141420.html
Gives us the algorithm published in 1992
For elliptic curves expressed as
y^2+ y.x = x^3 + a.x^2 + b
For a given value of x, there are two possible values of y/x, differing
by 1.
Thus, to compress the point, represent it by the full value of x, and
the least significant bit of y/x
Analogously for elliptic curves expressed as y^2 = x^3 + a.x^2 + b.
From jamesd at echeque.com Tue May 17 21:17:23 2011
From: jamesd at echeque.com (James A. Donald)
Date: Wed, 18 May 2011 11:17:23 +1000
Subject: [cryptography] Point compression prior art?
In-Reply-To: <4DD1AB52.4070008@jacaranda.org>
References: <4DC02CE0.6070900@ciphergoth.org>
<4DD1AB52.4070008@jacaranda.org>
Message-ID: <4DD31E23.6050506@echeque.com>
On 2011-05-17 8:55 AM, David-Sarah Hopwood wrote:
> On 03/05/11 19:59, Zooko O'Whielacronx wrote:
>> Have you seen DJB's "Irrelevant patents on elliptic-curve cryptography"
>>
>> http://cr.yp.to/ecdh/patents.html
>>
> [...]
>> My Curve25519 software never computes y, so it is not covered by the
>> patent. It should, in any case, be obvious to the reader that a patent
>> cannot cover compression mechanisms published seven years before the
>> patent was filed.
>> """
>>
>> DJB also has this page, which goes into more detail about 6141420:
>>
>> http://cr.yp.to/patents/us/6141420.html
>>
>> Contrary to the "filed 1994.07.29" above, the patent was actually
>> filed January 29, 1997:
>>
>> http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=6,141,420.PN.&OS=PN/6,141,420&RS=PN/6,141,420
>
> True, but it has the "related U.S. patent document" with application number
> 282263, which was filed in July 1994. That date is what is most relevant
> for the "published seven years before the patent was filed" comment.
>
>> Which means it expires January 29, 2017.
>
> If a granted patent has prior art for a given claim, then it is invalid
> for that claim, and cannot be infringed, so its expiration date is not
> important. (The holder can of course claim that it is infringed, but they
> could do that for any random patent they hold, regardless of relevance.)
The most useful fact in the above link is that the best method for point
compression of elliptic curves, in all elliptic curves and any elliptic
curve, was published in 1992, 19 years ago. (x plus one bit that
discriminates between the two y values)
Since then, people have been publishing uselessly weird and complicated
ways of compressing points on an elliptic curve, and then claiming that
since they have a patent for some obscure, complicated, and useless ways
of compressing a point in certain obscure and arcane special cases,
anyone who compresses points has to pay them money.
Which is typical of the vast majority of patents.
From travis+ml-rbcryptography at subspacefield.org Fri May 20 17:30:21 2011
From: travis+ml-rbcryptography at subspacefield.org (travis+ml-rbcryptography at subspacefield.org)
Date: Fri, 20 May 2011 14:30:21 -0700
Subject: [cryptography] rolling hashes, EDC/ECC vs MAC/MIC, etc.
Message-ID: <20110520213021.GA26325@subspacefield.org>
Hmm, after sending this to some of you I remembered this list :-)
====
Just a quick thought, I noticed the other day that rsync uses a
"rolling MD4 hash" or something like that to detect changes in a
window of data.
I wonder if A/V shouldn't use something similar?
I assume MD4 is an outdated choice - perhaps some cryppie needs to
design a hash function that is specifically designed for a FIFO kind
of window? Maybe there is and I'm just out of the loop.
Potentially another application is for "metadata silvering" on file
systems like ZFS, where we want to keep an updated checksum for a
file, to detect corruption, but still want to have, say, efficient
writing to the file - can you support appending? How about random access?
Also, FEC defends against an unintelligent adversary; I wonder if we
couldn't defend against stronger ones (MAC/MIC) efficiently and
neutralize the unintelligent one (nature and errors) for free? It
seems a shame to tack two sets of metadata onto our data.
==== shameless plug follows ====
I run the Bay Area Security Enthusiasts group & mlist:
http://base.bitrot.info/
Anyone can join the mlist, and please come out if you're in SF
sometime.
I have a few security presentations, some on crypto, and one free
online book:
http://www.subspacefield.org/security/
That is all.
Travis
--
http://www.subspacefield.org/~travis/
I don't believe in luck. I believe in the law of large numbers.
If you are a spammer, please email john at subspacefield.org to get blacklisted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL:
From zooko at zooko.com Fri May 20 18:11:42 2011
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Fri, 20 May 2011 16:11:42 -0600
Subject: [cryptography] rolling hashes, EDC/ECC vs MAC/MIC, etc.
In-Reply-To: <20110520213021.GA26325@subspacefield.org>
References: <20110520213021.GA26325@subspacefield.org>
Message-ID:
On Fri, May 20, 2011 at 3:30 PM,
wrote:
>
> I wonder if A/V shouldn't use something similar?
What's A/V?
> I assume MD4 is an outdated choice - perhaps some cryppie needs to
> design a hash function that is specifically designed for a FIFO kind
> of window? ?Maybe there is and I'm just out of the loop.
>
> Potentially another application is for "metadata silvering" on file
> systems like ZFS, where we want to keep an updated checksum for a
> file, to detect corruption, but still want to have, say, efficient
> writing to the file - can you support appending? ?How about random access?
>
> Also, FEC defends against an unintelligent adversary; I wonder if we
> couldn't defend against stronger ones (MAC/MIC) efficiently and
> neutralize the unintelligent one (nature and errors) for free? ?It
> seems a shame to tack two sets of metadata onto our data.
All of the above seems well suited to maintaining a Merkle Tree over
the file data with a secure hash.
Regards,
Zooko
From zooko at zooko.com Fri May 20 18:14:18 2011
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Fri, 20 May 2011 16:14:18 -0600
Subject: [cryptography] Point compression prior art?
In-Reply-To: <4DC02CE0.6070900@ciphergoth.org>
References: <4DC02CE0.6070900@ciphergoth.org>
Message-ID:
Dear Paul Crowley:
How about the "Compact Representation", section 4.2, of RFC 6090:
http://www.rfc-editor.org/rfc/rfc6090.txt
Is that the same "point compression" that you were looking for?
Regards,
Zooko
From paul at ciphergoth.org Fri May 20 18:40:25 2011
From: paul at ciphergoth.org (Paul Crowley)
Date: Fri, 20 May 2011 23:40:25 +0100
Subject: [cryptography] Point compression prior art?
In-Reply-To:
References: <4DC02CE0.6070900@ciphergoth.org>
Message-ID: <4DD6EDD9.1070606@ciphergoth.org>
On 20/05/11 23:14, Zooko O'Whielacronx wrote:
> How about the "Compact Representation", section 4.2, of RFC 6090:
>
> http://www.rfc-editor.org/rfc/rfc6090.txt
>
> Is that the same "point compression" that you were looking for?
Sadly not; this is the "discard y, transmit only x" scheme described in
the original CRYPTO 85 paper introducing elliptic curve cryptography.
This works for ECDH, but for protocols such as ECDSA it's harder to see
how to make do with only one of the coordinates. Thanks for the
reference though!
--
__
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/
From nico at cryptonector.com Fri May 20 18:49:51 2011
From: nico at cryptonector.com (Nico Williams)
Date: Fri, 20 May 2011 17:49:51 -0500
Subject: [cryptography] Point compression prior art?
In-Reply-To: <4DD6EDD9.1070606@ciphergoth.org>
References: <4DC02CE0.6070900@ciphergoth.org>
<4DD6EDD9.1070606@ciphergoth.org>
Message-ID:
On Fri, May 20, 2011 at 5:40 PM, Paul Crowley wrote:
> On 20/05/11 23:14, Zooko O'Whielacronx wrote:
>> How about the "Compact Representation", section 4.2, of RFC 6090:
>>
>> http://www.rfc-editor.org/rfc/rfc6090.txt
>>
>> Is that the same "point compression" that you were looking for?
>
> Sadly not; this is the "discard y, transmit only x" scheme described in the
> original CRYPTO 85 paper introducing elliptic curve cryptography. This
> ?works for ECDH, but for protocols such as ECDSA it's harder to see how to
> make do with only one of the coordinates. ?Thanks for the reference though!
What about using Shcnorr's signature scheme with ECDH? Here's DJB
talking about it in the context of his Curve25519, which uses the
discard-y point compression technique:
http://www.derkeiler.com/Newsgroups/sci.crypt/2006-08/msg01621.html
This would seem adequate to me, and should result in small signatures.
Nico
--
From nico at cryptonector.com Fri May 20 18:18:16 2011
From: nico at cryptonector.com (Nico Williams)
Date: Fri, 20 May 2011 17:18:16 -0500
Subject: [cryptography] rolling hashes, EDC/ECC vs MAC/MIC, etc.
In-Reply-To: <20110520213021.GA26325@subspacefield.org>
References: <20110520213021.GA26325@subspacefield.org>
Message-ID:
On Fri, May 20, 2011 at 4:30 PM,
wrote:
> Just a quick thought, I noticed the other day that rsync uses a
> "rolling MD4 hash" or something like that to detect changes in a
> window of data.
A quick look around should tell you that it uses a "rolling checksum"
and a hash function. MD4 is one such hash function. The rolling
checksum is a CRC, which is to say, not a hash function.
> I wonder if A/V shouldn't use something similar?
The rsync rolling CRC is useful for detecting insertions an deletions
-- i.e., remote diff.
> I assume MD4 is an outdated choice - perhaps some cryppie needs to
> design a hash function that is specifically designed for a FIFO kind
> of window? ?Maybe there is and I'm just out of the loop.
MD4 isn't the function with the "rolling" property. A function with
that property isn't a hash function. It might be a strong CRC though,
which might be good enough for error detection, or not.
> Potentially another application is for "metadata silvering" on file
> systems like ZFS, where we want to keep an updated checksum for a
> file, to detect corruption, but still want to have, say, efficient
> writing to the file - can you support appending? ?How about random access?
That would be nice, but I don't think a CRC offers strong enough
protection. What might be nice is if the filesystem could export an
API for getting rolling CRC data -- it might speed up rsync-like
applications. I filed an RFE for that in ZFS back at Sun (Oracle)
years ago, and I posted about it back in 2005 in this thread:
https://www.opensolaris.org/jive/thread.jspa?threadID=12917
Nico
--
From paul at ciphergoth.org Fri May 20 19:12:47 2011
From: paul at ciphergoth.org (Paul Crowley)
Date: Sat, 21 May 2011 00:12:47 +0100
Subject: [cryptography] Point compression prior art?
In-Reply-To:
References: <4DC02CE0.6070900@ciphergoth.org> <4DD6EDD9.1070606@ciphergoth.org>
Message-ID: <4DD6F56F.6060907@ciphergoth.org>
On 20/05/11 23:49, Nico Williams wrote:
> What about using Shcnorr's signature scheme with ECDH? Here's DJB
> talking about it in the context of his Curve25519, which uses the
> discard-y point compression technique:
>
> http://www.derkeiler.com/Newsgroups/sci.crypt/2006-08/msg01621.html
>
> This would seem adequate to me, and should result in small signatures.
I don't see how "discard y" works here. It works for DH because x(?yB) =
?xyB = y(?xB). But for Schnorr the verifier needs sB-rnB and sB-rnB !=
sB-r(-nB). I guess it wouldn't be too expensive to try both - any
opinions on the patent status of that?
--
__
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/
From nico at cryptonector.com Fri May 20 19:36:32 2011
From: nico at cryptonector.com (Nico Williams)
Date: Fri, 20 May 2011 18:36:32 -0500
Subject: [cryptography] Point compression prior art?
In-Reply-To: <4DD6F56F.6060907@ciphergoth.org>
References: <4DC02CE0.6070900@ciphergoth.org>
<4DD6EDD9.1070606@ciphergoth.org>
<4DD6F56F.6060907@ciphergoth.org>
Message-ID:
On Fri, May 20, 2011 at 6:12 PM, Paul Crowley wrote:
> On 20/05/11 23:49, Nico Williams wrote:
>> What about using Shcnorr's signature scheme with ECDH? ?Here's DJB
>> talking about it in the context of his Curve25519, which uses the
>> discard-y point compression technique:
>>
>> http://www.derkeiler.com/Newsgroups/sci.crypt/2006-08/msg01621.html
>>
>> This would seem adequate to me, and should result in small signatures.
>
> I don't see how "discard y" works here. It works for DH because x(?yB) =
> ?xyB = y(?xB). ?But for Schnorr the verifier needs sB-rnB and sB-rnB !=
> sB-r(-nB). ?I guess it wouldn't be too expensive to try both - any opinions
> on the patent status of that?
Ah yes, I see that now. I wouldn't know if there exists any patents
covering that.
Nico
--
From seb at dbzteam.org Fri May 20 20:04:06 2011
From: seb at dbzteam.org (Sebastien Martini)
Date: Sat, 21 May 2011 02:04:06 +0200
Subject: [cryptography] Point compression prior art?
In-Reply-To:
References: <4DC02CE0.6070900@ciphergoth.org>
<4DD6EDD9.1070606@ciphergoth.org>
Message-ID:
Hi,
On Sat, May 21, 2011 at 00:49, Nico Williams wrote:
> On Fri, May 20, 2011 at 5:40 PM, Paul Crowley wrote:
>> On 20/05/11 23:14, Zooko O'Whielacronx wrote:
>>> How about the "Compact Representation", section 4.2, of RFC 6090:
>>>
>>> http://www.rfc-editor.org/rfc/rfc6090.txt
>>>
>>> Is that the same "point compression" that you were looking for?
>>
>> Sadly not; this is the "discard y, transmit only x" scheme described in the
>> original CRYPTO 85 paper introducing elliptic curve cryptography. This
>> ?works for ECDH, but for protocols such as ECDSA it's harder to see how to
>> make do with only one of the coordinates. ?Thanks for the reference though!
>
> What about using Shcnorr's signature scheme with ECDH? ?Here's DJB
> talking about it in the context of his Curve25519, which uses the
> discard-y point compression technique:
>
> http://www.derkeiler.com/Newsgroups/sci.crypt/2006-08/msg01621.html
>
> This would seem adequate to me, and should result in small signatures.
>From a practical point of view there is however something not really
handy with Schnorr's signature scheme, that is you can't call the sign
function with a hash of the message because the ephemeral public key
must be concataned to the message before being hashed.
seb
From travis+ml-rbcryptography at subspacefield.org Sat May 21 03:53:47 2011
From: travis+ml-rbcryptography at subspacefield.org (travis+ml-rbcryptography at subspacefield.org)
Date: Sat, 21 May 2011 00:53:47 -0700
Subject: [cryptography] rolling hashes, EDC/ECC vs MAC/MIC, etc.
In-Reply-To:
References: <20110520213021.GA26325@subspacefield.org>
Message-ID: <20110521075347.GD18510@subspacefield.org>
On Fri, May 20, 2011 at 05:18:16PM -0500, Nico Williams wrote:
> > I wonder if A/V shouldn't use something similar?
>
> The rsync rolling CRC is useful for detecting insertions an deletions
> -- i.e., remote diff.
Right, but right now some anti-virus does hashes over the whole file,
or so I've heard, and so even a single bit flip in a resource (icon)
can defeat some of them.
What'd be nicer is fuzzier matches --- perhaps.
> A function with
> that property isn't a hash function.
How do you figure?
--
http://www.subspacefield.org/~travis/
I don't believe in luck. I believe in the law of large numbers.
If you are a spammer, please email john at subspacefield.org to get blacklisted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL:
From paul at ciphergoth.org Sat May 21 04:47:41 2011
From: paul at ciphergoth.org (Paul Crowley)
Date: Sat, 21 May 2011 09:47:41 +0100
Subject: [cryptography] Point compression prior art?
In-Reply-To:
References: <4DC02CE0.6070900@ciphergoth.org> <4DD6EDD9.1070606@ciphergoth.org>
Message-ID: <4DD77C2D.4050002@ciphergoth.org>
On 21/05/11 01:04, Sebastien Martini wrote:
>> From a practical point of view there is however something not really
> handy with Schnorr's signature scheme, that is you can't call the sign
> function with a hash of the message because the ephemeral public key
> must be concataned to the message before being hashed.
This isn't what you would do in practice; in practice one would hash the
message as normal, then hash that together with the ephemeral value to
generate the challenge value.
--
__
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/
From jamesd at echeque.com Sat May 21 07:17:12 2011
From: jamesd at echeque.com (James A. Donald)
Date: Sat, 21 May 2011 21:17:12 +1000
Subject: [cryptography] Point compression prior art?
In-Reply-To: <4DD6F56F.6060907@ciphergoth.org>
References: <4DC02CE0.6070900@ciphergoth.org> <4DD6EDD9.1070606@ciphergoth.org>
<4DD6F56F.6060907@ciphergoth.org>
Message-ID: <4DD79F38.1010707@echeque.com>
On 2011-05-21 9:12 AM, Paul Crowley wrote:
> On 20/05/11 23:49, Nico Williams wrote:
>> What about using Shcnorr's signature scheme with ECDH? Here's DJB
>> talking about it in the context of his Curve25519, which uses the
>> discard-y point compression technique:
>>
>> http://www.derkeiler.com/Newsgroups/sci.crypt/2006-08/msg01621.html
>>
>> This would seem adequate to me, and should result in small signatures.
>
> I don't see how "discard y" works here. It works for DH because x(?yB) =
> ?xyB = y(?xB). But for Schnorr the verifier needs sB-rnB and sB-rnB !=
> sB-r(-nB). I guess it wouldn't be too expensive to try both - any
> opinions on the patent status of that?
I believe that the wheel is patented, as is the idea of trying to get
around the patent by using something other than a wheel for the sort of
purposes a wheel might be used for. Should someone ever figure how to
make something other than a wheel roll, the idea of rolling non wheels
is also patented.
From lodewijkadlp at gmail.com Sat May 21 07:27:56 2011
From: lodewijkadlp at gmail.com (=?UTF-8?Q?lodewijk_andr=C3=A9_de_la_porte?=)
Date: Sat, 21 May 2011 13:27:56 +0200
Subject: [cryptography] Point compression prior art?
In-Reply-To: <4DD79F38.1010707@echeque.com>
References: <4DC02CE0.6070900@ciphergoth.org>
<4DD6EDD9.1070606@ciphergoth.org>
<4DD6F56F.6060907@ciphergoth.org> <4DD79F38.1010707@echeque.com>
Message-ID:
Usage of the word rolling is also trademarked and limited.
You forgot about wheels that do not roll. Can't use that either.
You may have found some people using wheels for rolling. They should be
frowned upon, given extra-intimate pat-downs, blackmailed, arrested anyway,
made fun of before trial, given a long unfair trail, be non-lethally
tortured because they might know other "rollers" and later executed for
being a danger to the state beyond any help after which his familly will be
billed for all expenses (and exported).
Seriously.
On May 21, 2011 1:17 PM, "James A. Donald" wrote:
> On 2011-05-21 9:12 AM, Paul Crowley wrote:
>> On 20/05/11 23:49, Nico Williams wrote:
>>> What about using Shcnorr's signature scheme with ECDH? Here's DJB
>>> talking about it in the context of his Curve25519, which uses the
>>> discard-y point compression technique:
>>>
>>> http://www.derkeiler.com/Newsgroups/sci.crypt/2006-08/msg01621.html
>>>
>>> This would seem adequate to me, and should result in small signatures.
>>
>> I don't see how "discard y" works here. It works for DH because x(?yB) =
>> ?xyB = y(?xB). But for Schnorr the verifier needs sB-rnB and sB-rnB !=
>> sB-r(-nB). I guess it wouldn't be too expensive to try both - any
>> opinions on the patent status of that?
>
> I believe that the wheel is patented, as is the idea of trying to get
> around the patent by using something other than a wheel for the sort of
> purposes a wheel might be used for. Should someone ever figure how to
> make something other than a wheel roll, the idea of rolling non wheels
> is also patented.
>
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From smb at cs.columbia.edu Sat May 21 10:00:27 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Sat, 21 May 2011 10:00:27 -0400
Subject: [cryptography] rolling hashes, EDC/ECC vs MAC/MIC, etc.
In-Reply-To: <20110521075347.GD18510@subspacefield.org>
References: <20110520213021.GA26325@subspacefield.org>
<20110521075347.GD18510@subspacefield.org>
Message-ID:
On May 21, 2011, at 3:53 47AM, travis+ml-rbcryptography at subspacefield.org wrote:
> On Fri, May 20, 2011 at 05:18:16PM -0500, Nico Williams wrote:
>>> I wonder if A/V shouldn't use something similar?
>>
>> The rsync rolling CRC is useful for detecting insertions an deletions
>> -- i.e., remote diff.
>
> Right, but right now some anti-virus does hashes over the whole file,
> or so I've heard, and so even a single bit flip in a resource (icon)
> can defeat some of them.
Anti-virus programs have long since abandoned simple, whole-file matches,
for all of the obvious reasons. Some even emulate execution of the file
to see what actually happens. See http://en.wikipedia.org/wiki/Antivirus
(and of course its references) for details.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
From zooko at zooko.com Sat May 21 14:50:19 2011
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Sat, 21 May 2011 12:50:19 -0600
Subject: [cryptography] rolling hashes, EDC/ECC vs MAC/MIC, etc.
In-Reply-To:
References: <20110520213021.GA26325@subspacefield.org>
Message-ID:
Dear Nico Williams:
Thanks for the reference! Very cool.
What I would most want is for ZFS (and every other filesystem) to
maintain a Merkle Tree over the file data with a good secure hash.
Whenever a change to a file is made, the filesystem can update the
Merkle Tree this with mere O(log(N)) work in the size of the file plus
O(N) work in the size of the change. For a modern filesystem like ZFS
which is already maintaining a checksum tree the *added* cost of
maintaining the secure hash Merkle Tree could be minimal.
Then, the filesystem should make this Merkle Tree available to
applications through a simple query.
This would enable applications?without needing any further
in-filesystem code?to perform a Merkle Tree sync, which would range
from "noticeably more efficient" to "dramatically more efficient" than
rsync or zfs send. :-)
Of course it is only more efficient because we're treating the
maintenance of the secure-hash Merkle Tree as free. There are two
senses in which this is legitimate and it is almost free:
1. Since the values get maintained persistently over the file's
lifetime then the total computation required is approximately O(N)
where N is the total size of all deltas that have been applied to the
file in its life. (Let's just drop the logarithmic part for now,
because see 2. below.)
Compare this to the cost of doing a fast, insecure CRC over the whole
file such as in rsync. The cost of that is O(N) * K where N is the
(then current) size of the file and K is the number of times you run
rsync on that file.
The extreme case is if the file hasn't changed. Then for the
application-level code to confirm that the file on this machine is the
same as the file on that machine, it merely has to ask the filesystem
for the root hash on each machine and transmit that root hash over the
network. This is optimally fast compared to rsync, and unlike "zfs
send|recv" it is optimally fast whenever the two files are identical
even if they have both changed since the last time they were synced.
2. Since the modern, sophisticated filesystem like ZFS is maintaining
a tree of checksums over the data *anyway* you can piggy-back this
computation onto that work, avoiding any extra seeks and minimizing
extra memory access.
In fact, ZFS itself can actually use SHA-256 for the checksum tree,
which would make it almost provide exactly what I want, except for:
2. a. From what I've read, nobody uses the SHA-256 configuration in
ZFS because it is too computationally expensive, so they use an
insecure checksum (fletcher2/4) instead.
2. b. I assume the shape of the resulting checksum tree is modified by
artifacts of the ZFS layout instead of being a simple canonical shape.
This is a show-stopper for this use case because if the same file data
exists on a different system, and some software on that system
computes a Merkle Tree over the data, it might come out with different
hashes than the ZFS checksum tree, thus eliminating all of the
performance benefits of this approach.
But, if ZFS could be modified to fix these problems or if a new
filesystem would add a feature of maintaining a canonical,
reproducible Merkle Tree, then it might be extremely useful.
Thanks to Brian Warner and Dan Shoutis for discussions about this idea.
Regards,
Zooko
From nico at cryptonector.com Sat May 21 17:00:38 2011
From: nico at cryptonector.com (Nico Williams)
Date: Sat, 21 May 2011 16:00:38 -0500
Subject: [cryptography] rolling hashes, EDC/ECC vs MAC/MIC, etc.
In-Reply-To: <20110521075347.GD18510@subspacefield.org>
References: <20110520213021.GA26325@subspacefield.org>
<20110521075347.GD18510@subspacefield.org>
Message-ID:
On Sat, May 21, 2011 at 2:53 AM,
wrote:
> On Fri, May 20, 2011 at 05:18:16PM -0500, Nico Williams wrote:
>> A function with
>> that property isn't a hash function.
>
> How do you figure?
Well, to be fair, a rolling hash is a hash function, proper. It may
well not be what we'd call a cryptographically secure function, and
I'll admit I'm not certain of that, that it is my intuition that a
rolling hash is not cryptographically secure. I find very little
research on cryptographically secure rolling hash functions (for
laughs though, search for "secure rolling hash"), but even so, I'm
having second thoughts about my statement above.
Nico
--
From nico at cryptonector.com Sat May 21 17:22:27 2011
From: nico at cryptonector.com (Nico Williams)
Date: Sat, 21 May 2011 16:22:27 -0500
Subject: [cryptography] rolling hashes, EDC/ECC vs MAC/MIC, etc.
In-Reply-To:
References: <20110520213021.GA26325@subspacefield.org>
Message-ID:
On Sat, May 21, 2011 at 1:50 PM, Zooko O'Whielacronx wrote:
> What I would most want is for ZFS (and every other filesystem) to
> maintain a Merkle Tree over the file data with a good secure hash.
Me too. ZFS does do that, but unfortunately the internal Merkel hash
maintained this way also has metadata tree nodes (namely, indirect
blocks), which wouldn't be a problem except that embedded in that
metadata (and hashed in) are block pointers, which contain some data
which is completely non-deterministic relative to the file contents.
The right thing to have done would have been to exclude the address
portion of block pointers, but that owuld have required more data
movement and/or computation (and perhaps was not thought of at the
time, but I was never in the ZFS team, so I'd not know.
> Whenever a change to a file is made, the filesystem can update the
> Merkle Tree this with mere O(log(N)) work in the size of the file plus
> O(N) work in the size of the change. For a modern filesystem like ZFS
> which is already maintaining a checksum tree the *added* cost of
> maintaining the secure hash Merkle Tree could be minimal.
Right!
> Then, the filesystem should make this Merkle Tree available to
> applications through a simple query.
Indeed. And if non-deterministic metadata is excluded then the only
thing one would have to know in order to independently compute the
same hash would be the maximum breath of the tree and leaf block size,
and that the tree is intended to be kept with all but the rightmost
leaf node full. This would be a wonderful feature to have.
> This would enable applications?without needing any further
> in-filesystem code?to perform a Merkle Tree sync, which would range
> from "noticeably more efficient" to "dramatically more efficient" than
> rsync or zfs send. :-)
I haven't thought about this enough, but my level-0 concern would be
that data moves not aligned with block size would require a rolling
hash in order to make synchronization efficient, thus the Merkle tree
wouldn't help unless, perhaps, it were constructed from rolling hash
functions.
The other thought I had was that now that we accept that file stores
need large amounts of computational power, not jut I/O bandwidth, it's
not a stretch for the server to also compute and store (i.e.,
pre-compute) arrays of rolling CRCs, each taken over a small data
chunk contiguous with the preceding and succeeding ones. This would
allow a client to very quickly read the rsync signature of a remote
file and locally generate a patch to it, making the write process very
efficient for large files that get many small changes all over the
place.
> Of course it is only more efficient because we're treating the
> maintenance of the secure-hash Merkle Tree as free. There are two
> senses in which this is legitimate and it is almost free:
And/or because we intend to use this for optimizing an otherwise slow
operation, and if we do it enough then it'd be worthwhile even if the
given FS had never before used a Merkle tree.
> [...]
> 2. a. From what I've read, nobody uses the SHA-256 configuration in
> ZFS because it is too computationally expensive, so they use an
> insecure checksum (fletcher2/4) instead.
You kinda have to use SHA-256 if you want dedup.
> 2. b. I assume the shape of the resulting checksum tree is modified by
> artifacts of the ZFS layout instead of being a simple canonical shape.
Yes: a) the shape of the indirect block tree (but this is
deterministic if you know the maximum block size for the filesystem
and the maximum block size for the file), and b) physical block
address information in indirect blocks (which can and should have been
excluded -- it's good enough to compute the hash of an indirect block
over the block checksums in each block pointer). See above. Oh,
also, there the first few block pointers in the dnode too.
> This is a show-stopper for this use case because if the same file data
> exists on a different system, and some software on that system
> computes a Merkle Tree over the data, it might come out with different
> hashes than the ZFS checksum tree, thus eliminating all of the
> performance benefits of this approach.
Indeed, but:
> But, if ZFS could be modified to fix these problems or if a new
> filesystem would add a feature of maintaining a canonical,
> reproducible Merkle Tree, then it might be extremely useful.
I think it could be. I don't think you'll get much out of ZFS folks
nowadays though. Maybe if you talk to ZFS folks outside of Oracle
though, they might confirm whether this is doable.
BTW, IIRC I filed an RFE at Sun to expose a Merkle hash tree checksum
to applications. I believe I've seen others ask for this before too
at various times, and it may be that the RFE I filed (if I did) was in
response to a request on one of the OSOL discuss lists -- this must
have been back in 2005. This is a really, really obvious enhancement
to want -- it should be obvious the moment you realize that Merkle
hash trees are a godsend.
Nico
--
From danilo.gligoroski at gmail.com Fri May 27 02:28:33 2011
From: danilo.gligoroski at gmail.com (Danilo Gligoroski)
Date: Fri, 27 May 2011 08:28:33 +0200
Subject: [cryptography] D-Wave Sells First Quantum Computer
In-Reply-To:
References: <20110520213021.GA26325@subspacefield.org>
Message-ID: <4ddf449d.0f0edf0a.60ec.31a4@mx.google.com>
I am among skeptics that quantum computers will break RSA1024 or ECDSA160 in the next 35 years, but maybe I have to revise my views.
http://www.hpcwire.com/hpcwire/2011-05-26/d-wave_sells_first_quantum_computer.html
On Wednesday, D-Wave Systems made history by announcing the sale of the world's first commercial quantum computer. The buyer was Lockheed Martin Corporation, who will use the machine to help solve some of their "most challenging computation problems." ...
... D-Wave One uses a superconducting 128-qubit (quantum bit) chip, called Rainier, representing the first commercial implementation of a quantum processor. An early prototype, a 16-qubit system called Orion, was demonstrated in February 2007. At the time, D-Wave was talking about future systems based on 512-qubit and 1024-qubit technology, but the 128-qubit Rainier turned out to be the company's first foray into the commercial market. ...
Regards,
Danilo!
From jamesd at echeque.com Fri May 27 03:54:21 2011
From: jamesd at echeque.com (James A. Donald)
Date: Fri, 27 May 2011 17:54:21 +1000
Subject: [cryptography] D-Wave Sells First Quantum Computer
In-Reply-To: <4ddf449d.0f0edf0a.60ec.31a4@mx.google.com>
References: <20110520213021.GA26325@subspacefield.org>
<4ddf449d.0f0edf0a.60ec.31a4@mx.google.com>
Message-ID: <4DDF58AD.6090208@echeque.com>
On 2011-05-27 4:28 PM, Danilo Gligoroski wrote:
> I am among skeptics that quantum computers will break RSA1024 or ECDSA160 in the next 35 years, but maybe I have to revise my views.
>
> http://www.hpcwire.com/hpcwire/2011-05-26/d-wave_sells_first_quantum_computer.html
>
>
> On Wednesday, D-Wave Systems made history by announcing the sale of the world's first commercial quantum computer. The buyer was Lockheed Martin Corporation, who will use the machine to help solve some of their "most challenging computation problems." ...
>
> ... D-Wave One uses a superconducting 128-qubit (quantum bit) chip, called Rainier, representing the first commercial implementation of a quantum processor. An early prototype, a 16-qubit system called Orion, was demonstrated in February 2007. At the time, D-Wave was talking about future systems based on 512-qubit and 1024-qubit technology, but the 128-qubit Rainier turned out to be the company's first foray into the commercial market. ...
128 quantum bits sounds like a lot, but it is less than it seems,
because this is not a general purpose quantum computer, though it can
emmulate a general purpose quantum computer with considerably fewer
quantum bits.
From lodewijkadlp at gmail.com Fri May 27 06:14:37 2011
From: lodewijkadlp at gmail.com (=?UTF-8?Q?lodewijk_andr=C3=A9_de_la_porte?=)
Date: Fri, 27 May 2011 12:14:37 +0200
Subject: [cryptography] D-Wave Sells First Quantum Computer
In-Reply-To: <4DDF58AD.6090208@echeque.com>
References: <20110520213021.GA26325@subspacefield.org>
<4ddf449d.0f0edf0a.60ec.31a4@mx.google.com>
<4DDF58AD.6090208@echeque.com>
Message-ID:
Any word on the kind of processing power this thing is? It really does sound
like the future, with it's supercooled processor 'n all. They state the
price is "consistent with large-scal,high-performance computing systems"
whatever that means, could it possibly be worthwhile?
>From wikipedia:
> *quantum annealing* (QA) is a general method for finding the global
> minimum of a given *objective
> function * over a given
> set of *candidate solutions* (the *search space*), by a process analogous
> to quantum fluctuations
> .
Which makes it quite usable, to my suprise.
In 30 years I'll have one at home. Not to worry.
Best regards,
Lodewijk
2011/5/27 James A. Donald
> On 2011-05-27 4:28 PM, Danilo Gligoroski wrote:
>
>> I am among skeptics that quantum computers will break RSA1024 or ECDSA160
>> in the next 35 years, but maybe I have to revise my views.
>>
>>
>> http://www.hpcwire.com/hpcwire/2011-05-26/d-wave_sells_first_quantum_computer.html
>>
>>
>> On Wednesday, D-Wave Systems made history by announcing the sale of the
>> world's first commercial quantum computer. The buyer was Lockheed Martin
>> Corporation, who will use the machine to help solve some of their "most
>> challenging computation problems." ...
>>
>> ... D-Wave One uses a superconducting 128-qubit (quantum bit) chip, called
>> Rainier, representing the first commercial implementation of a quantum
>> processor. An early prototype, a 16-qubit system called Orion, was
>> demonstrated in February 2007. At the time, D-Wave was talking about future
>> systems based on 512-qubit and 1024-qubit technology, but the 128-qubit
>> Rainier turned out to be the company's first foray into the commercial
>> market. ...
>>
>
> 128 quantum bits sounds like a lot, but it is less than it seems, because
> this is not a general purpose quantum computer, though it can emmulate a
> general purpose quantum computer with considerably fewer quantum bits.
>
>
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jeanphilippe.aumasson at gmail.com Fri May 27 06:24:24 2011
From: jeanphilippe.aumasson at gmail.com (Jean-Philippe Aumasson)
Date: Fri, 27 May 2011 12:24:24 +0200
Subject: [cryptography] D-Wave Sells First Quantum Computer
In-Reply-To:
References: <20110520213021.GA26325@subspacefield.org>
<4ddf449d.0f0edf0a.60ec.31a4@mx.google.com>
<4DDF58AD.6090208@echeque.com>
Message-ID:
Scott Aaronson's take on D-wave quantum computer and recent Nature paper:
http://blogs.forbes.com/alexknapp/2011/05/24/q-and-a-with-prof-scott-aaronson-on-d-waves-quantum-computer/
Excerpts:
"they?re not claiming a ?quantum speedup? ? i.e., to solve some actual
computational problem faster using quantum coherence. They?re just
claiming an observation of the sorts of quantum effects that would be
a prerequisite to such a speedup"
"researchers have constructed special examples of optimization
problems where quantum annealing reaches the global optimum
exponentially faster than classical simulated annealing. But on the
other hand, they?ve constructed other examples where quantum annealing
is just as slow as classical simulated annealing, both of them getting
trapped in local optima!"
"any claims by D-Wave that the practical value of quantum annealing
has already been demonstrated need to be taken with a huge grain of
salt"
2011/5/27 lodewijk andr? de la porte :
> Any word on the kind of processing power this thing is? It really does sound
> like the future, with it's supercooled processor 'n all. They state the
> price is "consistent with large-scal,high-performance computing systems"
> whatever that means, could it possibly be worthwhile?
> From wikipedia:
>>
>> quantum annealing?(QA) is a general method for finding the?global
>> minimum?of a given?objective function?over a given set of?candidate
>> solutions?(the?search space), by a process analogous to?quantum
>> fluctuations.
>
> Which makes it quite usable, to my suprise.
> In 30 years I'll have one at home. Not to worry.
> Best regards,
> Lodewijk
>
> 2011/5/27 James A. Donald
>>
>> On 2011-05-27 4:28 PM, Danilo Gligoroski wrote:
>>>
>>> I am among skeptics that quantum computers will break RSA1024 or ECDSA160
>>> in the next 35 years, but maybe I have to revise my views.
>>>
>>>
>>> http://www.hpcwire.com/hpcwire/2011-05-26/d-wave_sells_first_quantum_computer.html
>>>
>>>
>>> On Wednesday, D-Wave Systems made history by announcing the sale of the
>>> world's first commercial quantum computer. The buyer was Lockheed Martin
>>> Corporation, who will use the machine to help solve some of their "most
>>> challenging computation problems." ...
>>>
>>> ... D-Wave One uses a superconducting 128-qubit (quantum bit) chip,
>>> called Rainier, representing the first commercial implementation of a
>>> quantum processor. An early prototype, a 16-qubit system called Orion, was
>>> demonstrated in February 2007. At the time, D-Wave was talking about future
>>> systems based on 512-qubit and 1024-qubit technology, but the 128-qubit
>>> Rainier turned out to be the company's first foray into the commercial
>>> market. ...
>>
>> 128 quantum bits sounds like a lot, but it is less than it seems, because
>> this is not a general purpose quantum computer, though it can emmulate a
>> general purpose quantum computer with considerably fewer quantum bits.
>>
>> _______________________________________________
>> cryptography mailing list
>> cryptography at randombit.net
>> http://lists.randombit.net/mailman/listinfo/cryptography
>
>
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
>
From zooko at zooko.com Fri May 27 09:03:38 2011
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Fri, 27 May 2011 07:03:38 -0600
Subject: [cryptography] Point compression prior art?
In-Reply-To: <4DD1AB52.4070008@jacaranda.org>
References: <4DC02CE0.6070900@ciphergoth.org>
<4DD1AB52.4070008@jacaranda.org>
Message-ID:
Daniel J. Bernstein wrote to me on 2011-05-14. Everything below is
quoted from that letter. --Zooko
------- begin appended copy of letter
Hi Zooko,
I tried following up to cryptography at randombit.net but haven't taken the
time to figure out which hoops to jump through to make messages actually
appear there. Anyway, you have to read the "parent case" section of the
patent:
This is a continuation of PCT/CA95/00452, filed on Jul. 31, 1995,
which is a continuation-in-part of Ser. No. 08/282,263, filed on Jul.
29, 1994, now abandoned.
This means that the patent can survive prior art after July 1993, but it
also means that the patent expires in 2014.
---Dan
From jamesd at echeque.com Fri May 27 15:29:25 2011
From: jamesd at echeque.com (James A. Donald)
Date: Sat, 28 May 2011 05:29:25 +1000
Subject: [cryptography] Point compression prior art?
In-Reply-To:
References: <4DC02CE0.6070900@ciphergoth.org> <4DD1AB52.4070008@jacaranda.org>
Message-ID: <4DDFFB95.5090203@echeque.com>
On 2011-05-27 11:03 PM, Zooko O'Whielacronx wrote:
> Daniel J. Bernstein wrote to me on 2011-05-14. Everything below is
> quoted from that letter. --Zooko
>
> ------- begin appended copy of letter
> Hi Zooko,
>
> I tried following up to cryptography at randombit.net but haven't taken the
> time to figure out which hoops to jump through to make messages actually
> appear there. Anyway, you have to read the "parent case" section of the
> patent:
>
> This is a continuation of PCT/CA95/00452, filed on Jul. 31, 1995,
> which is a continuation-in-part of Ser. No. 08/282,263, filed on Jul.
> 29, 1994, now abandoned.
>
> This means that the patent can survive prior art after July 1993, but it
> also means that the patent expires in 2014.
So there is 1992 prior art representing a point by the x coordinate,
plus one bit selecting one of the two possible Y coordinates,
page 171 of the Harper-Menezes-Vanstone paper
"Public-key cryptosystems with very small key
lengths" at Eurocrypt '92,
and the patent would have expired anyway by the time someone gets around
to suing you.
The usual pattern, however, is to simply patent something else, usually
something with even older prior art. I believe that the patent on
wheels still stands.
From jamesd at echeque.com Fri May 27 22:37:23 2011
From: jamesd at echeque.com (James A. Donald)
Date: Sat, 28 May 2011 12:37:23 +1000
Subject: [cryptography] D-Wave Sells First Quantum Computer
In-Reply-To:
References: <20110520213021.GA26325@subspacefield.org> <4ddf449d.0f0edf0a.60ec.31a4@mx.google.com> <4DDF58AD.6090208@echeque.com>
Message-ID: <4DE05FE3.4030307@echeque.com>
On 2011-05-27 8:24 PM, Jean-Philippe Aumasson wrote:
> "researchers have constructed special examples of optimization
> problems where quantum annealing reaches the global optimum
> exponentially faster than classical simulated annealing. But on the
> other hand, they?ve constructed other examples where quantum annealing
> is just as slow as classical simulated annealing, both of them getting
> trapped in local optima!"
What can be said is that the class of problems soluble by a quantum
computer is larger than the class of problems soluble by a classical
computer.
How much larger is an empirical question.
From lodewijkadlp at gmail.com Sat May 28 10:27:33 2011
From: lodewijkadlp at gmail.com (=?UTF-8?Q?lodewijk_andr=C3=A9_de_la_porte?=)
Date: Sat, 28 May 2011 16:27:33 +0200
Subject: [cryptography] D-Wave Sells First Quantum Computer
In-Reply-To: <454035F23932FA428F6A0B77ABB406A301708DA98AB8@OITMXCMS02VI.AD.UMD.EDU>
References: <454035F23932FA428F6A0B77ABB406A301708DA98AB8@OITMXCMS02VI.AD.UMD.EDU>
Message-ID:
This explaination is the first that really makes sense. Thanks.
(although there is future in quantum computing as in bits with >2 possible
values. This is not a "general computing" quantum computer.)
2011/5/28 Mark Avrum Gubrud
> Lockheed will use the D-Wave device to conduct further "research" on
> contract to the USG (DoD, DHS, IC) under classification (D-wave is I believe
> a Canadian company) which will serve to further cover up its uselessness.
> They may also use it to spice up marketing for their security services,
> since D-Wave is claiming they can use it to generate "software" for image
> recognition. Lockheed can then say they make use of 'advanced quantum
> computing, an industry first, to generate algorithms for target
> recognition.' That should certainly help do the trick when the customers
> are military, government and corporate bureaucrats and politicians.
>
> ----- Forwarded message from Jean-Philippe Aumasson <
> jeanphilippe.aumasson at gmail.com> -----
>
> From: Jean-Philippe Aumasson
> Date: Fri, 27 May 2011 12:24:24 +0200
> To: Crypto discussion list
> Subject: Re: [cryptography] D-Wave Sells First Quantum Computer
> Reply-To: Crypto discussion list
>
> Scott Aaronson's take on D-wave quantum computer and recent Nature paper:
>
> http://blogs.forbes.com/alexknapp/2011/05/24/q-and-a-with-prof-scott-aaronson-on-d-waves-quantum-computer/
>
> Excerpts:
>
> "they?re not claiming a ?quantum speedup? ? i.e., to solve some actual
> computational problem faster using quantum coherence. They?re just
> claiming an observation of the sorts of quantum effects that would be
> a prerequisite to such a speedup"
>
> "researchers have constructed special examples of optimization
> problems where quantum annealing reaches the global optimum
> exponentially faster than classical simulated annealing. But on the
> other hand, they?ve constructed other examples where quantum annealing
> is just as slow as classical simulated annealing, both of them getting
> trapped in local optima!"
>
> "any claims by D-Wave that the practical value of quantum annealing
> has already been demonstrated need to be taken with a huge grain of
> salt"
>
>
>
>
> 2011/5/27 lodewijk andr? de la porte :
> > Any word on the kind of processing power this thing is? It really does
> sound
> > like the future, with it's supercooled processor 'n all. They state the
> > price is "consistent with large-scal,high-performance computing systems"
> > whatever that means, could it possibly be worthwhile?
> > From wikipedia:
> >>
> >> quantum annealing?(QA) is a general method for finding the?global
> >> minimum?of a given?objective function?over a given set of?candidate
> >> solutions?(the?search space), by a process analogous to?quantum
> >> fluctuations.
> >
> > Which makes it quite usable, to my suprise.
> > In 30 years I'll have one at home. Not to worry.
> > Best regards,
> > Lodewijk
> >
> > 2011/5/27 James A. Donald
> >>
> >> On 2011-05-27 4:28 PM, Danilo Gligoroski wrote:
> >>>
> >>> I am among skeptics that quantum computers will break RSA1024 or
> ECDSA160
> >>> in the next 35 years, but maybe I have to revise my views.
> >>>
> >>>
> >>>
> http://www.hpcwire.com/hpcwire/2011-05-26/d-wave_sells_first_quantum_computer.html
> >>>
> >>>
> >>> On Wednesday, D-Wave Systems made history by announcing the sale of the
> >>> world's first commercial quantum computer. The buyer was Lockheed
> Martin
> >>> Corporation, who will use the machine to help solve some of their "most
> >>> challenging computation problems." ...
> >>>
> >>> ... D-Wave One uses a superconducting 128-qubit (quantum bit) chip,
> >>> called Rainier, representing the first commercial implementation of a
> >>> quantum processor. An early prototype, a 16-qubit system called Orion,
> was
> >>> demonstrated in February 2007. At the time, D-Wave was talking about
> future
> >>> systems based on 512-qubit and 1024-qubit technology, but the 128-qubit
> >>> Rainier turned out to be the company's first foray into the commercial
> >>> market. ...
> >>
> >> 128 quantum bits sounds like a lot, but it is less than it seems,
> because
> >> this is not a general purpose quantum computer, though it can emmulate a
> >> general purpose quantum computer with considerably fewer quantum bits.
> >>
> >> _______________________________________________
> >> cryptography mailing list
> >> cryptography at randombit.net
> >> http://lists.randombit.net/mailman/listinfo/cryptography
> >
> >
> > _______________________________________________
> > cryptography mailing list
> > cryptography at randombit.net
> > http://lists.randombit.net/mailman/listinfo/cryptography
> >
> >
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
> ----- End forwarded message -----
> --
> Eugen* Leitl leitl http://leitl.org
> ______________________________________________________________
> ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
> 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david-sarah at jacaranda.org Sat May 28 19:01:55 2011
From: david-sarah at jacaranda.org (David-Sarah Hopwood)
Date: Sun, 29 May 2011 00:01:55 +0100
Subject: [cryptography] D-Wave Sells First Quantum Computer
In-Reply-To: <4DE05FE3.4030307@echeque.com>
References: <20110520213021.GA26325@subspacefield.org> <4ddf449d.0f0edf0a.60ec.31a4@mx.google.com> <4DDF58AD.6090208@echeque.com>
<4DE05FE3.4030307@echeque.com>
Message-ID: <4DE17EE3.4000500@jacaranda.org>
On 28/05/11 03:37, James A. Donald wrote:
> On 2011-05-27 8:24 PM, Jean-Philippe Aumasson wrote:
>> "researchers have constructed special examples of optimization
>> problems where quantum annealing reaches the global optimum
>> exponentially faster than classical simulated annealing. But on the
>> other hand, they?ve constructed other examples where quantum annealing
>> is just as slow as classical simulated annealing, both of them getting
>> trapped in local optima!"
>
> What can be said is that the class of problems soluble by a quantum computer
> is larger than the class of problems soluble by a classical computer.
No, it can't:
- for idealized quantum and classical computers (with unbounded memory
running for unbounded time), those classes are identical.
- for quantum and classical computers that can be practically built at any
point in time, and with a limit on the time to find a solution, it
certainly isn't clear that the class of problems soluble by quantum
computers will be larger (ever). That depends on how big and fast you
can make quantum computers and classical computers.
--
David-Sarah Hopwood ? http://davidsarah.livejournal.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 294 bytes
Desc: OpenPGP digital signature
URL:
From jamesd at echeque.com Sat May 28 22:05:40 2011
From: jamesd at echeque.com (James A. Donald)
Date: Sun, 29 May 2011 12:05:40 +1000
Subject: [cryptography] D-Wave Sells First Quantum Computer
In-Reply-To: <4DE17EE3.4000500@jacaranda.org>
References: <20110520213021.GA26325@subspacefield.org> <4ddf449d.0f0edf0a.60ec.31a4@mx.google.com> <4DDF58AD.6090208@echeque.com> <4DE05FE3.4030307@echeque.com>
<4DE17EE3.4000500@jacaranda.org>
Message-ID: <4DE1A9F4.3020404@echeque.com>
On 28/05/11 03:37, James A. Donald wrote:
>> What can be said is that the class of problems soluble by a quantum computer
>> is larger than the class of problems soluble by a classical computer.
On 2011-05-29 9:01 AM, David-Sarah Hopwood wrote:
> No, it can't:
>
> - for idealized quantum and classical computers (with unbounded memory
> running for unbounded time), those classes are identical.
>
> - for quantum and classical computers that can be practically built at any
> point in time, and with a limit on the time to find a solution, it
> certainly isn't clear that the class of problems soluble by quantum
> computers will be larger (ever). That depends on how big and fast you
> can make quantum computers and classical computers.
What can be said is that the class of problems soluble by a quantum
computer with a polynomially large number of components in polynomial
time is larger than the class of problems soluble by a classical
computer with a polynomially large number of components in polynomial time.
From njloof at gmail.com Sat May 28 22:24:52 2011
From: njloof at gmail.com (Nathan Loofbourrow)
Date: Sat, 28 May 2011 19:24:52 -0700
Subject: [cryptography] D-Wave Sells First Quantum Computer
In-Reply-To: <4DE1A9F4.3020404@echeque.com>
References: <20110520213021.GA26325@subspacefield.org>
<4ddf449d.0f0edf0a.60ec.31a4@mx.google.com>
<4DDF58AD.6090208@echeque.com>
<4DE05FE3.4030307@echeque.com> <4DE17EE3.4000500@jacaranda.org>
<4DE1A9F4.3020404@echeque.com>
Message-ID:
On Sat, May 28, 2011 at 7:05 PM, James A. Donald wrote:
> On 28/05/11 03:37, James A. Donald wrote:
>
>> What can be said is that the class of problems soluble by a quantum
>>> computer
>>> is larger than the class of problems soluble by a classical computer.
>>>
>>
> On 2011-05-29 9:01 AM, David-Sarah Hopwood wrote:
>
>> No, it can't:
>>
>> - for idealized quantum and classical computers (with unbounded memory
>> running for unbounded time), those classes are identical.
>>
>> - for quantum and classical computers that can be practically built at
>> any
>> point in time, and with a limit on the time to find a solution, it
>> certainly isn't clear that the class of problems soluble by quantum
>> computers will be larger (ever). That depends on how big and fast you
>> can make quantum computers and classical computers.
>>
>
> What can be said is that the class of problems soluble by a quantum
> computer with a polynomially large number of components in polynomial time
> is larger than the class of problems soluble by a classical computer with a
> polynomially large number of components in polynomial time.
Wait, was P!=NP proven and I missed it? I thought it was merely an assertion
with overwhelming evidence, but no formal proof.
n
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From lodewijkadlp at gmail.com Sat May 28 23:52:56 2011
From: lodewijkadlp at gmail.com (=?UTF-8?Q?lodewijk_andr=C3=A9_de_la_porte?=)
Date: Sun, 29 May 2011 05:52:56 +0200
Subject: [cryptography] D-Wave Sells First Quantum Computer
In-Reply-To:
References: <20110520213021.GA26325@subspacefield.org>
<4ddf449d.0f0edf0a.60ec.31a4@mx.google.com>
<4DDF58AD.6090208@echeque.com>
<4DE05FE3.4030307@echeque.com> <4DE17EE3.4000500@jacaranda.org>
<4DE1A9F4.3020404@echeque.com>
Message-ID:
May I forumulate Lewis' first law:
As a discussion amoungst computer scientists continues the propability of
the P != NP problem being mentioned tends to to 1.
Or was this a law already? It seems familliar.
-Lodewijk "Lewis" Andr? de la Porte
On May 29, 2011 4:25 AM, "Nathan Loofbourrow" wrote:
> On Sat, May 28, 2011 at 7:05 PM, James A. Donald
wrote:
>
>> On 28/05/11 03:37, James A. Donald wrote:
>>
>>> What can be said is that the class of problems soluble by a quantum
>>>> computer
>>>> is larger than the class of problems soluble by a classical computer.
>>>>
>>>
>> On 2011-05-29 9:01 AM, David-Sarah Hopwood wrote:
>>
>>> No, it can't:
>>>
>>> - for idealized quantum and classical computers (with unbounded memory
>>> running for unbounded time), those classes are identical.
>>>
>>> - for quantum and classical computers that can be practically built at
>>> any
>>> point in time, and with a limit on the time to find a solution, it
>>> certainly isn't clear that the class of problems soluble by quantum
>>> computers will be larger (ever). That depends on how big and fast you
>>> can make quantum computers and classical computers.
>>>
>>
>> What can be said is that the class of problems soluble by a quantum
>> computer with a polynomially large number of components in polynomial
time
>> is larger than the class of problems soluble by a classical computer with
a
>> polynomially large number of components in polynomial time.
>
>
> Wait, was P!=NP proven and I missed it? I thought it was merely an
assertion
> with overwhelming evidence, but no formal proof.
>
> n
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From paul at ciphergoth.org Sun May 29 13:12:26 2011
From: paul at ciphergoth.org (Paul Crowley)
Date: Sun, 29 May 2011 18:12:26 +0100
Subject: [cryptography] Small speedup of ECDLP?
Message-ID: <4DE27E7A.1090907@ciphergoth.org>
I doubt this is original, but I'd be interested to know who thought of
it first. Given a group G with generator g and a point y in the group,
suppose you're using the standard parallelized Pollard rho attack to
find x such that ax = y. If the time t_a it takes you to add g to an
arbitrary point on an elliptic curve p is much less than the time t_p it
takes you to find ag + by for arbitrary a, b then I think I see a way to
speed up Pollard-Rho by around sqrt(t_p/4t_a).
A standard birthday attack requires that sqrt(2 ln(2) N) to find a
collision in a random-ish function with a range of size N, so the
standard Pollard rho attack generates about sqrt(2 ln(2) |G|) such
points for a 50% probability of success, taking time sqrt(2 ln(2) |G|) t_p.
To get the speedup, we need a set D of easily identified "distinguished
points" in G, perhaps by examining least significant bits, such that |D|
/ |G| ? t_a / t_p. Then for each a, b, we find the least non-negative c
such that (a + c)g + by ? D; we do this just by starting with ag + by
and adding g repeatedly until we end up with a point in D. Assuming
this behaves like a Poisson distribution, this will take on average
around |G|/|D| steps. We then look for collisions in D.
Each point now takes around t_p + (|G|/|D|)t_a ? 2t_p to generate, but
because we now need a collision in D, we now only need to generate
sqrt(2 ln(2) |D|) such points. Since we're generating t_a/t_p fewer
points but each takes twice as long, we get our speedup of sqrt(t_p/4t_a).
I think it's very unlikely that the people who do this sort of thing
have missed this trick, but I'd be interested to know if it's already
been written up - can anyone point me to any references? Thanks!
--
__
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/
From sneves at dei.uc.pt Sun May 29 14:06:40 2011
From: sneves at dei.uc.pt (Samuel Neves)
Date: Sun, 29 May 2011 19:06:40 +0100
Subject: [cryptography] Small speedup of ECDLP?
In-Reply-To: <4DE27E7A.1090907@ciphergoth.org>
References: <4DE27E7A.1090907@ciphergoth.org>
Message-ID: <4DE28B30.8030906@dei.uc.pt>
On 29-05-2011 18:12, Paul Crowley wrote:
> A standard birthday attack requires that sqrt(2 ln(2) N) to find a
> collision in a random-ish function with a range of size N, so the
> standard Pollard rho attack generates about sqrt(2 ln(2) |G|) such
> points for a 50% probability of success, taking time sqrt(2 ln(2) |G|)
> t_p.
Standard birthday attacks on the (EC)DLP use r-adding walks [1] (see
also [2] and [3]), which do not require computing ax + by explicitly,
thus requiring only one group addition per iteration (i.e., t_a).
What you describe looks like a 1-adding walk, although I must have
missed something there. r-adding walks for very small r are not very
random, cf. [2].
Best regards,
Samuel Neves
[1] http://www.springerlink.com/content/y280563355n23466/
[2]
http://www.ams.org/mcom/2001-70-234/S0025-5718-00-01213-8/S0025-5718-00-01213-8.pdf
[3] http://cr.yp.to/elliptic/negation-20110102.pdf