minor fixes

i2p2www/spec/encryptedleaseset.rst

@@ -326,7 +326,7 @@ Definitions
 B
     The Ed25519 base point (generator) 2^255 - 19 as in [ED25519-REFS]_
 
-l
+L
     The Ed25519 order 2^252 + 27742317777372353535851937790883648493
     as in [ED25519-REFS]_
 
@@ -384,7 +384,7 @@ GENERATE_ALPHA(destination, date, secret), for all parties:
   secret = UTF-8 encoded string
   seed = HKDF(H("I2PGenerateAlpha", keydata), datestring || secret, "i2pblinding1", 64)
   // treat seed as a 64 byte little-endian value
-  alpha = seed mod l
+  alpha = seed mod L
 {% endhighlight %}
 
 BLIND_PRIVKEY(), for the owner publishing the leaseset:
@@ -395,7 +395,7 @@ BLIND_PRIVKEY(), for the owner publishing the leaseset:
 alpha = GENERATE_ALPHA(destination, date, secret)
   a = destination's signing private key
   // Addition using scalar arithmentic
-  blinded signing private key = a' = BLIND_PRIVKEY(a, alpha) = (a + alpha) mod l
+  blinded signing private key = a' = BLIND_PRIVKEY(a, alpha) = (a + alpha) mod L
   blinded signing public key = A' = DERIVE_PUBLIC(a')
 {% endhighlight %}
 
@@ -438,11 +438,11 @@ The outer portion of the encrypted leaseset uses Red25519 keys and signatures.
 
 Red25519 is similar to Ed25519. There are two differences:
 
-Red25519 private keys are generated from random numbers and then must be reduced mod l, where l is defined above.
+Red25519 private keys are generated from random numbers and then must be reduced mod L, where L is defined above.
 Ed25519 private keys are generated from random numbers and then "clamped" using
 bitwise masking to bytes 0 and 31. This is not done for Red25519.
 The functions GENERATE_ALPHA() and BLIND_PRIVKEY() defined above generate proper
-Red25519 private keys using mod l.
+Red25519 private keys using mod L.
 
 In Red25519, the calculation of r for signing uses additional random data,
 and uses the public key value rather than the hash of the private key.

i2p2www/spec/proposals/123-new-netdb-entries.rst

@@ -5,7 +5,7 @@ New netDB Entries
     :author: zzz, str4d, orignal
     :created: 2016-01-16
     :thread: http://zzz.i2p/topics/2051
-    :lastupdated: 2019-03-12
+    :lastupdated: 2019-03-13
     :status: Open
     :supercedes: 110, 120, 121, 122
 
@@ -46,6 +46,8 @@ The following proposals are somewhat related:
 - 142 New Crypto Template (for new symmetric crypto)
 - 144 ECIES-X25519-AEAD-Ratchet
 - 145 ECIES-P256
+- 146 Red25519
+- 148 EdDSA-BLAKE2b-Ed25519
 
 
 Proposal
@@ -761,7 +763,7 @@ Definitions
 B
     The Ed25519 base point (generator) 2^255 - 19 as in [ED25519-REFS]_
 
-l
+L
     The Ed25519 order 2^252 + 27742317777372353535851937790883648493
     as in [ED25519-REFS]_
 
@@ -820,7 +822,7 @@ GENERATE_ALPHA(destination, date, secret), for all parties:
   secret = UTF-8 encoded string
   seed = HKDF(H("I2PGenerateAlpha", keydata), datestring || secret, "i2pblinding1", 64)
   // treat seed as a 64 byte little-endian value
-  alpha = seed mod l
+  alpha = seed mod L
 {% endhighlight %}
 
 BLIND_PRIVKEY(), for the owner publishing the leaseset:
@@ -833,7 +835,7 @@ BLIND_PRIVKEY(), for the owner publishing the leaseset:
   alpha = GENERATE_ALPHA(destination, date, secret)
   a = destination's signing private key
   // Addition using scalar arithmentic
-  blinded signing private key = a' = BLIND_PRIVKEY(a, alpha) = (a + alpha) mod l
+  blinded signing private key = a' = BLIND_PRIVKEY(a, alpha) = (a + alpha) mod L
   blinded signing public key = A' = DERIVE_PUBLIC(a')
 {% endhighlight %}
 
@@ -879,11 +881,11 @@ The outer portion of the encrypted leaseset uses Red25519 keys and signatures.
 
 Red25519 is almost identical to Ed25519. There are two differences:
 
-Red25519 private keys are generated from random numbers and then must be reduced mod l, where l is defined above.
+Red25519 private keys are generated from random numbers and then must be reduced mod L, where L is defined above.
 Ed25519 private keys are generated from random numbers and then "clamped" using
 bitwise masking to bytes 0 and 31. This is not done for Red25519.
 The functions GENERATE_ALPHA() and BLIND_PRIVKEY() defined above generate proper
-Red25519 private keys using mod l.
+Red25519 private keys using mod L.
 
 In Red25519, the calculation of r for signing uses additional random data,
 and uses the public key value rather than the hash of the private key.

i2p2www/spec/proposals/148-eddsa-blake2b-ed25519.rst

@@ -5,7 +5,7 @@ EdDSA-BLAKE2b-Ed25519
     :author: zzz
     :created: 2019-03-12
     :thread: http://zzz.i2p/topics/2689
-    :lastupdated: 2019-03-12
+    :lastupdated: 2019-03-13
     :status: Open
 
 .. contents::
@@ -26,7 +26,7 @@ Motivation
 During discussions and design of NTCP2 (proposal 111) and LS2 (proposal 123),
 we briefly considered various attacks that were possible, and how to
 prevent them. Three of these attacks are Length Extension Attacks,
-Reuse of Signed Data, and Dupicate Message Identification.
+Reuse of Signed Data, and Duplicate Message Identification.
 
 For both NTCP2 and LS2, we decided that
 these attacks were not directly relevant to the proposals at hand,