Document why signature in SSU SessionCreated msg is encrypted #37
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Opened 5 years ago
Last modified 5 years ago
#1849newenhancement
Document why signature in SSU SessionCreated msg is encrypted
Reported by:zzzOwned by:
Priority:
minor
Milestone:
eventually
Component:
www/i2p
Version:
0.9.26
Keywords:
Cc:
Parent Tickets:
Sensitive:
no
Description
Add to the SSU overview and/or spec.
Also research in java code, mtn commits, and 10-year-old meeting logs, status notes, and emails for additional info.
zzz: Ah, I found out why we need to encrypt the signature
or at least why we do it
zzz: An attacker could substitute the signature with their own signature, and hence claim to have sent the message
zzz: But it does not seems to be applicable to I2P, because both parties know each others RI and hence public keys
EinMByte> zzz: It all comes down to whether or not it is feasible for an attacker to intercept the DatabaseStoreMessage?, and substitute it with their own
But maybe it's a good idea to keep the encryption there anyway, just in case that is probably
For sure, there MUST be a note on there
s/there/that
Subtickets
comment:2 Changed 5 years ago by EinMByte
I'd like to make a correction to the above post: only the initiator (Alice) already knows the RI of the other party (Bob), so it is required after all that Alice encrypts her signature.
It is not true (as I mistakenly assumed) that Bob knows Alice's router hash.
So the attack described above would work in the I2P context (if we didn't encrypt signatures), since Mallory can just recreate the signature with his own router hash included (in the scenario of the above post it isn't included at all).
By making Alice encrypt her signature such an attack cannot work:
comment:1 Changed 5 years ago by EinMByte
More information regarding this attack, and also why it is a good idea to sign both X and Y for both parties can be found in Diffie, W.; van Oorschot P. C.; Wiener M. J., Authentication and Authenticated Key Exchanges. (section 5.1).
To elaborate on the above: it seems like the attack is mainly applicable when certificates (issued by a trusted third party) are used to exchange public keys.
In the I2P context, a peer always attempts to connect to a particular router hash (a router is its RI), so it is not possible to substitute the certificate at all. Importantly, this identity information is included in the exchanged signatures.
I think this consideration also rules out the possibility of unknown key-share attacks to which the protocol might otherwise be vulnerable. The appropriate reference here is Blake-Wilson, S.: Menzes, A., Unknown Key-Share Attacks on the Station-to-Station (STS) Protocol.
For STS-ENC (close to our transport protocols), two attacks are described there
Public key substitution: the attacker is able to register the public key of one of both parties as their own. This is not possible in the I2P context.
An attack based on the assumption that an attacker is able to create an (invalid) RI such that the signature by Alice is also valid for that RI. Such an attack on the ElGamal? signature system (with freely chosen and unchecked parameters) is discussed in that paper, but it is not very practical (and doesn't apply at all to I2P).
So it looks like we don't need the encryption as long as the identity information is being included in the signatures. If this was not the case, consider the following attack
Bob shares a key with Alice, but in fact thinks this key is shared with Mallory (unknown key-share attack against the responder).
Even using this weak version of the protocol, you cannot trick the initiator in the same way, because Alice knows that she wants to talk to Bob, and will only accept his signature.
Last edited 5 years ago
by EinMByte
( previous)
( diff)