Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2021-03-15 📝 Original message:On Tue, Mar 16, 2021 at ...
📅 Original date posted:2021-03-15
📝 Original message:On Tue, Mar 16, 2021 at 08:01:47AM +0900, Karl-Johan Alm via bitcoin-dev wrote:
> It may initially take months to break a single key.
>From what I understand, the constraint on using quantum techniques to
break an ECC key is on the number of bits you can entangle and how long
you can keep them coherent -- but those are both essentially thresholds:
you can't use two quantum computers that support a lower number of bits
when you need a higher number, and you can't reuse the state you reached
after you collapsed halfway through to make the next run shorter.
I think that means having a break take a longer time means maintaining
the quantum state for longer, which is *harder* than having it happen
quicker...
So I think the only way you get it taking substantial amounts of time to
break a key is if your quantum attack works quickly but very unreliably:
maybe it takes a minute to reset, and every attempt only has probability
p of succeeding (ie, random probability of managing to maintain the
quantum state until completion of the dlog algorithm), so over t minutes
you end up with probability 1-(1-p)^t of success.
For 50% odds after 1 month with 1 minute per attempt, you'd need a 0.0016%
chance per attempt, for 50% odds after 1 day, you'd need 0.048% chance per
attempt. But those odds assume you've only got one QC making the attempts
-- if you've got 30, you can make a month's worth of attempts in a day;
if you scale up to 720, you can make a month's worth of attempts in an
hour, ie once you've got one, it's a fairly straightforward engineering
challenge at that point.
So a "slow" attack simply doesn't seem likely to me. YMMV, obviously.
Cheers,
aj
Published at
2023-06-07 18:30:53Event JSON
{
"id": "fdf98ea71456f33cce689d9436c22a55058782ff8f5948bd8b34aea2d06212ac",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686162653,
"kind": 1,
"tags": [
[
"e",
"a234deec8deaa4b2f960309b1c4b9227805148596a77c14f96fdcb654e31f3ba",
"",
"root"
],
[
"e",
"4b90ad008656e543b050fe165bef9fa77c34397cbf4c8d0a174e50c5f134dac8",
"",
"reply"
],
[
"p",
"b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e"
]
],
"content": "📅 Original date posted:2021-03-15\n📝 Original message:On Tue, Mar 16, 2021 at 08:01:47AM +0900, Karl-Johan Alm via bitcoin-dev wrote:\n\u003e It may initially take months to break a single key. \n\n\u003eFrom what I understand, the constraint on using quantum techniques to\nbreak an ECC key is on the number of bits you can entangle and how long\nyou can keep them coherent -- but those are both essentially thresholds:\nyou can't use two quantum computers that support a lower number of bits\nwhen you need a higher number, and you can't reuse the state you reached\nafter you collapsed halfway through to make the next run shorter.\n\nI think that means having a break take a longer time means maintaining\nthe quantum state for longer, which is *harder* than having it happen\nquicker...\n\nSo I think the only way you get it taking substantial amounts of time to\nbreak a key is if your quantum attack works quickly but very unreliably:\nmaybe it takes a minute to reset, and every attempt only has probability\np of succeeding (ie, random probability of managing to maintain the\nquantum state until completion of the dlog algorithm), so over t minutes\nyou end up with probability 1-(1-p)^t of success.\n\nFor 50% odds after 1 month with 1 minute per attempt, you'd need a 0.0016%\nchance per attempt, for 50% odds after 1 day, you'd need 0.048% chance per\nattempt. But those odds assume you've only got one QC making the attempts\n-- if you've got 30, you can make a month's worth of attempts in a day;\nif you scale up to 720, you can make a month's worth of attempts in an\nhour, ie once you've got one, it's a fairly straightforward engineering\nchallenge at that point.\n\nSo a \"slow\" attack simply doesn't seem likely to me. YMMV, obviously.\n\nCheers,\naj",
"sig": "a70cac66fced47f02e1ab86a6276031d25b90e4d5996d2cc1f4a513aac10f14fb0ce3f739e309c8a5e828a3ca19af30f400ba70b7f3bc0a21b4495fc520c73e3"
}