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
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
On Wed, Mar 05, 2014 at 12:54:04PM -0800, Gregory Maxwell wrote:
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
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
On Sat, Mar 8, 2014 at 11:34 AM, Luke-Jr l...@dashjr.org 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.
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
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 m...@plan99.net:
I'm wondering about whether (don't laugh) moving signing into the kernel
and then using the
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
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
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
20 matches
Mail list logo
