📅 Original date posted:2014-08-09
📝 Original message:> Does anyone see any concerns when it comes to security of the proposed
> change?
Yes. This proposal is less secure.
It is incompatible in theory with existing implementations of the
specification. The incompatibility is also a potentially a security
problem because it may cause users to believe a key is worthless when
it is not or to lose funds when they are unable to spend them.
It is also an untimely proposal and would be inconsiderate other parties
who have done the work to produce correct and compatible implementations.
> In case I_L >= n assign I_L := I_L mod n.
This will make the selection of private keys uneven.
The unevenness is small and it is unlikely to very matter much but it
is objectively less secure. Future advances in cryptography may make
the distinction more important. The change would eliminate any hope of
the specification ever having provable security equal to random keys.
The bignum modulo operation also requires complex additional logic and is
just as likely to remain untested in implementations, though unit-testing
can test these cases by replacing the hash function.
Because of layering no suitable modulo may be available and an incorrect
implementation could create a devastating weakness, like reflecting a
large class of keys to a small number of values. A similar error would
be unlikely for an incorrect implementation of skipping and someone who
managed to still fail would likely have failed either way.
> most of the implementations don't do the checking at all, because tjen
> it's rather hard at application level to implement skipping logic. OTOH
There are many corner cases which must be handled in cryptographic
software.
You must handle the point at infinity cases, you must handle the signature
having a value of zero (or you leak the private key), in the point
arithemetics you must handle the special case of adding colinear points.
If someone is unprepared to deal with these and many other complications
they may want to leave writing this kind of software for other people.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140809/8da85020/attachment.html>;
second isogeny [ARCHIVE] /
npub1qa…c5jtv
2023-06-07 15:25:08
in reply to nevent1q…7qy5
Author Public Key
npub1qajs2nd7fp5rpyrkmwxsygzmjnjyz25724k5aj6stnylel6daehqyc5jtvSeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:25:08Event JSON
{
"id": "e3bf0ad4b0c6c8b48c975cbb53307af3062d69234b14263b90f08c82720ecef3",
"pubkey": "0765054dbe4868309076db8d02205b94e4412a9e556d4ecb505cc9fcff4dee6e",
"created_at": 1686151508,
"kind": 1,
"tags": [
[
"e",
"3ca0963e89cd1107e635c5e4bc693c845dc6452cc3c59b304c35ad8ade1f5307",
"",
"root"
],
[
"e",
"e6107998174bcd724d16b0881e2fb1ffeb385c54f6540bdef54789ee792ba5b0",
"",
"reply"
],
[
"p",
"7631397e469f47f3535567311f5f7c17129e0ff2cb253df015e3d92ddfd92c63"
]
],
"content": "📅 Original date posted:2014-08-09\n📝 Original message:\u003e Does anyone see any concerns when it comes to security of the proposed\n\u003e change?\n\nYes. This proposal is less secure.\n\nIt is incompatible in theory with existing implementations of the\nspecification. The incompatibility is also a potentially a security\nproblem because it may cause users to believe a key is worthless when\nit is not or to lose funds when they are unable to spend them.\n\nIt is also an untimely proposal and would be inconsiderate other parties\nwho have done the work to produce correct and compatible implementations.\n\n\u003e In case I_L \u003e= n assign I_L := I_L mod n.\n\nThis will make the selection of private keys uneven.\n\nThe unevenness is small and it is unlikely to very matter much but it\nis objectively less secure. Future advances in cryptography may make\nthe distinction more important. The change would eliminate any hope of\nthe specification ever having provable security equal to random keys.\n\nThe bignum modulo operation also requires complex additional logic and is\njust as likely to remain untested in implementations, though unit-testing\ncan test these cases by replacing the hash function.\n\nBecause of layering no suitable modulo may be available and an incorrect\nimplementation could create a devastating weakness, like reflecting a\nlarge class of keys to a small number of values. A similar error would\nbe unlikely for an incorrect implementation of skipping and someone who\nmanaged to still fail would likely have failed either way.\n\n\u003e most of the implementations don't do the checking at all, because tjen\n\u003e it's rather hard at application level to implement skipping logic. OTOH\n\nThere are many corner cases which must be handled in cryptographic\nsoftware.\n\nYou must handle the point at infinity cases, you must handle the signature\nhaving a value of zero (or you leak the private key), in the point\narithemetics you must handle the special case of adding colinear points.\n\nIf someone is unprepared to deal with these and many other complications\nthey may want to leave writing this kind of software for other people.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140809/8da85020/attachment.html\u003e",
"sig": "a241f7c6e79040f1cf4257b4c5ac27f03023b0d168361cdbf0e7634edb8fe41deb1999c5ea1c7d5428552cb4aee70356954296e64c0a7b3f0bd5f9c351a82bf5"
}