📅 Original date posted:2014-03-05
📝 Original message:On 3/5/2014 7:49 AM, Mike Hearn wrote:
> A new practical technique has been published that can recover
> secp256k1 private keys after observing OpenSSL calculate as little as
> 200 signatures:
>
> http://eprint.iacr.org/2014/161.pdf
>
> This attack is based on the FLUSH+RELOAD technique published last
> year. It works by observing L3 CPU cache timings and forcing cache
> line flushes using the clflush opcode. As a result, it is applicable
> to any x86 environment where an attacker may be able to run on the
> same hardware i.e. virtualised hosting environments where keys are
> being reused.
>
> I am not currently aware of any efforts to make OpenSSL's secp256k1
> implementation completely side channel free in all aspects. Also,
> unfortunately many people have reimplemented ECDSA themselves and even
> if OpenSSL gets fixed, the custom implementations probably won't.
>
> So, IMHO this is a sign for hot wallet users to start walking (but not
> running) towards the exits of these shared cloud services: it doesn't
> feel safe to sign transactions on these platforms, so hot wallets
> should be managed by dedicated hardware. Of course other parts of the
> service, like the website, are less sensitive and can still run in the
> cloud. I doubt the researchers will release their code to do the side
> channel attack and it's rather complex to reimplement, so this gives
> some time for mitigation. Unfortunately the huge sums being held in
> some "bitbank" style hot wallets mean that attackers are well
> motivated to pull off even quite complex attacks.
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
How can we patch this issue?
--
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140305/64ceb7da/attachment.html>;
Kevin [ARCHIVE] /
npub1vd…sc3yk
2023-06-07 15:14:41
in reply to nevent1q…kqck
Author Public Key
npub1vdngmkaq73c0aq4fp7xgzjjtp9l66l2t50j7ma242lcp8rleuvls8sc3ykPublished at
2023-06-07 15:14:41Event JSON
{
"id": "beef2f9b9583cc327f6b7443abe090e6d614e85356d663fbecb5a7c10bf4d55e",
"pubkey": "63668ddba0f470fe82a90f8c814a4b097fad7d4ba3e5edf55557f0138ff9e33f",
"created_at": 1686150881,
"kind": 1,
"tags": [
[
"e",
"d46bd1a40c3d916ca1e2c015ea0a2210ec8d4fdd9116c09aec6725abac0dd67f",
"",
"root"
],
[
"e",
"b5f1b182db8bbf4cd8ca52838b9c4e5695401ecaf2e648360da92120973df89f",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2014-03-05\n📝 Original message:On 3/5/2014 7:49 AM, Mike Hearn wrote:\n\u003e A new practical technique has been published that can recover \n\u003e secp256k1 private keys after observing OpenSSL calculate as little as \n\u003e 200 signatures:\n\u003e\n\u003e http://eprint.iacr.org/2014/161.pdf\n\u003e\n\u003e This attack is based on the FLUSH+RELOAD technique published last \n\u003e year. It works by observing L3 CPU cache timings and forcing cache \n\u003e line flushes using the clflush opcode. As a result, it is applicable \n\u003e to any x86 environment where an attacker may be able to run on the \n\u003e same hardware i.e. virtualised hosting environments where keys are \n\u003e being reused.\n\u003e\n\u003e I am not currently aware of any efforts to make OpenSSL's secp256k1 \n\u003e implementation completely side channel free in all aspects. Also, \n\u003e unfortunately many people have reimplemented ECDSA themselves and even \n\u003e if OpenSSL gets fixed, the custom implementations probably won't.\n\u003e\n\u003e So, IMHO this is a sign for hot wallet users to start walking (but not \n\u003e running) towards the exits of these shared cloud services: it doesn't \n\u003e feel safe to sign transactions on these platforms, so hot wallets \n\u003e should be managed by dedicated hardware. Of course other parts of the \n\u003e service, like the website, are less sensitive and can still run in the \n\u003e cloud. I doubt the researchers will release their code to do the side \n\u003e channel attack and it's rather complex to reimplement, so this gives \n\u003e some time for mitigation. Unfortunately the huge sums being held in \n\u003e some \"bitbank\" style hot wallets mean that attackers are well \n\u003e motivated to pull off even quite complex attacks.\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Subversion Kills Productivity. Get off Subversion \u0026 Make the Move to Perforce.\n\u003e With Perforce, you get hassle-free workflows. Merge that actually works.\n\u003e Faster operations. Version large binaries. Built-in WAN optimization and the\n\u003e freedom to use Git, Perforce or both. Make the move to Perforce.\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=122218951\u0026iu=/4140/ostg.clktrk\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\nHow can we patch this issue?\n\n\n-- \nKevin\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140305/64ceb7da/attachment.html\u003e",
"sig": "dc4424039f9a5a34013920f6312c58998a76f5fc0aaa94f6d524aca4b05021d88031383dc15203ed1149d31e324b494c366810ca7b54cd8a00dc318c8b5f09b7"
}