Y'all are getting deep into tinfoil-wearing-hat-conspiracy-theory territory.
If you are worried about the NSA compromising your hardware or software,
then use multisig transactions and
sign on diverse hardware/software stacks. Generate the multiple private
keys on different hardware/software
stack
This *could* be a useful feature, but only if it's generalizable to
other processor architectures, and **in particular** has an implementation
using dedicated silicon that has a **public** open-source hardware layout,
so you can X-ray the chip, and confirm with a thermal imager that yes, the
encryp
On Wed, Mar 05, 2014 at 12:54:04PM -0800, Gregory Maxwell wrote:
> 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 wri
On Sat, Mar 8, 2014 at 11:34 AM, Luke-Jr wrote:
> On Wednesday, March 05, 2014 4:21:52 PM Kevin wrote:
>> How can we patch this issue?
> No need, it is not an issue for Bitcoin.
> Properly used, there is only ever one signature per public key.
Security shouldn't depend on perfect use. There are
On Wednesday, March 05, 2014 4:21:52 PM Kevin wrote:
> How can we patch this issue?
No need, it is not an issue for Bitcoin.
Properly used, there is only ever one signature per public key.
Luke
--
Subversion Kills Produ
While there is no mention of virtualization in the side-channel article,
the FLUSH+RELOAD paper [1] mentions virtualization and claims the clflush
instruction works not only towards processes on the same OS, but also
against processes in a separate guest OS if executed on the host OS (type 2
hyperv
You've heard of TRESOR?
No, not Trezor.
https://en.wikipedia.org/wiki/TRESOR
Signing on the CPU, without touching RAM.
- Sent from my phone
Den 6 mar 2014 09:41 skrev "Mike Hearn" :
> I'm wondering about whether (don't laugh) moving signing into the kernel
> and then using the MTRRs to disable
I'm wondering about whether (don't laugh) moving signing into the kernel
and then using the MTRRs to disable caching entirely for a small scratch
region of memory would also work. You could then disable pre-emption and
prevent anything on the same core from interrupting or timing the signing
operat
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: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
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
24 matches
Mail list logo
