đź“… Original date posted:2018-09-03
📝 Original message:Without commenting on the other merits of either proposal, the addition of the service flag resolves bip151’s previously-discussed lack of backward compatibility.
e
> On Sep 3, 2018, at 21:16, Jonas Schnelli via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi
>
> During work on the implementation of BIP151 [1] I figured out that the current
> published proposal could be further optimized.
>
> I wrote an overhauled BIP151 specification with some – partially radical –
> changes.
>
> Now it’s unclear to me if this should be published under a new BIP nr. or if it
> is acceptable to change the existing 151 proposal.
> If a new BIP number would be required, I think withdrawing BIP151 should be
> done (which somehow indicates we should alter 151).
>
> The only BIP151 implementation I’m aware of is the one from Armory [2].
> BCoins implementation has been removed [3].
>
> The new proposal draft is available here:
> https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52
>
> Major changes
> =============
> - the encryption handshake no longer requires the v1 protocol, it’s a pure
> 32bytes-per-side „pseudorandom" key exchange that happens before anything else.
> - the multi message envelope has been removed.
> - a new NODE_ENCRYPTED service bit
> - the key derivation and what communication direction uses what key is now more
> specific
> - the length of a packet uses now a 3-byte integer with 23 available bits
> - introduction of short-command-ID (ex.: uint8_t 13 == INV, etc.) which result in
> some v2 messages require less bandwidth then v1
> - rekeying doesn’t require a message and can be signaled in the most
> significant bit in the packet-size field
>
>
> Points that are in discussion and may be added to the BIP (or to a new one):
>
> Hybrid NewHope key exchange
> ===========================
> The current ECDH key exchange is vulnerable to Shor’s algorithm and is thus not
> considered quantum-safe.
> Following TORs approach [4] by adding a NewHope [5] key-exchange the handshake
> protocol would very likely make the encryption PQ safe with little costs.
> There is also a straight forward implementation [6] from the NewHope team that
> has been submitted to NIST PQC project.
>
> Inefficiency of ChaCha20Poly1305 at openssh
> ========================================
> The proposed AEAD could eventually be further optimized.
> ChaCha20Poly1305 at openssh uses at least three rounds of ChaCha20 which
> eventually can be reduced to two (messages below <=64 bytes [inv, ping,
> pong,...] only require one round of ChaCha20, but two for the Poly1305 key and
> the message length encryption where the Poly1305 key chacha round „throws away“
> 32 bytes).
>
>
> I would suggest that we don’t rehash discussions about the general
> concept of encrypting the traffic. This has already been discussed [7][8].
>
> I hope we can limit this thread to discuss further ideas for optimisation as well as
> technical details of the published proposal or its implementation.
>
>
> [1] https://github.com/bitcoin/bitcoin/pull/14032
> [2] https://github.com/goatpig/BitcoinArmory/pull/510
> [3] https://github.com/bcoin-org/bcoin/commit/41af7acfd68b0492a6442865afd439300708e662
> [4] https://gitweb.torproject.org/user/isis/torspec.git/plain/proposals/XXX-newhope-hybrid-handshake.txt?h=draft/newhope
> [5] https://eprint.iacr.org/2015/1092
> [6] https://github.com/newhopecrypto/newhope
>
> [7] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013565.html
> [8] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-June/012826.html
>
>
> Thanks
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Eric Voskuil [ARCHIVE] /
npub1sg…ppx3c
2023-06-07 18:14:32
in reply to nevent1q…jjj8
Author Public Key
npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3cPublished at
2023-06-07 18:14:32Event JSON
{
"id": "945fc9c2b494a52c119f623afa3bc14d9ac9a9d9ebf362a965b0efcba8400c0d",
"pubkey": "82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e",
"created_at": 1686161672,
"kind": 1,
"tags": [
[
"e",
"09bbfb36304ce80b7562564d4efcc5e0da687e130fd0018986c38ff8b9a9cc86",
"",
"root"
],
[
"e",
"6ba47097c1c1ddf06d09d54d9ed31723db2ccf878f54ca847b65215a48e29123",
"",
"reply"
],
[
"p",
"9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c"
]
],
"content": "📅 Original date posted:2018-09-03\n📝 Original message:Without commenting on the other merits of either proposal, the addition of the service flag resolves bip151’s previously-discussed lack of backward compatibility.\n\ne\n\n\u003e On Sep 3, 2018, at 21:16, Jonas Schnelli via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e Hi\n\u003e \n\u003e During work on the implementation of BIP151 [1] I figured out that the current\n\u003e published proposal could be further optimized.\n\u003e \n\u003e I wrote an overhauled BIP151 specification with some – partially radical –\n\u003e changes.\n\u003e \n\u003e Now it’s unclear to me if this should be published under a new BIP nr. or if it\n\u003e is acceptable to change the existing 151 proposal.\n\u003e If a new BIP number would be required, I think withdrawing BIP151 should be\n\u003e done (which somehow indicates we should alter 151).\n\u003e \n\u003e The only BIP151 implementation I’m aware of is the one from Armory [2].\n\u003e BCoins implementation has been removed [3].\n\u003e \n\u003e The new proposal draft is available here:\n\u003e https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52\n\u003e \n\u003e Major changes\n\u003e =============\n\u003e - the encryption handshake no longer requires the v1 protocol, it’s a pure\n\u003e 32bytes-per-side „pseudorandom\" key exchange that happens before anything else.\n\u003e - the multi message envelope has been removed.\n\u003e - a new NODE_ENCRYPTED service bit\n\u003e - the key derivation and what communication direction uses what key is now more\n\u003e specific\n\u003e - the length of a packet uses now a 3-byte integer with 23 available bits\n\u003e - introduction of short-command-ID (ex.: uint8_t 13 == INV, etc.) which result in\n\u003e some v2 messages require less bandwidth then v1\n\u003e - rekeying doesn’t require a message and can be signaled in the most\n\u003e significant bit in the packet-size field\n\u003e \n\u003e \n\u003e Points that are in discussion and may be added to the BIP (or to a new one):\n\u003e \n\u003e Hybrid NewHope key exchange\n\u003e ===========================\n\u003e The current ECDH key exchange is vulnerable to Shor’s algorithm and is thus not\n\u003e considered quantum-safe.\n\u003e Following TORs approach [4] by adding a NewHope [5] key-exchange the handshake\n\u003e protocol would very likely make the encryption PQ safe with little costs.\n\u003e There is also a straight forward implementation [6] from the NewHope team that\n\u003e has been submitted to NIST PQC project.\n\u003e \n\u003e Inefficiency of ChaCha20Poly1305 at openssh\n\u003e ========================================\n\u003e The proposed AEAD could eventually be further optimized.\n\u003e ChaCha20Poly1305 at openssh uses at least three rounds of ChaCha20 which\n\u003e eventually can be reduced to two (messages below \u003c=64 bytes [inv, ping,\n\u003e pong,...] only require one round of ChaCha20, but two for the Poly1305 key and\n\u003e the message length encryption where the Poly1305 key chacha round „throws away“\n\u003e 32 bytes).\n\u003e \n\u003e \n\u003e I would suggest that we don’t rehash discussions about the general\n\u003e concept of encrypting the traffic. This has already been discussed [7][8].\n\u003e \n\u003e I hope we can limit this thread to discuss further ideas for optimisation as well as\n\u003e technical details of the published proposal or its implementation.\n\u003e \n\u003e \n\u003e [1] https://github.com/bitcoin/bitcoin/pull/14032\n\u003e [2] https://github.com/goatpig/BitcoinArmory/pull/510\n\u003e [3] https://github.com/bcoin-org/bcoin/commit/41af7acfd68b0492a6442865afd439300708e662\n\u003e [4] https://gitweb.torproject.org/user/isis/torspec.git/plain/proposals/XXX-newhope-hybrid-handshake.txt?h=draft/newhope\n\u003e [5] https://eprint.iacr.org/2015/1092\n\u003e [6] https://github.com/newhopecrypto/newhope\n\u003e \n\u003e [7] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013565.html\n\u003e [8] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-June/012826.html\n\u003e \n\u003e \n\u003e Thanks\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "1cdb84a31f30130b439653f809fc1d31be33f74d8fe75e1cffb478cefc69ad4b861107cb5c2acea48e479641ad0d59d39f0986fea4181ca160f7464feb392293"
}