On an unrelated note, X.509 is a terrible standard that should be
abandoned as quickly as possible. BitPay is working on a new standard
based on bitcoin-like addresses for authentication. It would be great if
we could work with the community to establish a complete, decentralized
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
On Mar 5, 2014, at 8:56 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
On Wed, Mar 5, 2014 at 1:49 PM, Mike Hearn m...@plan99.net wrote:
I am not currently aware of any efforts to make OpenSSL's secp256k1
implementation completely side channel free in all aspects. Also,
unfortunately
On Wed, Mar 5, 2014 at 2:18 PM, Jean-Paul Kogelman
jeanpaulkogel...@me.com wrote:
As far as I know, judging from the implementation, there is hardly any
effort to try to prevent timing attacks.
Is it safe to assume that this is also true for your secp256k1 implementation?
I've done some
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
On Wed, Mar 05, 2014 at 11:21:52AM -0500, Kevin wrote:
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:
How can we patch this issue?
If you're following
On Wed, Mar 05, 2014 at 11:51:25AM -0800, Gregory Maxwell wrote:
On Wed, Mar 5, 2014 at 11:39 AM, Peter Todd p...@petertodd.org wrote:
If you're following good practices you're not particularly vulneable to
it, if at all, even if you make use of shared hosting. First of all you
shouldn't be
On Wed, Mar 5, 2014 at 12:32 PM, Peter Todd p...@petertodd.org wrote:
That's nice, but I wrote my advice to show people how even if they don't
know any crypto beyond what the black boxes do - the absolute minimum
you need to know to write any Bitcoin software - you can still defend
yourself
If we don't mind sacrificing some performance when signing, there's a fairly
simple way to implement a constant-time constant-cache-access-pattern secp256k1.
It is based on the idea of branchless implementations of the field and group
operations.
Multiprecision arithmetic can be implemented
On Wed, Mar 5, 2014 at 1:31 PM, Eric Lombrozo elombr...@gmail.com wrote:
If we don't mind sacrificing some performance when signing, there's a fairly
simple way to implement a constant-time constant-cache-access-pattern
secp256k1.
It is based on the idea of branchless implementations of the
Everything you say is true.
However, branchless does reduce the attack surface considerably - if nothing
else, it significantly ups the difficulty of an attack for a relatively low
cost in program complexity, and that might still make it worth doing.
As for uniform memory access, if we avoided
Hello. How would I submit a patch? Could it be sent through the list
as an attachment?
--
Kevin
--
Subversion Kills Productivity. Get off Subversion Make the Move to Perforce.
With Perforce, you get hassle-free
On Wed, Mar 5, 2014 at 2:39 PM, Peter Todd p...@petertodd.org wrote:
More important though is you shouldn't be using single factor Bitcoin
addresses. Use n-of-m multisig instead and architect your system such
that that every transaction that happens in your service has to be
authorized by both
On Wed, Mar 5, 2014 at 2:14 PM, Eric Lombrozo elombr...@gmail.com wrote:
Everything you say is true.
However, branchless does reduce the attack surface considerably - if nothing
else, it significantly ups the difficulty of an attack for a relatively low
cost in program complexity, and that
On Wed, Mar 5, 2014 at 2:17 PM, Kevin kevinsisco61...@gmail.com wrote:
Hello. How would I submit a patch? Could it be sent through the list
as an attachment?
To the reference software? Normally you'd open a github account and
submit there.
Though if for some reason you can't— though its
Oh, I absolutely agree that this type of attack is NOT the weakest link in
security. There are MANY far easier targets in bitcoind and typical use
scenarios of it. If we want to dramatically improve the security of a typical
bitcoin wallet, the FLUSH+RELOAD attack is probably not where our
One wonders also re. bitmessage, though that may not be relevant to this
particular list.
On Wed, Mar 05, 2014 at 11:21:52AM -0500, Kevin wrote:
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
On Wed, Mar 5, 2014 at 11:17 PM, Kevin kevinsisco61...@gmail.com wrote:
Hello. How would I submit a patch? Could it be sent through the list
as an attachment?
You can, but as reviewing can take a while, the github model works better
for this project.
In my experience people lose track of
18 matches
Mail list logo
