I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

notes on LS2 key order

Browse Source 
was in prop. 123 but didn't get copied to the spec

fix key length
This commit is contained in:
zzz
2025-04-21 14:33:09 -04:00
parent b97fd5aedf
commit 8cfae06ab2
1 changed files with 21 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
i2p2www/spec/common-structures.rst
View File

@ -1252,7 +1252,7 @@ by the Destination_'s SigningPrivateKey_ or the transient key.
length -> 2 bytes
encryption_key :: `PublicKey`
length -> 256 bytes
length -> keylen bytes
num :: `Integer`
length -> 1 byte
@ -1269,6 +1269,26 @@ by the Destination_'s SigningPrivateKey_ or the transient key.
{% endhighlight %}
Encryption Key Preference
`````````````````````````
For published (server) leasesets, the encryption keys are in order of server preference,
most-preferred first. If clients support more than one encryption type, it is recommended
that they honor the server preference and select the first supported type as the
encryption method to use to connect to the server.
Generally, the newer (higher-numbered) key types are more secure or efficient and
are preferred, so the keys should be listed in reverse order of key type.
However, clients may, implementation-dependent, select based on their preference instead,
or use some method to determine the "combined" preference. This may be useful as
a configuration option, or for debugging.
The key order in unpublished (client) leasesets effectively does not matter, because
connections will usually not be attempted to unpublished clients.
Unless this order is used to determine a combined preference, as described above.
Options
```````
As of API 0.9.66, a standard format for service record options