Can we decide on RFC 6979 or an equilvalent before we have more issues?

[fbueller]

Since RFC6979 essentially states you seed a HMACDBRG with a private key and the message hash, purely to obtain a k value which is unique for this private key, is there any reason you cannot use the public keys x coordinate instead if the private key?

A 'problem' with the RFC is no one can tell if you were using deterministic signatures without your private key. Why assume its the private key? The public key is recoverable from a signature, so observers can verify you are carrying this out this procedure without your private key.

All that matters is they are unique.

[hhanh00]

If you did that, anyone can compute k and the secret key.

[fbueller]

Ah, you are right.  R would be entirely known. Should have had my coffee this morning..

[gmaxwell]

Interesting - as the feedback I'd got from gmaxwell was that he didn't think that the RFC should be used.

Huh??!  No, I believe I was the first person to promote it in this community.

Perhaps there was confusion over this point:   It doesn't actually solve the problems you're talking about. The very same incidences caused the private keys to be just as insecure.

This doesn't mean that a strong derandomized DSA isn't a good idea, but it does less than many credit it for.

[gmaxwell]

DSA has the same problem. I don't know what would work well. Subliminal free signatures introduce other issues or are impractical IMO. But smart people are working hard in this field...

Unique signatures are trivial and exist in many forms (e.g. the BLS signature scheme is automatically unique); They all have unacceptable tradeoffs: Huge increases in signature sizes, much less mature cryptographic assumptions, greatly increased verifier computational complexity, patents, one time use, lack of review, etc. (or usually a mixture of all these)

Picking a signature scheme based primarily on your ability to suppress side channels sounds like obsessive micro-optimization.  While desirable, we have multisignature already, which is arguably better than sidechannel suppression, and doesn't excessively compromise the many far more concerning criteria.

[hhanh00]

Picking a signature scheme based primarily on your ability to suppress side channels sounds like obsessive micro-optimization.  While desirable, we have multisignature already, which is arguably better than sidechannel suppression, and doesn't excessively compromise the many far more concerning criteria.

Is there any hardware wallet that supports multisig? AFAIK Trezor doesn't yet. I was only concerned about subliminial channels because of the need to trust the wallet software. But I was wrong, they actually provide a way to check that the firmware isn't tampered - even if it is by them.

[gmaxwell]

But I was wrong, they actually provide a way to check that the firmware isn't tampered - even if it is by them.

Tampered firmware can just feed you a copy of the correct firmware.  (snake oil certification even gets the clueful folks, I guess).

The btcchip stuff apparently works with multisig... though it's a little odd to use because it doesn't have a display (it does a very clever thing where it acts as a USB HID device and you plug into another device to act as the screen.)

[hhanh00]

But I was wrong, they actually provide a way to check that the firmware isn't tampered - even if it is by them.

Tampered firmware can just feed you a copy of the correct firmware.  (sane oil certification even gets the clueful folks, I guess).

No no, I know they could have used a shadow rom but I think you have to trust them eventually if you want to use it. At this point, you can compile from source, check that the hash is the same as the signed package and then flash the later. I have some experience with embedded devices so I have some ideas on how to circumvent this but it's as good as it gets IMO.

(Besides, the easiest is to avoid reusing any address)
(I don't use any hardware wallet)

[bcearl]

There is no global decision to be made here. RFC6979 has to be implemented by each implementation itself, and there is no way to externally check which one transaction is created accordingly and which one is not.

RSA is dead, it is slow and it will be even slower. RSA 2048 will not be secure any more soon (for Bitcoin, ten years are soon!). Longer key lenghs does not help. If you really want a long-time secure RSA, you would need 15kbit keys, which is beyond serious consideration.

And even if it would work: RSA is only deterministic in principle. The mathematical basics of RSA are deterministic, but it does have a lot of flaws as well. To get rid of the flaws, you need to implement a lot of tricks including non-deterministic padding for messages. Serious implementations of RSA are not deterministic either.