Gold collapsing. Bitcoin UP.

[NewLiberty]

out of curiosity to the security experts here.

which do you consider more secure, Armory or Trezor?

I'm not a security expert, but I would say trezor (with passphrase).

It's also easier to use securely.

Trezor seems safe. A simple paper wallet generated offline on a new computer running linux is safe too 

Did you miss Rocks post above discussing the vulnerability of using new computers, or just saying it is safe enough for you because you disagree with the risk?

[thezerg]

out of curiosity to the security experts here.

which do you consider more secure, Armory or Trezor?

I'm not a security expert, but I would say trezor (with passphrase).

It's also easier to use securely.

Trezor seems safe. A simple paper wallet generated offline on a new computer running linux is safe too  

One idea is that a small custom device like the trezor could have put an accelerometer in for just a few bucks

Haveged might be really bad on an isolated device.  No interrupts coming in...

[cypherdoc]

Mycelium Entropy:

https://www.indiegogo.com/projects/mycelium-entropy

[rocks]

I use http://www.issihosts.com/haveged/ to get more entropy (based on "processor flutter").

Mycelium Entropy:

https://www.indiegogo.com/projects/mycelium-entropy

Those are both really cool projects, thanks for sharing. If anything their existence shows that generating true randomness on deterministic computers is hard and it is necessary to resort to the variability that is found in the real physical world.

[lebing]

Mycelium Entropy:

https://www.indiegogo.com/projects/mycelium-entropy

Cool, but I won't bite until they offer bip32

[cypherdoc]

Mycelium Entropy:

https://www.indiegogo.com/projects/mycelium-entropy

Cool, but I won't bite until they offer bip32

they already do

[HeliKopterBen]

Mycelium Entropy:

https://www.indiegogo.com/projects/mycelium-entropy

"This way the paper wallet has never touched a computer or a network, and as soon as you eject the device the private key is wiped from memory"

This is not true.  Anyone printing paper wallet should be careful of what printer they are using.  Larger industrial printers have hard drives that record all spooled print data in some cases, especially older models.  Most of them are also connected to the internet.  Some of the newer models have data security or drive encryption installed by default but not all.  Smaller personal and desktop printers that don't have hard drives may be ok.  IMO dedicated hardware wallets are the better option.

http://www.cbsnews.com/news/digital-photocopiers-loaded-with-secrets/

[cypherdoc]

Mycelium Entropy:

https://www.indiegogo.com/projects/mycelium-entropy

"This way the paper wallet has never touched a computer or a network, and as soon as you eject the device the private key is wiped from memory"

This is not true.  Anyone printing paper wallet should be careful of what printer they are using.  Larger industrial printers have hard drives that record all spooled print data in some cases, especially older models.  Most of them are also connected to the internet.  Some of the newer models have data security or drive encryption installed by default but not all.  Smaller personal and desktop printers that don't have hard drives may be ok.  IMO dedicated hardware wallets are the better option.

http://www.cbsnews.com/news/digital-photocopiers-loaded-with-secrets/

Is Trezor a single address that is reused?

[brg444]

Mycelium Entropy:

https://www.indiegogo.com/projects/mycelium-entropy

"This way the paper wallet has never touched a computer or a network, and as soon as you eject the device the private key is wiped from memory"

This is not true.  Anyone printing paper wallet should be careful of what printer they are using.  Larger industrial printers have hard drives that record all spooled print data in some cases, especially older models.  Most of them are also connected to the internet.  Some of the newer models have data security or drive encryption installed by default but not all.  Smaller personal and desktop printers that don't have hard drives may be ok.  IMO dedicated hardware wallets are the better option.

http://www.cbsnews.com/news/digital-photocopiers-loaded-with-secrets/

Is Trezor a single address that is reused?

no trezor has bip32 HD wallet

[smoothie]

I wonder if you could use the current CPU temperature to the first or second decimal place as a source of entropy.

The least significant bit of a 16 bit audio sample always seemed a good idea to me.

The nice thing about randomness: you can mix many sources (using xor or whatever) and you'll not lose anything even if one source is bad.

Unfortunately what you may get wrong if you are too careless about this is how much useful randomness you have.

If I recall correctly some sources in the Linux kernel rng are added to the pool but counted as zero entropy.

this is why understanding the inner workings of predifined rng's or procedure calls to generate entropy is essential.

Also making sure that entropy is explicitly used properly is key. Simply make sure entropy is being used for what it is being generated for.

[dnaleor]

out of curiosity to the security experts here.

which do you consider more secure, Armory or Trezor?

I'm not a security expert, but I would say trezor (with passphrase).

It's also easier to use securely.

Trezor seems safe. A simple paper wallet generated offline on a new computer running linux is safe too  

the problem with a paper wallet is to spend the coins safely.
An average bitcoin user these days isn't able to create a linux live CD, import a private key, export the transaction by USB and broadcast it on another online computer running a full node.

[molecular]

out of curiosity to the security experts here.

which do you consider more secure, Armory or Trezor?

I'm not a security expert, but I would say trezor (with passphrase).

It's also easier to use securely.

Trezor seems safe. A simple paper wallet generated offline on a new computer running linux is safe too  

the problem with a paper wallet is to spend the coins safely.
An average bitcoin user these days isn't able to create a linux live CD, import a private key, export the transaction by USB and broadcast it on another online computer running a full node.

Exactly. Like I said above: trezor (with additional passphrase against theft of seed backup) is quite secure, but most importantly: it's both easy to use securely (hard to fuck up) and very convenient. I use it as a day-to-day wallet (plus mycelium on the phone)

[cypherdoc]

I wonder if you could use the current CPU temperature to the first or second decimal place as a source of entropy.

The least significant bit of a 16 bit audio sample always seemed a good idea to me.

The nice thing about randomness: you can mix many sources (using xor or whatever) and you'll not lose anything even if one source is bad.

Unfortunately what you may get wrong if you are too careless about this is how much useful randomness you have.

If I recall correctly some sources in the Linux kernel rng are added to the pool but counted as zero entropy.

this is why understanding the inner workings of predifined rng's or procedure calls to generate entropy is essential.

Also making sure that entropy is explicitly used properly is key. Simply make sure entropy is being used for what it is being generated for.

Somebody should code  up an entropy "meter"  to go in the menu bar of Linux   distros.

[oakpacific]

out of curiosity to the security experts here.

which do you consider more secure, Armory or Trezor?

I'm not a security expert, but I would say trezor (with passphrase).

It's also easier to use securely.

Trezor seems safe. A simple paper wallet generated offline on a new computer running linux is safe too  

the problem with a paper wallet is to spend the coins safely.
An average bitcoin user these days isn't able to create a linux live CD, import a private key, export the transaction by USB and broadcast it on another online computer running a full node.

Exactly. Like I said above: trezor (with additional passphrase against theft of seed backup) is quite secure, but most importantly: it's both easy to use securely (hard to fuck up) and very convenient. I use it as a day-to-day wallet (plus mycelium on the phone)

Has anybody noticed that Bitcoin actually has the potential to eliminate theft, like, for real?

[cypherdoc]

what is "constant time"?

Improved signing security

For 0.10 the security of signing against unusual attacks has been improved by making the signatures constant time and deterministic.

This change is a result of switching signing to use libsecp256k1 instead of OpenSSL. Libsecp256k1 is a cryptographic library optimized for the curve Bitcoin uses which was created by Bitcoin Core developer Pieter Wuille.

There exist attacks[1] against most ECC implementations where an attacker on shared virtual machine hardware could extract a private key if they could cause a target to sign using the same key hundreds of times. While using shared hosts and reusing keys are inadvisable for other reasons, it's a better practice to avoid the exposure.

OpenSSL has code in their source repository for derandomization and reduction in timing leaks, and we've eagerly wanted to use it for a long time but this functionality has still not made its way into a released version of OpenSSL. Libsecp256k1 achieves significantly stronger protection: As far as we're aware this is the only deployed implementation of constant time signing for the curve Bitcoin uses and we have reason to believe that libsecp256k1 is better tested and more thoroughly reviewed than the implementation in OpenSSL.

[1] https://eprint.iacr.org/2014/161.pdf

A countermeasure against

http://en.m.wikipedia.org/wiki/Timing_attack

?

Although I can't think of a practical scenario where a typical user would ever be exposed to this, yes, the concern is side-channel attacks (e.g., a timing attack):

ABSTRACT. We apply the Flush+Reload side-channel attack based on cache hits/misses to extract a small amount of data from OpenSSL ECDSA signature requests. We then apply a “standard” lattice technique to extract the private key, but unlike previous attacks we are able to make use of the side-channel information from almost all of the observed executions. This means we obtain private key recovery by observing a relatively small number of executions, and by expending a relatively small amount of post-processing via lattice reduction. We demonstrate our analysis via experiments using the curve secp256k1 used in the Bitcoin protocol. In particular we show that with as little as 200 signatures we are able to achieve a reasonable level of success in recovering the secret key for a 256-bit curve. This is significantly better than prior methods of applying lattice reduction techniques to similar side channel information.

From: N. Benger, J van de Pol, N.P. Smart, Y. Yar, “‘Ooh Aah... Just a Little Bit’: A small amount of side channel can go a long way,” from International Association for Cryptologic Research, 2014.

Basically, there's a bunch of number crunching done by your CPU each time your wallet signs a bitcoin transaction.  If a "constant time" algorithm is used, it takes the same amount of time to produce an ECDSA signature regardless of the message being signed (or the k value or private key used).  If the signing time is always the same, then an attacker cannot learn anything about your private keys by inspecting the timing variations (since there are none) when you sign various messages.  

Where does "timing variation" come from?  As one example, your wallet needs to perform the following elliptic curve point multiplication as part of the ECDSA signing process:

  (x₁, y₁) = k x G

There's several different algorithms that can be used to carry out this multiplication.  The simplest is probably the "double and add" method.  However, the amount of time it takes this algorithm to execute depends on the specific value of k (G is always constant for bitcoin).  On the other hand, the "Montgomery Ladder" approach computes the point multiplication in a fixed amount of time (regardless of the specific value of k).  So a wallet would use a constant-time approach like the Montgomery Ladder technique rather than the double-and-add method as part of ensuring "constant time" ECDSA signatures.

Why does "constant time" matter?  In most cases I don't think it really does.  But let's imagine a contrived scenario where an attacker can get my wallet to produce several bitcoin-signed message with one of its funded private keys.  The attacker can pass it any piece of text, and my wallet will sign that text and relay the signature back to the attacker.  Normally this shouldn't be a problem because bitcoin-signed messages are safe.  But if the attacker can somehow accurately time how long my CPU takes to produce each signature, and then fiddle with the messages that it's requesting my wallet to sign, perhaps it can leach out enough information to determine my private key…

I think deterministic signatures are much more important than constant-time signatures (there's been a non-trivial amount of funds lost due to the repeat k-value problem but I doubt a single satoshi has ever been lost due to a genuine side-channel attack).  Someone like gmaxwell could comment better on the practical risks here…

I take it the time to do the multiplication varies directly with the size of the number k? Would it be linearly related?

And this applies whether or not we use deterministic signatures?

[justusranvier]

Has anybody noticed that Bitcoin actually has the potential to eliminate theft, like, for real?

Yes. Probably in more ways than you were anticipating:

I am fascinated by Tim May's crypto-anarchy. Unlike the communities traditionally associated with the word "anarchy", in a crypto-anarchy the government is not temporarily destroyed but permanently forbidden and permanently unnecessary. It's a community where the threat of violence is impotent because violence is impossible, and violence is impossible because its participants cannot be linked to their true names or physical locations.

[NotLambchop]

...

...violence is impossible because its participants cannot be linked to their true names or physical locations.

Not quite...

[cypherdoc]

https://m.youtube.com/watch?v=v6JUyK5dHoE

[NewLiberty]

...

...violence is impossible because its participants cannot be linked to their true names or physical locations.

Not quite...

LOL, you know Wei Dai wrote that like a decade before Bitcoin right?
Justus is merely pointing out that the anti-theft elements of cryptographic solutions were contemplated long before it occurred to oakpacific this week.
The potential to do what governing that needs to be done with less of a central authority is one of the values crypto has the potential to add.

And Charlie pled out to a Money Transmission violation, not theft anyway.  The MTLs are arbitrary barriers to entry set up by banking to wall off their industry from competition.  I don't know who Charlie's victim is there... Citibank? for not being able to collect their customary fees?

The MTLs are part of banking's war on cash.  So that they can control the ledgers.  The Bank Secrecy Act laws preventing un-monitored transfers of US$10K were written when? in 1970? They haven't been adjusted for inflation since?

In today's dollars that would be over US$60K
http://www.dollartimes.com/inflation/inflation.php?amount=10000&year=1970

So what may have been thought of as a reasonable law then, is insane today.   The frog is well and truly boiled.

[smoothie]

I wonder if you could use the current CPU temperature to the first or second decimal place as a source of entropy.

The least significant bit of a 16 bit audio sample always seemed a good idea to me.

The nice thing about randomness: you can mix many sources (using xor or whatever) and you'll not lose anything even if one source is bad.

Unfortunately what you may get wrong if you are too careless about this is how much useful randomness you have.

If I recall correctly some sources in the Linux kernel rng are added to the pool but counted as zero entropy.

this is why understanding the inner workings of predifined rng's or procedure calls to generate entropy is essential.

Also making sure that entropy is explicitly used properly is key. Simply make sure entropy is being used for what it is being generated for.

Somebody should code  up an entropy "meter"  to go in the menu bar of Linux   distros.

This would be interesting to see as well as a current list of entropy sources.

At some point you only need so much entropy from real world randomness but it is cool to come up with new ideas on ways to generate even more randomness.