mirror of
https://github.com/PurpleI2P/i2pd.git
synced 2025-03-07 06:09:42 +00:00
initial
124
Garlic-Routing-V2.md
Normal file
124
Garlic-Routing-V2.md
Normal file
@@ -0,0 +1,124 @@
|
||||
|
||||
# I2P Tunnel Participant Protocol upgrade #
|
||||
|
||||
# THIS IS A DRAFT #
|
||||
|
||||
Proposal for 4 new i2np message types and 2 new data structures.
|
||||
|
||||
Only applies to tunnel participants, tunnel gateway is unchanged.
|
||||
|
||||
## Data Structures ##
|
||||
|
||||
### BidDiTunnelRequestRecord ###
|
||||
|
||||
Function: replace tunnel request records, add certificates for future protocol expansion
|
||||
|
||||
Encrypted Format:
|
||||
|
||||
224 bytes encrypted data
|
||||
|
||||
Cleartext Format:
|
||||
|
||||
16 bytes truncated sha256 of the router identity of this hop
|
||||
8 bytes big endian integer expiration timestamp as seconds since unix epoch
|
||||
4 bytes big endian integer send tunnel id
|
||||
4 bytes big endian integer recv tunnel id
|
||||
32 bytes sha256 of router identity for send tunnel
|
||||
32 bytes sha256 of router identity for recv tunnel
|
||||
32 bytes chacha20 symmetric key for send tunnel
|
||||
32 bytes chacha20 symmetric key for recv tunnel
|
||||
32 bytes ed25519 public encryption key to encrypt reply to, also used as signing key for revocation
|
||||
i2p certificate (currently NULL, 3 bytes)
|
||||
N bytes random padding such that this record is 224 bytes total
|
||||
|
||||
|
||||
### BiDiTunnelResponseRecord ###
|
||||
|
||||
Function: replace BuildResponseRecord
|
||||
|
||||
Encrypted Format:
|
||||
|
||||
224 bytes encrypted data
|
||||
|
||||
Decrypted Format:
|
||||
|
||||
32 bytes sha256 hash of the next 192 bytes
|
||||
191 bytes random badding
|
||||
1 byte reply, same as from BuildResponseRecord
|
||||
|
||||
## I2NP Messages ##
|
||||
|
||||
### BiDiTunnelBuild ###
|
||||
|
||||
I2NP Type: 29
|
||||
|
||||
Function: request bidirectional tunnel participation, replaces VariableTunnelBuild
|
||||
|
||||
Composed of N encrypted/fake BiDiTunnelResponseRecords
|
||||
|
||||
Format:
|
||||
|
||||
224 * N bytes encrypted data
|
||||
|
||||
Tunnel Participant attempts to decrypt each BiDiTunnelResponseRecord contained.
|
||||
|
||||
This message can contain multiple BiDiTunnelResponseRecords for this participant.
|
||||
|
||||
### BiDiTunnelBuildResult ###
|
||||
|
||||
I2NP Type: 30
|
||||
|
||||
Function: Result of a BiDiTunnelBuild , replaces VariableTunnelBuildReply
|
||||
|
||||
### TunnelCancel ###
|
||||
|
||||
I2NP Type: 31
|
||||
|
||||
Function: Cancel a BiDiTunnel tunnel previously requested.
|
||||
|
||||
Sent from the creator of the tunnel, signed with the revocation key provided in the corresponding BiDiTunnelBuild Message.
|
||||
|
||||
Used to Prematurely revoke tunnel commitment to a tunnel participant.
|
||||
|
||||
Size: >= 96 bytes (32 bytes aligned)
|
||||
|
||||
Format:
|
||||
|
||||
32 bytes sha265 of router identity for send tunnel
|
||||
32 bytes sha256 of router identity for recv tunnel
|
||||
4 bytes big endian integer send tunnel id
|
||||
4 bytes big endian integer recv tunnel id
|
||||
i2p certificate (currently NULL, 3 bytes)
|
||||
N bytes random padding such that message is 32 bytes aligned
|
||||
32 bytes ed25519 signature of bytes before start of signature
|
||||
|
||||
Note: no limits are imposed on this message's padding other than the resulting message must be 32 bytes aligned and is less than 65536 bytes, the limit imposed by I2NP.
|
||||
|
||||
### BidiTunnelData ###
|
||||
|
||||
I2NP Type: 32
|
||||
|
||||
Function: TunnelDataMessage for bidirectional tunnels
|
||||
|
||||
Size: 2048 bytes
|
||||
|
||||
Format:
|
||||
|
||||
16 bytes poly1305 mac
|
||||
8 bytes nonce
|
||||
4 bytes send tunnel id
|
||||
4 bytes recv tunnel id
|
||||
2016 bytes payload
|
||||
|
||||
|
||||
## Justification
|
||||
|
||||
* i2p's tunnel crypto lacks mac, possible tagging attack
|
||||
|
||||
* elgamal is too slow, possible DoS attack
|
||||
|
||||
* chacha20poly1305 is fast
|
||||
|
||||
* as of 2016 most of the network supports ed25519
|
||||
|
||||
* 32 bytes aligned implies 16 bytes aligned, messages are aligned in memory such that performance boosts can be achieved.
|
||||
Reference in New Issue
Block a user