On Wed, Mar 5, 2014 at 11:17 PM, Kevin 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 patches sent to mailing
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
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 effor
On Wed, Mar 5, 2014 at 2:17 PM, Kevin 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 strongly preferred—
sending
On Wed, Mar 5, 2014 at 2:14 PM, Eric Lombrozo 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 might still mak
On Wed, Mar 5, 2014 at 2:39 PM, Peter Todd 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 the "online" s
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 wor
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
On Wed, Mar 5, 2014 at 1:31 PM, Eric Lombrozo 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 field and group
>
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 bran
On Wed, Mar 5, 2014 at 12:32 PM, Peter Todd 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 against that at
On Wed, Mar 05, 2014 at 11:51:25AM -0800, Gregory Maxwell wrote:
> On Wed, Mar 5, 2014 at 11:39 AM, Peter Todd 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 re-using ad
On Wed, Mar 5, 2014 at 11:39 AM, Peter Todd 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 re-using addresses, which means you won't be passing that
> ~200 sig threshold.
>
>
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 fo
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
yea
On Wed, Mar 5, 2014 at 2:18 PM, Jean-Paul Kogelman
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 preliminary work on
> On Mar 5, 2014, at 8:56 PM, Pieter Wuille wrote:
>
>> On Wed, Mar 5, 2014 at 1:49 PM, Mike Hearn wrote:
>> 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
On Wed, Mar 5, 2014 at 1:49 PM, Mike Hearn wrote:
> 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 i
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 timing
>
> 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
> authen
20 matches
Mail list logo
