<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Apr 7, 2017, at 5:06 PM, Tony Arcieri <<a href="mailto:bascule@gmail.com">bascule@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 7, 2017 at 4:57 PM, Ron Garret <span dir="ltr"><<a href="mailto:ron@flownet.com" target="_blank">ron@flownet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Not really. What appears to be a 64 byte secret key is actually a 32-byte secret key concatenated with the corresponding 32-byte public key.</blockquote><div><br></div><div>Oleg is describing the original NaCl API (as in <a href="https://nacl.cr.yp.to/">https://nacl.cr.yp.to/</a>), not the API provided by the ref10 implementation (which has proliferated from SUPERCOP). My understanding is this version has various incompatibilities and security issues versus ref10.</div></div><div><br></div><div>This version uses a 64-bit secret key (sk) alongside a 32-bit public key. See Brian Warner's writeup which Oleg linked for more information.</div><div><br></div><div>Here is the original key generation code from NaCl (2011), which fills a 64-byte secret key buffer with 32-bytes of randomness before expanding it into 64-bytes using SHA-512. Note it also "pre-clamps" the secret scalar:</div><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><font face="monospace, monospace">int crypto_sign_keypair(</font></div><div class="gmail_extra"><font face="monospace, monospace"> unsigned char *pk,</font></div><div class="gmail_extra"><font face="monospace, monospace"> unsigned char *sk</font></div><div class="gmail_extra"><font face="monospace, monospace"> )</font></div><div class="gmail_extra"><font face="monospace, monospace">{</font></div><div class="gmail_extra"><font face="monospace, monospace"> sc25519 scsk;</font></div><div class="gmail_extra"><font face="monospace, monospace"> ge25519 gepk;</font></div><div class="gmail_extra"><font face="monospace, monospace"><br></font></div><div class="gmail_extra"><font face="monospace, monospace"> randombytes(sk, 32);</font></div><div class="gmail_extra"><font face="monospace, monospace"> crypto_hash_sha512(sk, sk, 32);</font></div><div class="gmail_extra"><font face="monospace, monospace"> sk[0] &= 248;</font></div><div class="gmail_extra"><font face="monospace, monospace"> sk[31] &= 127;</font></div><div class="gmail_extra"><font face="monospace, monospace"> sk[31] |= 64;</font></div><div class="gmail_extra"><font face="monospace, monospace"><br></font></div><div class="gmail_extra"><font face="monospace, monospace"> sc25519_from32bytes(&scsk,sk);</font></div><div class="gmail_extra"><font face="monospace, monospace"><br></font></div><div class="gmail_extra"><font face="monospace, monospace"> ge25519_scalarmult_base(&gepk, &scsk);</font></div><div class="gmail_extra"><font face="monospace, monospace"> ge25519_pack(pk, &gepk);</font></div><div class="gmail_extra"><font face="monospace, monospace"> return 0;</font></div><div class="gmail_extra"><font face="monospace, monospace">}</font></div></blockquote></div>
</blockquote><br></div><div>Ah.</div><div><br></div><div>I’m using TweetNaCl which I had assumed had the same API as NaCl. But it doesn’t. TweetNacl does this:</div><div><br></div><div><pre style="word-wrap: break-word; white-space: pre-wrap;">int crypto_sign_keypair(u8 *pk, u8 *sk)
{
u8 d[64];
gf p[4];
int i;
randombytes(sk, 32);
crypto_hash(d, sk, 32);
d[0] &= 248;
d[31] &= 127;
d[31] |= 64;
scalarbase(p,d);
pack(pk,p);
FOR(i,32) sk[32 + i] = pk[i];
return 0;
}</pre><div><br></div><div><br></div></div><br></body></html>