<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent changes to Home</title><link>https://sourceforge.net/p/ed448goldilocks/wiki/Home/</link><description>Recent changes to Home</description><atom:link href="https://sourceforge.net/p/ed448goldilocks/wiki/Home/feed" rel="self"/><language>en</language><lastBuildDate>Tue, 17 Oct 2017 00:03:57 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/ed448goldilocks/wiki/Home/feed" rel="self" type="application/rss+xml"/><item><title>Home modified by Mike Hamburg</title><link>https://sourceforge.net/p/ed448goldilocks/wiki/Home/</link><description>&lt;div class="markdown_content"&gt;&lt;pre&gt;--- v10
+++ v11
@@ -1,7 +1,7 @@
 Ed448-Goldilocks
 ================

-This project page is here to host an experimental implementation of cryptography using the Ed448-Goldilocks elliptic curve.  This curve is part of the [safecurves project](http://safecurves.cr.yp.to).
+This project page is here to host an implementation of cryptography using the Ed448-Goldilocks elliptic curve.  This curve is part of the [safecurves project](http://safecurves.cr.yp.to).  The library also supports [Ed25519](https://ed25519.cr.yp.to/).

 The curve
 ---------
@@ -13,10 +13,16 @@

 Goldilocks will be a good choice for systems which are intentionally over-engineered.  That said, it is also designed to be as fast as possible for its security level.  Goldilocks is much faster than currently-deployed implementations of the weaker NIST-P256 curve.  Goldilocks is slower than Curve25519 and Ed25519 by a factor of about 3.5x.

-Bos, Costello, Longa and Naehrig have just released a [paper](https://research.microsoft.com/apps/pubs/default.aspx?id=209303) (Feb 2014) proposing new curves to replace the NIST ones, with fields on the order of 256, 384 and 512 bits.  Rough calculations suggest that on Sandy Bridge, the Goldilocks field implementation is about as fast as their fastest 384-ish-bit field (382-mont), so that overall variable-base operations on Goldilocks are slower by about 17% (~ 448/384-1).  However Goldilocks has a faster fixed-base implementation (and also uses larger tables), so it's faster at key generation and signing than any of the 384-ish-bit curves in that paper.
+The encoding
+--------
+Libdecaf supports the [Ristretto](https://ristretto.group) encoding internally.  The main goal of this encoding is to remove the cofactor from the elliptic curve group.  Cofactors are fine if you treat them with caution, but if you aren't careful then they can cause security problems.  Ristretto removes the cofactor, so it takes away one of the sharp edges of cryptography using Edwards curves.
+
+Ristretto is an evolution of the [Decaf](https://eprint.iacr.org/2015/673.pdf) encoding.
+
+The most common uses of Ed25519 and Ed448-Goldilocks are [X25519/X448 key exchange](https://tools.ietf.org/html/rfc7748) and [EdDSA signatures](https://tools.ietf.org/html/rfc8032).  These use different encodings for elliptic curve points.  Libdecaf supports those encodings as well, and contains fast implementations of X25519, X448 and EdDSA.

 Legal
------
+---------
 This is cryptographic code which originated in the United States, and so is subject to export control.

 I work for Cryptography Research, a division of Rambus.  Opinions stated here are my own, and do not necessarily reflect CRI or Rambus policy.
@@ -26,11 +32,12 @@
 I am not aware of any patents which apply to this work, though the point compression patent is close enough that you might want to read it carefully.  Likewise, I do not believe that the fixed-base comb patents apply to my comb, but I'm not a lawyer so don't take my word for it.  I'm not planning to file patents on any of the novel components of this work, but I am contractually obligated to help Rambus do so if they want to.  That said, most of the novel components are in my [paper](http://eprint.iacr.org/2012/309) from 2012, so they are safe.

 Thanks
-------
+---------
 Special thanks to:

 * Robert Ransom, for pointing out the efficient Montgomery ladder on the isomorphic curve.
-* Paulo Barreto, Dan Bernstein, Watson Ladd, Tanja Lange, Mark Marson and Trevor Perrin for their helpful feedback and encouragement. 
+* Paulo Barreto, Dan Bernstein, Watson Ladd, Tanja Lange, Mark Marson and Trevor Perrin for their helpful feedback and encouragement.
+* Isis Lovecruft, Henry de Valence, and Tony Arcieri for their collaboration on Ristretto.
 * Ben Jun and Dan Boneh, who approved the code for release.
 * Judy Shie, Jae Kim, Michael Moore and Anne Seymour, who dealt with the legal aspects.

&lt;/pre&gt;
&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mike Hamburg</dc:creator><pubDate>Tue, 17 Oct 2017 00:03:57 -0000</pubDate><guid>https://sourceforge.net28012079d13edcce4a34979c63f7a812ef143e90</guid></item><item><title>Home modified by Mike Hamburg</title><link>https://sourceforge.net/p/ed448goldilocks/wiki/Home/</link><description>&lt;div class="markdown_content"&gt;&lt;pre&gt;--- v9
+++ v10
@@ -7,7 +7,7 @@
 ---------
 Ed448-Goldilocks is the elliptic curve:

-x&lt;sup&gt;2&lt;/sup&gt; + y&lt;sup&gt;2&lt;/sup&gt; = 1 - 39081x&lt;sup&gt;2&lt;/sup&gt;y&lt;sup&gt;2&lt;/sup&gt; mod 2&lt;sup&gt;448&lt;/sup&gt; - 2&lt;sup&gt;224&lt;/sup&gt; - 1
+&lt;center&gt;x&lt;sup&gt;2&lt;/sup&gt; + y&lt;sup&gt;2&lt;/sup&gt; ≣ 1 - 39081x&lt;sup&gt;2&lt;/sup&gt;y&lt;sup&gt;2&lt;/sup&gt; mod 2&lt;sup&gt;448&lt;/sup&gt; - 2&lt;sup&gt;224&lt;/sup&gt; - 1&lt;/center&gt;

 This is a 448-bit Edwards curve with a 223-bit conjectured security level.  It is designed for [spinal tap grade security](http://silentcircle.wordpress.com/tag/spinal-tap/).  The self-deprecating humor there is spot-on.  For practical security concerns, you should use the faster and more mature Curve25519 / Ed25519 software, or similar.  Curve25519's 126-bit security level is strong enough that it will take a huge mathematical breakthrough or a quantum computer to crack it.  A quantum computer would break every elliptic curve, and who knows what a mathematical breakthrough would do?

&lt;/pre&gt;
&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mike Hamburg</dc:creator><pubDate>Sun, 27 Jul 2014 20:23:33 -0000</pubDate><guid>https://sourceforge.nete4b5285cb5bfbad492e30344e9174a5121c22495</guid></item><item><title>Home modified by Mike Hamburg</title><link>https://sourceforge.net/p/ed448goldilocks/wiki/Home/</link><description>&lt;div class="markdown_content"&gt;&lt;pre&gt;--- v8
+++ v9
@@ -5,23 +5,15 @@

 The curve
 ---------
-Goldilocks is a 448-bit Edwards curve with a 223-bit conjectured security level.  It is designed for [spinal tap grade security](http://silentcircle.wordpress.com/tag/spinal-tap/).  The self-deprecating humor there is spot-on.  For practical security concerns, you should use the faster and more mature Curve25519 / Ed25519 software, or similar.  Curve25519's 126-bit security level is strong enough that it will take a huge mathematical breakthrough or a quantum computer to crack it.  A quantum computer would break every elliptic curve, and who knows what a mathematical breakthrough would do?
+Ed448-Goldilocks is the elliptic curve:
+
+x&lt;sup&gt;2&lt;/sup&gt; + y&lt;sup&gt;2&lt;/sup&gt; = 1 - 39081x&lt;sup&gt;2&lt;/sup&gt;y&lt;sup&gt;2&lt;/sup&gt; mod 2&lt;sup&gt;448&lt;/sup&gt; - 2&lt;sup&gt;224&lt;/sup&gt; - 1
+
+This is a 448-bit Edwards curve with a 223-bit conjectured security level.  It is designed for [spinal tap grade security](http://silentcircle.wordpress.com/tag/spinal-tap/).  The self-deprecating humor there is spot-on.  For practical security concerns, you should use the faster and more mature Curve25519 / Ed25519 software, or similar.  Curve25519's 126-bit security level is strong enough that it will take a huge mathematical breakthrough or a quantum computer to crack it.  A quantum computer would break every elliptic curve, and who knows what a mathematical breakthrough would do?

 Goldilocks will be a good choice for systems which are intentionally over-engineered.  That said, it is also designed to be as fast as possible for its security level.  Goldilocks is much faster than currently-deployed implementations of the weaker NIST-P256 curve.  Goldilocks is slower than Curve25519 and Ed25519 by a factor of about 3.5x.

 Bos, Costello, Longa and Naehrig have just released a [paper](https://research.microsoft.com/apps/pubs/default.aspx?id=209303) (Feb 2014) proposing new curves to replace the NIST ones, with fields on the order of 256, 384 and 512 bits.  Rough calculations suggest that on Sandy Bridge, the Goldilocks field implementation is about as fast as their fastest 384-ish-bit field (382-mont), so that overall variable-base operations on Goldilocks are slower by about 17% (~ 448/384-1).  However Goldilocks has a faster fixed-base implementation (and also uses larger tables), so it's faster at key generation and signing than any of the 384-ish-bit curves in that paper.
-
-Project status
---------------
-I've implemented:
-
-* Fixed-base-point scalar multiplication using the "signed comb" algorithm on an isogenous twisted Edwards curve.
-* Key generation using the above.
-* Variable-base-point scalar multiplication using the Montgomery ladder on an isomorphic Montgomery curve.
-* Variable-base-point scalar multiplication using a fixed 4-bit window on the isogenous Edwards curve.  This is just to check consistency and as a reference for other algorithms, since the Montgomery ladder is faster.
-* Variable-time WNAF double-scalar multiplication (one base fixed, one base variable).  This is for signature verification.
-
-All of these algorithms are designed to be secure against timing attacks, but not power analysis.

 Legal
 -----
&lt;/pre&gt;
&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mike Hamburg</dc:creator><pubDate>Sun, 27 Jul 2014 20:21:53 -0000</pubDate><guid>https://sourceforge.neta38b78246e98ab33f53d41373bb86a7381478f12</guid></item><item><title>Home modified by Mike Hamburg</title><link>https://sourceforge.net/p/ed448goldilocks/wiki/Home/</link><description>&lt;div class="markdown_content"&gt;&lt;pre&gt;--- v7
+++ v8
@@ -1,31 +1,27 @@
 Ed448-Goldilocks
 ================

-This project page is here to host an experimental and partial implementation of cryptography using the Ed448-Goldilocks elliptic curve.  This curve is part of the [safecurves project](http://safecurves.cr.yp.to).
+This project page is here to host an experimental implementation of cryptography using the Ed448-Goldilocks elliptic curve.  This curve is part of the [safecurves project](http://safecurves.cr.yp.to).

 The curve
 ---------
 Goldilocks is a 448-bit Edwards curve with a 223-bit conjectured security level.  It is designed for [spinal tap grade security](http://silentcircle.wordpress.com/tag/spinal-tap/).  The self-deprecating humor there is spot-on.  For practical security concerns, you should use the faster and more mature Curve25519 / Ed25519 software, or similar.  Curve25519's 126-bit security level is strong enough that it will take a huge mathematical breakthrough or a quantum computer to crack it.  A quantum computer would break every elliptic curve, and who knows what a mathematical breakthrough would do?

-So Goldilocks will be a good choice only for systems which are intentionally over-engineered.  That said, it is also designed to be as fast as possible for this security level.  It is more than twice as fast as the weaker NIST-P256, as implemented in OpenSSL 1.0.1f, on Intel Sandy Bridge and Haswell.  It's also much faster than NIST-P224 in OpenSSL 1.0.1f, but Emilia Kasper has since greatly improved that curve's implementation.  Goldilocks is slower than Curve25519 and Ed25519 by a factor of about 3.5x.
+Goldilocks will be a good choice for systems which are intentionally over-engineered.  That said, it is also designed to be as fast as possible for its security level.  Goldilocks is much faster than currently-deployed implementations of the weaker NIST-P256 curve.  Goldilocks is slower than Curve25519 and Ed25519 by a factor of about 3.5x.

 Bos, Costello, Longa and Naehrig have just released a [paper](https://research.microsoft.com/apps/pubs/default.aspx?id=209303) (Feb 2014) proposing new curves to replace the NIST ones, with fields on the order of 256, 384 and 512 bits.  Rough calculations suggest that on Sandy Bridge, the Goldilocks field implementation is about as fast as their fastest 384-ish-bit field (382-mont), so that overall variable-base operations on Goldilocks are slower by about 17% (~ 448/384-1).  However Goldilocks has a faster fixed-base implementation (and also uses larger tables), so it's faster at key generation and signing than any of the 384-ish-bit curves in that paper.

-I believe that Goldilocks will also support a fast ARM implementation, but I haven't made one yet.  The code I've written so far uses 64x64-&amp;gt;128-bit multiply and accumulate, so it doesn't work on ARM.
-
 Project status
 --------------
-I've mostly implemented:
+I've implemented:

 * Fixed-base-point scalar multiplication using the "signed comb" algorithm on an isogenous twisted Edwards curve.
 * Key generation using the above.
-* Variable-base-point scalar multiplication using the Montgomery ladder on an isomorphic Montgomery curve.  This can be used to compute an ECDH shared secret, except that I haven't incorporated a hash function yet.
+* Variable-base-point scalar multiplication using the Montgomery ladder on an isomorphic Montgomery curve.
 * Variable-base-point scalar multiplication using a fixed 4-bit window on the isogenous Edwards curve.  This is just to check consistency and as a reference for other algorithms, since the Montgomery ladder is faster.
 * Variable-time WNAF double-scalar multiplication (one base fixed, one base variable).  This is for signature verification.

-All of these algorithms are designed to be secure against timing attacks, but not (for example) power analysis.  I also haven't integrated a hash function yet, so you can't actually use this for real cryptography.
-
-As such, the code is only useful as a curiosity for academics and other implementors.
+All of these algorithms are designed to be secure against timing attacks, but not power analysis.

 Legal
 -----
&lt;/pre&gt;
&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mike Hamburg</dc:creator><pubDate>Sun, 27 Jul 2014 20:13:09 -0000</pubDate><guid>https://sourceforge.net061489dc516da6ded4c83c587ad2faf3c4098af2</guid></item><item><title>Home modified by Mike Hamburg</title><link>https://sourceforge.net/p/ed448goldilocks/wiki/Home/</link><description>&lt;div class="markdown_content"&gt;&lt;pre&gt;--- v6
+++ v7
@@ -44,7 +44,7 @@
 * Robert Ransom, for pointing out the efficient Montgomery ladder on the isomorphic curve.
 * Paulo Barreto, Dan Bernstein, Watson Ladd, Tanja Lange, Mark Marson and Trevor Perrin for their helpful feedback and encouragement. 
 * Ben Jun and Dan Boneh, who approved the code for release.
-* Judy Shie and Anne Seymour, who dealt with the legal aspects.
+* Judy Shie, Jae Kim, Michael Moore and Anne Seymour, who dealt with the legal aspects.

 [[members limit=20]]
 [[download_button]]
&lt;/pre&gt;
&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mike Hamburg</dc:creator><pubDate>Fri, 21 Feb 2014 23:01:11 -0000</pubDate><guid>https://sourceforge.net1971fe83197b97536b37a894ccc853ca8ca5c0c8</guid></item><item><title>Home modified by Mike Hamburg</title><link>https://sourceforge.net/p/ed448goldilocks/wiki/Home/</link><description>&lt;div class="markdown_content"&gt;&lt;pre&gt;--- v5
+++ v6
@@ -23,7 +23,7 @@
 * Variable-base-point scalar multiplication using a fixed 4-bit window on the isogenous Edwards curve.  This is just to check consistency and as a reference for other algorithms, since the Montgomery ladder is faster.
 * Variable-time WNAF double-scalar multiplication (one base fixed, one base variable).  This is for signature verification.

-All of these algorithms are designed to be secure against timing attacks, but not (for example) power analysis.  I also haven't integrated a secure random number generator yet, so you can't actually use this for real cryptography.
+All of these algorithms are designed to be secure against timing attacks, but not (for example) power analysis.  I also haven't integrated a hash function yet, so you can't actually use this for real cryptography.

 As such, the code is only useful as a curiosity for academics and other implementors.

&lt;/pre&gt;
&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mike Hamburg</dc:creator><pubDate>Fri, 21 Feb 2014 19:20:08 -0000</pubDate><guid>https://sourceforge.net2034c3bd3a8454c6a0e0e8c31b5e75a7a9bfc04b</guid></item><item><title>Home modified by Mike Hamburg</title><link>https://sourceforge.net/p/ed448goldilocks/wiki/Home/</link><description>&lt;div class="markdown_content"&gt;&lt;pre&gt;--- v4
+++ v5
@@ -9,17 +9,19 @@

 So Goldilocks will be a good choice only for systems which are intentionally over-engineered.  That said, it is also designed to be as fast as possible for this security level.  It is more than twice as fast as the weaker NIST-P256, as implemented in OpenSSL 1.0.1f, on Intel Sandy Bridge and Haswell.  It's also much faster than NIST-P224 in OpenSSL 1.0.1f, but Emilia Kasper has since greatly improved that curve's implementation.  Goldilocks is slower than Curve25519 and Ed25519 by a factor of about 3.5x.

+Bos, Costello, Longa and Naehrig have just released a [paper](https://research.microsoft.com/apps/pubs/default.aspx?id=209303) (Feb 2014) proposing new curves to replace the NIST ones, with fields on the order of 256, 384 and 512 bits.  Rough calculations suggest that on Sandy Bridge, the Goldilocks field implementation is about as fast as their fastest 384-ish-bit field (382-mont), so that overall variable-base operations on Goldilocks are slower by about 17% (~ 448/384-1).  However Goldilocks has a faster fixed-base implementation (and also uses larger tables), so it's faster at key generation and signing than any of the 384-ish-bit curves in that paper.
+
 I believe that Goldilocks will also support a fast ARM implementation, but I haven't made one yet.  The code I've written so far uses 64x64-&gt;128-bit multiply and accumulate, so it doesn't work on ARM.

 Project status
 --------------
-There's no code here yet, because I'm waiting on Legal approval and export control to post it.
-
 I've mostly implemented:

-* Fixed-base-point scalar multiplication using the "signed comb" algorithm on an isogenous twisted Edwards curve.  This will later be useful for key generation and signing.
-* Variable-base-point scalar multiplication using the Montgomery ladder on an isomorphic Montgomery curve.  This will later be useful for ECDH.
+* Fixed-base-point scalar multiplication using the "signed comb" algorithm on an isogenous twisted Edwards curve.
+* Key generation using the above.
+* Variable-base-point scalar multiplication using the Montgomery ladder on an isomorphic Montgomery curve.  This can be used to compute an ECDH shared secret, except that I haven't incorporated a hash function yet.
 * Variable-base-point scalar multiplication using a fixed 4-bit window on the isogenous Edwards curve.  This is just to check consistency and as a reference for other algorithms, since the Montgomery ladder is faster.
+* Variable-time WNAF double-scalar multiplication (one base fixed, one base variable).  This is for signature verification.

 All of these algorithms are designed to be secure against timing attacks, but not (for example) power analysis.  I also haven't integrated a secure random number generator yet, so you can't actually use this for real cryptography.

@@ -29,11 +31,20 @@
 -----
 This is cryptographic code which originated in the United States, and so is subject to export control.

-This code is provided as-is, with no warranty whatsoever.  It isn't done yet, and it isn't secure yet, so don't use it for anything important.
-
 I work for Cryptography Research, a division of Rambus.  Opinions stated here are my own, and do not necessarily reflect CRI or Rambus policy.

-I am not aware of any patents which apply to this work, though the point compression patent is close enough that you might want to read it carefully.  Likewise, I do not believe that the fixed-base comb patents apply to my comb, but I'm not a lawyer so don't take my word for it.  I'm not planning to file patents on any of the novel components of this work, but I am contractually obligated to help Rambus do so if they want to.
+This code is released under MIT license.  Its copyright is owned by Cryptography Research, Inc, except for crandom, which is owned by Stanford University.  There is no warranty, so use this code at your own risk.  Or better yet, don't use it yet, because it's not done yet, and the API and output formats will probably change.
+
+I am not aware of any patents which apply to this work, though the point compression patent is close enough that you might want to read it carefully.  Likewise, I do not believe that the fixed-base comb patents apply to my comb, but I'm not a lawyer so don't take my word for it.  I'm not planning to file patents on any of the novel components of this work, but I am contractually obligated to help Rambus do so if they want to.  That said, most of the novel components are in my [paper](http://eprint.iacr.org/2012/309) from 2012, so they are safe.
+
+Thanks
+------
+Special thanks to:
+
+* Robert Ransom, for pointing out the efficient Montgomery ladder on the isomorphic curve.
+* Paulo Barreto, Dan Bernstein, Watson Ladd, Tanja Lange, Mark Marson and Trevor Perrin for their helpful feedback and encouragement. 
+* Ben Jun and Dan Boneh, who approved the code for release.
+* Judy Shie and Anne Seymour, who dealt with the legal aspects.

 [[members limit=20]]
 [[download_button]]
&lt;/pre&gt;
&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mike Hamburg</dc:creator><pubDate>Fri, 21 Feb 2014 19:19:35 -0000</pubDate><guid>https://sourceforge.nete2530fa4939acdb00d8a39e6a35c293cc82544a3</guid></item><item><title>Home modified by Mike Hamburg</title><link>https://sourceforge.net/p/ed448goldilocks/wiki/Home/</link><description>&lt;div class="markdown_content"&gt;&lt;pre&gt;--- v3
+++ v4
@@ -1,13 +1,15 @@
 Ed448-Goldilocks
 ================

-This project page is here to host an experimental and partial implementation of cryptography using the Ed448-Goldilocks elliptic curve.
+This project page is here to host an experimental and partial implementation of cryptography using the Ed448-Goldilocks elliptic curve.  This curve is part of the [safecurves project](http://safecurves.cr.yp.to).

 The curve
 ---------
-Goldilocks is a 448-bit Edwards curve.  It is designed for [spinal tap grade security].  The self-deprecating humor there is spot-on.  For practical security concerns, you should use the faster and more mature Curve25519 / Ed25519 software, or similar.  Curve25519's 126-bit security level is strong enough that it will take a huge mathematical breakthrough or a quantum computer to crack it.  A quantum computer would break every elliptic curve, and who knows what a mathematical breakthrough would do?
+Goldilocks is a 448-bit Edwards curve with a 223-bit conjectured security level.  It is designed for [spinal tap grade security](http://silentcircle.wordpress.com/tag/spinal-tap/).  The self-deprecating humor there is spot-on.  For practical security concerns, you should use the faster and more mature Curve25519 / Ed25519 software, or similar.  Curve25519's 126-bit security level is strong enough that it will take a huge mathematical breakthrough or a quantum computer to crack it.  A quantum computer would break every elliptic curve, and who knows what a mathematical breakthrough would do?

-So Goldilocks will be a good choice only for systems which are intentionally over-engineered.  That said, it is also designed to be as fast as possible for this security level.  It is more than twice as fast as the weaker NIST-P256 (as implemented in OpenSSL 1.0.1f) on Intel Sandy Bridge and Haswell.  It's also much faster than NIST-P224 in OpenSSL 1.0.1f, but Emilia Kasper has since greatly improved that curve's implementation.  Goldilocks is slower than Curve25519 and Ed25519 by a factor of about 3.5x.  I believe that Goldilocks will also support a fast ARM implementation, but I haven't made one yet.
+So Goldilocks will be a good choice only for systems which are intentionally over-engineered.  That said, it is also designed to be as fast as possible for this security level.  It is more than twice as fast as the weaker NIST-P256, as implemented in OpenSSL 1.0.1f, on Intel Sandy Bridge and Haswell.  It's also much faster than NIST-P224 in OpenSSL 1.0.1f, but Emilia Kasper has since greatly improved that curve's implementation.  Goldilocks is slower than Curve25519 and Ed25519 by a factor of about 3.5x.
+
+I believe that Goldilocks will also support a fast ARM implementation, but I haven't made one yet.  The code I've written so far uses 64x64-&gt;128-bit multiply and accumulate, so it doesn't work on ARM.

 Project status
 --------------
&lt;/pre&gt;
&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mike Hamburg</dc:creator><pubDate>Fri, 14 Feb 2014 19:48:52 -0000</pubDate><guid>https://sourceforge.net9c660fb79e846bcb42510dc6ad634dad5fd5b617</guid></item><item><title>Home modified by Mike Hamburg</title><link>https://sourceforge.net/p/ed448goldilocks/wiki/Home/</link><description>&lt;div class="markdown_content"&gt;&lt;pre&gt;--- v2
+++ v3
@@ -14,6 +14,7 @@
 There's no code here yet, because I'm waiting on Legal approval and export control to post it.

 I've mostly implemented:
+
 * Fixed-base-point scalar multiplication using the "signed comb" algorithm on an isogenous twisted Edwards curve.  This will later be useful for key generation and signing.
 * Variable-base-point scalar multiplication using the Montgomery ladder on an isomorphic Montgomery curve.  This will later be useful for ECDH.
 * Variable-base-point scalar multiplication using a fixed 4-bit window on the isogenous Edwards curve.  This is just to check consistency and as a reference for other algorithms, since the Montgomery ladder is faster.
&lt;/pre&gt;
&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mike Hamburg</dc:creator><pubDate>Fri, 14 Feb 2014 19:45:01 -0000</pubDate><guid>https://sourceforge.net591b763c60dee773f56d1dac2af504feddc73f51</guid></item><item><title>Home modified by Mike Hamburg</title><link>https://sourceforge.net/p/ed448goldilocks/wiki/Home/</link><description>&lt;div class="markdown_content"&gt;&lt;pre&gt;--- v1
+++ v2
@@ -1,8 +1,36 @@
-Welcome to your wiki!
+Ed448-Goldilocks
+================

-This is the default page, edit it as you see fit. To add a new page simply reference it within brackets, e.g.: [SamplePage].
+This project page is here to host an experimental and partial implementation of cryptography using the Ed448-Goldilocks elliptic curve.

-The wiki uses [Markdown](/p/ed448goldilocks/wiki/markdown_syntax/) syntax.
+The curve
+---------
+Goldilocks is a 448-bit Edwards curve.  It is designed for [spinal tap grade security].  The self-deprecating humor there is spot-on.  For practical security concerns, you should use the faster and more mature Curve25519 / Ed25519 software, or similar.  Curve25519's 126-bit security level is strong enough that it will take a huge mathematical breakthrough or a quantum computer to crack it.  A quantum computer would break every elliptic curve, and who knows what a mathematical breakthrough would do?
+
+So Goldilocks will be a good choice only for systems which are intentionally over-engineered.  That said, it is also designed to be as fast as possible for this security level.  It is more than twice as fast as the weaker NIST-P256 (as implemented in OpenSSL 1.0.1f) on Intel Sandy Bridge and Haswell.  It's also much faster than NIST-P224 in OpenSSL 1.0.1f, but Emilia Kasper has since greatly improved that curve's implementation.  Goldilocks is slower than Curve25519 and Ed25519 by a factor of about 3.5x.  I believe that Goldilocks will also support a fast ARM implementation, but I haven't made one yet.
+
+Project status
+--------------
+There's no code here yet, because I'm waiting on Legal approval and export control to post it.
+
+I've mostly implemented:
+* Fixed-base-point scalar multiplication using the "signed comb" algorithm on an isogenous twisted Edwards curve.  This will later be useful for key generation and signing.
+* Variable-base-point scalar multiplication using the Montgomery ladder on an isomorphic Montgomery curve.  This will later be useful for ECDH.
+* Variable-base-point scalar multiplication using a fixed 4-bit window on the isogenous Edwards curve.  This is just to check consistency and as a reference for other algorithms, since the Montgomery ladder is faster.
+
+All of these algorithms are designed to be secure against timing attacks, but not (for example) power analysis.  I also haven't integrated a secure random number generator yet, so you can't actually use this for real cryptography.
+
+As such, the code is only useful as a curiosity for academics and other implementors.
+
+Legal
+-----
+This is cryptographic code which originated in the United States, and so is subject to export control.
+
+This code is provided as-is, with no warranty whatsoever.  It isn't done yet, and it isn't secure yet, so don't use it for anything important.
+
+I work for Cryptography Research, a division of Rambus.  Opinions stated here are my own, and do not necessarily reflect CRI or Rambus policy.
+
+I am not aware of any patents which apply to this work, though the point compression patent is close enough that you might want to read it carefully.  Likewise, I do not believe that the fixed-base comb patents apply to my comb, but I'm not a lawyer so don't take my word for it.  I'm not planning to file patents on any of the novel components of this work, but I am contractually obligated to help Rambus do so if they want to.

 [[members limit=20]]
 [[download_button]]
&lt;/pre&gt;
&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mike Hamburg</dc:creator><pubDate>Fri, 14 Feb 2014 19:44:33 -0000</pubDate><guid>https://sourceforge.netaf7cebd9130bfa3badffc2f1bad3bc889978865d</guid></item></channel></rss>