New proposal 161
This commit is contained in:
zzz
307
i2p2www/spec/proposals/161-ri-dest-padding.rst
Normal file
307
i2p2www/spec/proposals/161-ri-dest-padding.rst
Normal file
@ -0,0 +1,307 @@
|
|||||||
|
========================================
|
||||||
|
RI and Destination Padding
|
||||||
|
========================================
|
||||||
|
.. meta::
|
||||||
|
:author: zzz
|
||||||
|
:created: 2022-09-28
|
||||||
|
:thread: http://zzz.i2p/topics/3279
|
||||||
|
:lastupdated: 2022-09-28
|
||||||
|
:status: Open
|
||||||
|
:target: 0.9.57
|
||||||
|
|
||||||
|
.. contents::
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Overview
|
||||||
|
========
|
||||||
|
|
||||||
|
|
||||||
|
Summary
|
||||||
|
-------
|
||||||
|
|
||||||
|
The ElGamal public key in Destinations has been unused since release 0.6 (2005).
|
||||||
|
While our specifications do say that it is unused, they do NOT say that implementations can avoid
|
||||||
|
generating an ElGamal key pair and simply fill the field with random data.
|
||||||
|
|
||||||
|
We propose changing the specifications to say that
|
||||||
|
the field is ignored and that implementations MAY fill the field with random data.
|
||||||
|
This change is backward-compatible. There is no known implementation that validates
|
||||||
|
the ElGamal public key.
|
||||||
|
|
||||||
|
Additionally, this proposal offers guidance to implementers on how to generate the
|
||||||
|
random data for Destination AND Router Identity padding so that it is compressible while
|
||||||
|
still being secure, and without having Base 64 representations appear to be corrupt or insecure.
|
||||||
|
This provides most of the benefits of removing the padding fields without any
|
||||||
|
disruptive protocol changes.
|
||||||
|
Compressible Destinations reduces streaming SYN and repliable datagram size;
|
||||||
|
compressible Router Identities reduce Database Store Messages, SSU2 Session Confirmed messages,
|
||||||
|
and reseed su3 files.
|
||||||
|
|
||||||
|
Finally, the proposal discusses possibilities for new Destination and Router Identity formats
|
||||||
|
that would eliminate the padding altogether. There is also a brief discussion of post-quantum
|
||||||
|
crypto and how that may affect future planning.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Goals
|
||||||
|
-----
|
||||||
|
|
||||||
|
- Eliminate requirement to generate ElGamal keypair for Destinations
|
||||||
|
- Recommend best practices so Destinations and Router Identities are highly compressible,
|
||||||
|
yet do not display obvious patterns in Base 64 representations.
|
||||||
|
- Encourage adoption of best practices by all implementations so
|
||||||
|
the fields are not distinguishable
|
||||||
|
- Reduce streaming SYN size
|
||||||
|
- Reduce repliable datagram size
|
||||||
|
- Reduce SSU2 RI block size
|
||||||
|
- Reduce SSU2 Session Confirmed size and fragmentation frequency
|
||||||
|
- Reduce Database Store Message (with RI) size
|
||||||
|
- Reduce reseed file size
|
||||||
|
- Maintain compatibility in all protocols and APIs
|
||||||
|
- Update specifications
|
||||||
|
- Discuss alternatives for new Destination and Router Identity formats
|
||||||
|
|
||||||
|
By eliminating the requirement to generate ElGamal keys, implementations may
|
||||||
|
be able to completely remove ElGamal code, subject to backward-compatibility considerations
|
||||||
|
in other protocols.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Design
|
||||||
|
======
|
||||||
|
|
||||||
|
Strictly speaking, the 32-byte signing public key alone (in both Destinations and Router Identities)
|
||||||
|
and the 32-byte encryption public key (in Router Identities only) is a random number
|
||||||
|
that provides all the entropy necessary for the SHA-256 hashes of these structures
|
||||||
|
to be cryptographically strong and randomly distributed in the network database DHT.
|
||||||
|
|
||||||
|
However, out of an abundance of caution, we recommend a minimum of 32 bytes of random data
|
||||||
|
be used in the ElG public key field and padding. Additionally, if the fields were all zeros,
|
||||||
|
Base 64 destinations would contain long runs of AAAA characters, which may cause alarm
|
||||||
|
or confusion to users.
|
||||||
|
|
||||||
|
For Ed25519 signature type and X25519 encryption type:
|
||||||
|
Destinations will contain 11 copies (352 bytes) of the random data.
|
||||||
|
Router Identities will contain 10 copies (320 bytes) of the random data.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Estimated Savings
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
Destinations are included in every streaming SYN [Streaming]_
|
||||||
|
and repliable datagram [Datagram]_.
|
||||||
|
Router Infos (containing Router Identities) are included in Database Store Messages [I2NP]_
|
||||||
|
and in the Session Confirmed messages in [NTCP2]_ and [SSU2]_.
|
||||||
|
|
||||||
|
NTCP2 does not compress the Router Info.
|
||||||
|
RIs in Database Store Messages and SSU2 Session Confirmed messages are gzipped.
|
||||||
|
Router Infos are zipped in reseed SU3 files.
|
||||||
|
|
||||||
|
Destinations in Database Store Messages are not compressed.
|
||||||
|
Streaming SYN messages are gzipped at the I2CP layer.
|
||||||
|
|
||||||
|
For Ed25519 signature type and X25519 encryption type,
|
||||||
|
estimated savings:
|
||||||
|
|
||||||
|
=============== =========== ============= ==================== ================== =========== =============
|
||||||
|
Data Type Total Size Keys and Cert Uncompressed Padding Compressed Padding Size Savings
|
||||||
|
=============== =========== ============= ==================== ================== =========== =============
|
||||||
|
Destination 391 39 352 32 71 320 bytes (82%)
|
||||||
|
Router Identity 391 71 320 32 103 288 bytes (74%)
|
||||||
|
Router Info 1000 typ. 71 320 32 722 typ. 288 bytes (29%)
|
||||||
|
=============== =========== ============= ==================== ================== =========== =============
|
||||||
|
|
||||||
|
Notes: Assumes 7-byte certificate is not compressible, zero additional gzip overhead.
|
||||||
|
Neither is true, but effects will be small.
|
||||||
|
Ignores other compressible parts of the Router Info.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Specification
|
||||||
|
=============
|
||||||
|
|
||||||
|
Proposed changes to our current specifications are documented below.
|
||||||
|
|
||||||
|
|
||||||
|
Common Structures
|
||||||
|
------------------
|
||||||
|
Change the common structures specification [COMMON]_
|
||||||
|
to specify that the 256-byte Destination public key field is ignored and may
|
||||||
|
contain random data.
|
||||||
|
|
||||||
|
Add a section to the common structures specification [COMMON]_
|
||||||
|
recommending best practice for the Destination public key field and the
|
||||||
|
padding fields in the Destination and Router Identity, as follows:
|
||||||
|
|
||||||
|
Generate 32 bytes of random data using a strong cryptographic pseudo-random number generator (PRNG)
|
||||||
|
and repeat those 32 bytes as necessary to fill the public key field (for Destinations)
|
||||||
|
and the padding field (for Destinations and Router Identities).
|
||||||
|
|
||||||
|
Private Key File
|
||||||
|
--------------------
|
||||||
|
The private key file (eepPriv.dat) format is not an official part of our specifications
|
||||||
|
but it is documented in the Java I2P javadocs [PKF]_
|
||||||
|
and other implementations do support it.
|
||||||
|
This enables portability of private keys to different implementations.
|
||||||
|
Add a note to that javadoc that the encryption public key may be random padding
|
||||||
|
and the encryption private key may be all zeros or random data.
|
||||||
|
|
||||||
|
SAM
|
||||||
|
------
|
||||||
|
Note in [SAM]_ that the encryption private key is unused and may be ignored.
|
||||||
|
Any random data may be returned by the client.
|
||||||
|
The SAM Bridge may send random data on creation (with DEST GENERATE or SESSION CREATE DESTINATION=TRANSIENT)
|
||||||
|
rather than all zeros, so the Base 64 representation does not have a string of AAAA characters
|
||||||
|
and look broken.
|
||||||
|
|
||||||
|
|
||||||
|
I2CP
|
||||||
|
------
|
||||||
|
No changes required to [I2CP]_. The private key for the encryption public key in the Destination
|
||||||
|
is not sent to the router.
|
||||||
|
|
||||||
|
|
||||||
|
Future Planning
|
||||||
|
==================
|
||||||
|
|
||||||
|
|
||||||
|
Protocol Changes
|
||||||
|
------------------
|
||||||
|
|
||||||
|
At a cost of protocol changes and a lack of backward compatibility, we could
|
||||||
|
change our protocols and specifications to eliminate the padding field in
|
||||||
|
the Destination, Router Identity, or both.
|
||||||
|
|
||||||
|
This proposal bears some similarity to the "b33" encrypted leaseset format,
|
||||||
|
containing only a key and a type field.
|
||||||
|
|
||||||
|
To maintain some compatibility, certain protocol layers could "expand" the padding field
|
||||||
|
with all zeros to present to other protocol layers.
|
||||||
|
|
||||||
|
For Destinations, we could also remove the encryption type field in the key certificate,
|
||||||
|
at a savings of two bytes.
|
||||||
|
Alternatively, Destinations could get a new encryption type in the key certificate,
|
||||||
|
indicating a zero public key (and padding).
|
||||||
|
|
||||||
|
If compatibility conversion between old and new formats is not included at some protocol layer,
|
||||||
|
the following specifications, APIs, protocols, and applications would be affected:
|
||||||
|
|
||||||
|
- Common structures spec
|
||||||
|
- I2NP
|
||||||
|
- I2CP
|
||||||
|
- NTCP2
|
||||||
|
- SSU2
|
||||||
|
- Ratchet
|
||||||
|
- Streaming
|
||||||
|
- SAM
|
||||||
|
- Bittorrent
|
||||||
|
- Reseeding
|
||||||
|
- Private Key File
|
||||||
|
- Java core and router API
|
||||||
|
- i2pd API
|
||||||
|
- Third-party SAM libraries
|
||||||
|
- Bundled and third-party tools
|
||||||
|
- Several Java plugins
|
||||||
|
- User interfaces
|
||||||
|
- P2P applications e.g. MuWire, bitcoin, monero
|
||||||
|
- hosts.txt, addressbook, and subscriptions
|
||||||
|
|
||||||
|
If conversion is specified at some layer, the list would be reduced.
|
||||||
|
|
||||||
|
The costs and benefits of these changes are not clear.
|
||||||
|
|
||||||
|
Specific proposals TBD:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
PQ Keys
|
||||||
|
------------------
|
||||||
|
|
||||||
|
Post-Quantum (PQ) encryption public keys, for any anticipated algorithm,
|
||||||
|
are larger than 256 bytes. This would eliminate any padding and any savings from proposed
|
||||||
|
changes above, for Router Identities.
|
||||||
|
|
||||||
|
In a "hybrid" PQ approach, like what SSL is doing, the PQ keys would be ephemeral only,
|
||||||
|
and would not appear in the Router Identity.
|
||||||
|
|
||||||
|
PQ signing keys are not viable,
|
||||||
|
and Destinations do not contain encryption public keys.
|
||||||
|
Static keys for ratchet are in the Lease Set, not the Destination.
|
||||||
|
so we may eliminate Destinations from the following discussion.
|
||||||
|
|
||||||
|
So PQ only affects Router Infos, and only for PQ static (not ephemeral) keys, not for PQ hybrid.
|
||||||
|
This would be for a new encryption type and would affect NTCP2, SSU2, and
|
||||||
|
encrypted Database Lookup Messages and replies.
|
||||||
|
Estimated time frame for design, development, and rollout of that would be ????????
|
||||||
|
But would be after hybrid or ratchet ????????????
|
||||||
|
|
||||||
|
For further discussion see [PQ]_.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Issues
|
||||||
|
======
|
||||||
|
|
||||||
|
It may be desirable to rekey the network at a slow rate, to provide cover for new routers.
|
||||||
|
"Rekeying" could mean simply changing the padding, not really changing the keys.
|
||||||
|
|
||||||
|
It is not possible to rekey existing Destinations.
|
||||||
|
|
||||||
|
Should Router Identities with padding in the public key field be identified with a different
|
||||||
|
encryption type in the key certificate? This would cause compatibility issues.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Migration
|
||||||
|
=========
|
||||||
|
|
||||||
|
No backward compatibility issues for replacing the ElGamal key with padding.
|
||||||
|
|
||||||
|
Rekeying, if implemented, would be similar to that done
|
||||||
|
in three previous router identity transitions:
|
||||||
|
From DSA-SHA1 to ECDSA signatures, then to
|
||||||
|
EdDSA signatures, then to X25519 encryption.
|
||||||
|
|
||||||
|
Subject to backward compatibility issues, and after disabling SSU,
|
||||||
|
implementations may remove ElGamal code completely.
|
||||||
|
Approximately 14% of routers in the network are ElGamal encryption type, including many floodfills.
|
||||||
|
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
.. [Common]
|
||||||
|
{{ spec_url('common-structures') }}
|
||||||
|
|
||||||
|
.. [Datagram]
|
||||||
|
{{ spec_url('datagrams') }}
|
||||||
|
|
||||||
|
.. [I2CP]
|
||||||
|
{{ spec_url('i2cp') }}
|
||||||
|
|
||||||
|
.. [I2NP]
|
||||||
|
{{ spec_url('i2np') }}
|
||||||
|
|
||||||
|
.. [NTCP2]
|
||||||
|
{{ spec_url('ntcp2') }}
|
||||||
|
|
||||||
|
.. [PKF]
|
||||||
|
http://{{ i2pconv('idk.i2p/javadoc-i2p') }}/net/i2p/data/PrivateKeyFile.html
|
||||||
|
|
||||||
|
.. [PQ]
|
||||||
|
http://zzz.i2p/topics/3294
|
||||||
|
|
||||||
|
.. [SAM]
|
||||||
|
{{ site_url('docs/api/samv3') }}
|
||||||
|
|
||||||
|
.. [SSU2]
|
||||||
|
{{ spec_url('ssu2') }}
|
||||||
|
|
||||||
|
.. [Streaming]
|
||||||
|
{{ spec_url('streaming') }}
|
||||||
Reference in New Issue
Block a user