Jonas Schnelli [ARCHIVE] on Nostr: đź“… Original date posted:2018-09-07 đź“ť Original message:Hi Tim Thanks for the ...
đź“… Original date posted:2018-09-07
đź“ť Original message:Hi Tim
Thanks for the feedback.
I agree with all of Gregs answers.
> key. Together with the encrypted packet lengths, the entire data stream looks like random then,
> which is pretty useful against censorship resistance for example. (The only exception is that the
> stream will never start with the magic bytes.)
All-or-none censorship attacks are out of scope for BIP151.
We won’t achieve DPI robustness in this proposal and I think it should not be part of the p2p protocol.
I think all-or-one censorship situations require an additional layer like TOR with OBFS4 (where AFAIK Eligator is used).
Eventually Core does directly support non-tor routed pluggable transports (it's partially already possible via SOCK proxy, but not on a gossip and plugin-launch level).
This does not exclude that we should obfuscate the key exchange as good as we can without blowing up the implementation too much.
The proposed encryption adds a robustness to the thread model with very little costs and low risks.
> "salt = BitcoinSharedSecret||INITIATOR_PUBKEY||RESPONDER_PUBKEY" should just avoid this issue.
This is a good point and I’d like to see more concrete examples how this (the non dynamic salt) could be exploited.
> Re-keying
> =========
> The problem with signalling re-keying in the length field is that the length field is not covered
> by the MAC. So the attacker can flip the signalling bit. The resulting protocol is probably still
> secure but the malleability is certainly not desirable.
In ChaCha20Poly1305 at openssh, the length field is AAD, encrypted with a different key and part of the MAC.
>
> Deterministic rekeying rules may be better. Otherwise there will be implementations that rekey
> every 10 seconds and implementations that just don't rekey at all (rendering the 10 s rekeying
> interval in the opposite direction useless). Different policies also make it possible to
> fingerprint implementations. Another problem is that people will set their policies arbitrarily.
> What's better: 5 min or 30 min? I don't know, but both are reasonable choices. (Thats's very much
> like discussions about ciphers... What's better AES-GCM or ChaCha20/Poly1305? I don't know, but
> again both are reasonable choices.)
The Rekey cost is two times a double-SHA256,… the costs of a rekey is similar to one or two v1 INV message creations.
>
> Symmetric crypto
> ================
> You call it chacha20-poly1305 at bitcoin but what's the difference to the openssh then? Is the
> idea to save a call to chacha here as you mentioned?
>
> I didn't think about this in detail: maybe there are a few meaningful cases where padding could
> hide the message length without too much overhead. (I'm not convinced, just a random thought.)
I think a new message type that could contain message + pad would be trivial.
Would this again be to obfuscate traffic patterns? Anti DPI is not the scope of BIP151.
>
> Misc
> ====
> "The ID/string mapping is a peer to peer arrangement and MAY be negotiated between the
> requesting and responding peer." I think that's overly complicated. I suggest it should just be
> written in stone, again to avoid complexity and to avoid fingerprinting. New implementations are
> necessary anyway, so maybe just use IDs for anything? ASCII is nice if you want to debug your code
> or some random network failure but that's hard anyway when encryption is used.
I wanted to avoid too much central planing here and only cover the ones where it's most efficient (small messages that are used often).
The ASCII commands are in itself somehow pseude-robust against collision.
For a 1MB block message, using a 1-byte short ID (rather then a 6-byte ASCII command) would reduce the bandwidth requirement insignificant (99.99952%).
If we would always have used short IDs in the past, there could have been a collision between XTIN, compact, sendheaders or so.
>
> In general, the entire thing is a little bit underspecified. (I'm aware it's just a draft.)
> A few examples:
> - What should a peer do if the MAC verification fails?
> - What should a peer do if it receives an even key?
> - "Processing the message before the authentication succeeds (MAC verified) MUST not be done."
> That should also apply to the ciphertext. (Or: What is a "message"?). It may be a good idea to
> to refer to the openssh document or steal from it; it does a pretty good job.
> - "Both peers MUST keep track of the message sequence number (uint32) of sent and received
> messages for building a 64-bit symmetric cipher IV." I think you mean nonce when you say IV?
> - What is the initial value of the sequence number?
Good points. Will make them more clear in the BIP.
I was under the false impression that it is obvious to disconnect in those cases.
> - How is a 64-bit nonce formed from one (two?) uint32?
That’s specified in ChaCha20Poly1305 at openssh ("a nonce consisting of the packet sequence number encoded as a uint64“).
But I’ll specified that more clear.
> - What if the uint32 overflows?
The max data before rekey is 1GB, AFAIK it is impossible to overflow.
> - "Re-Keying interval is a peer policy with a minimum timespan of 10 seconds." What if I receive
> too many re-keying requests? Nothing or should I raise the DoS score?
Current implementation proposal does a disconnect. With the risk of fingerprinting options, I think we can leave this open to the implementation?
> - "The Re-Keying must be done after every 1GB of data sent or received" Hm, every peer updates its
> own sending key, so this should just read "sent" instead of "sent or received“?
Yes. Should probably be „sent“,… and eventually a paragraph that states that a peer should disconnect if the remote peer did not rekey within that limit.
> Pseudocode could probably help here.
Agree. Will try to add.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180907/348e23e8/attachment.sig>;
đź“ť Original message:Hi Tim
Thanks for the feedback.
I agree with all of Gregs answers.
> key. Together with the encrypted packet lengths, the entire data stream looks like random then,
> which is pretty useful against censorship resistance for example. (The only exception is that the
> stream will never start with the magic bytes.)
All-or-none censorship attacks are out of scope for BIP151.
We won’t achieve DPI robustness in this proposal and I think it should not be part of the p2p protocol.
I think all-or-one censorship situations require an additional layer like TOR with OBFS4 (where AFAIK Eligator is used).
Eventually Core does directly support non-tor routed pluggable transports (it's partially already possible via SOCK proxy, but not on a gossip and plugin-launch level).
This does not exclude that we should obfuscate the key exchange as good as we can without blowing up the implementation too much.
The proposed encryption adds a robustness to the thread model with very little costs and low risks.
> "salt = BitcoinSharedSecret||INITIATOR_PUBKEY||RESPONDER_PUBKEY" should just avoid this issue.
This is a good point and I’d like to see more concrete examples how this (the non dynamic salt) could be exploited.
> Re-keying
> =========
> The problem with signalling re-keying in the length field is that the length field is not covered
> by the MAC. So the attacker can flip the signalling bit. The resulting protocol is probably still
> secure but the malleability is certainly not desirable.
In ChaCha20Poly1305 at openssh, the length field is AAD, encrypted with a different key and part of the MAC.
>
> Deterministic rekeying rules may be better. Otherwise there will be implementations that rekey
> every 10 seconds and implementations that just don't rekey at all (rendering the 10 s rekeying
> interval in the opposite direction useless). Different policies also make it possible to
> fingerprint implementations. Another problem is that people will set their policies arbitrarily.
> What's better: 5 min or 30 min? I don't know, but both are reasonable choices. (Thats's very much
> like discussions about ciphers... What's better AES-GCM or ChaCha20/Poly1305? I don't know, but
> again both are reasonable choices.)
The Rekey cost is two times a double-SHA256,… the costs of a rekey is similar to one or two v1 INV message creations.
>
> Symmetric crypto
> ================
> You call it chacha20-poly1305 at bitcoin but what's the difference to the openssh then? Is the
> idea to save a call to chacha here as you mentioned?
>
> I didn't think about this in detail: maybe there are a few meaningful cases where padding could
> hide the message length without too much overhead. (I'm not convinced, just a random thought.)
I think a new message type that could contain message + pad would be trivial.
Would this again be to obfuscate traffic patterns? Anti DPI is not the scope of BIP151.
>
> Misc
> ====
> "The ID/string mapping is a peer to peer arrangement and MAY be negotiated between the
> requesting and responding peer." I think that's overly complicated. I suggest it should just be
> written in stone, again to avoid complexity and to avoid fingerprinting. New implementations are
> necessary anyway, so maybe just use IDs for anything? ASCII is nice if you want to debug your code
> or some random network failure but that's hard anyway when encryption is used.
I wanted to avoid too much central planing here and only cover the ones where it's most efficient (small messages that are used often).
The ASCII commands are in itself somehow pseude-robust against collision.
For a 1MB block message, using a 1-byte short ID (rather then a 6-byte ASCII command) would reduce the bandwidth requirement insignificant (99.99952%).
If we would always have used short IDs in the past, there could have been a collision between XTIN, compact, sendheaders or so.
>
> In general, the entire thing is a little bit underspecified. (I'm aware it's just a draft.)
> A few examples:
> - What should a peer do if the MAC verification fails?
> - What should a peer do if it receives an even key?
> - "Processing the message before the authentication succeeds (MAC verified) MUST not be done."
> That should also apply to the ciphertext. (Or: What is a "message"?). It may be a good idea to
> to refer to the openssh document or steal from it; it does a pretty good job.
> - "Both peers MUST keep track of the message sequence number (uint32) of sent and received
> messages for building a 64-bit symmetric cipher IV." I think you mean nonce when you say IV?
> - What is the initial value of the sequence number?
Good points. Will make them more clear in the BIP.
I was under the false impression that it is obvious to disconnect in those cases.
> - How is a 64-bit nonce formed from one (two?) uint32?
That’s specified in ChaCha20Poly1305 at openssh ("a nonce consisting of the packet sequence number encoded as a uint64“).
But I’ll specified that more clear.
> - What if the uint32 overflows?
The max data before rekey is 1GB, AFAIK it is impossible to overflow.
> - "Re-Keying interval is a peer policy with a minimum timespan of 10 seconds." What if I receive
> too many re-keying requests? Nothing or should I raise the DoS score?
Current implementation proposal does a disconnect. With the risk of fingerprinting options, I think we can leave this open to the implementation?
> - "The Re-Keying must be done after every 1GB of data sent or received" Hm, every peer updates its
> own sending key, so this should just read "sent" instead of "sent or received“?
Yes. Should probably be „sent“,… and eventually a paragraph that states that a peer should disconnect if the remote peer did not rekey within that limit.
> Pseudocode could probably help here.
Agree. Will try to add.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180907/348e23e8/attachment.sig>;