You wrote, "Most exploits arise from programming errors in low level weakly typed languages". I pointed out that in our space we've observed the opposite: There have been more serious cryptographic weaknesses in software written in very high level languages like python, javascript, php, Java. etc. Thats all.  Please tone down the personal insults. You're very close to earning an ignore button press from me. I have scrupulously avoided besmirching your skills-- or even saying that I think your preferred tools are not _good_, only that that people using them suffer errors too-- but in every response you make you attack my competence.

Yes, years ago. https://bitcointalk.org/index.php?topic=21995.0

Our process is not "don't make mistakes", Bitcoin Core largely uses a safer subset of C++ that structurally prevents certain kinds of errors (assuming the subset is followed, we don't have any mechanical enforcement).  I don't believe anyone writing or reviewing code for the project would describe things primary safety strategy as coming from "don't make mistakes", not with the level of review and the general avoidance of riskier techniques.

Though even equip with automatic theorem provers that could reason about cryptographic constructs no language or language facility can free you from having to avoid errors (though avoiding errors is much more than "just don't make them").

Things like "restart on crash" can be quite dangerous, because they let an attacker try their attack over and over, or keep the software running (and mining / authoring irreversible transactions) on a failing system. In most cases if we know that something that the software hasn't accounted for has happened just being shut down is better. If doing this results in a DOS attack, ... DOS attacks against the network are bad, but they're preferable to less recoverable outcomes. I think if anything we'd be likely to go the other way: On a "can never happen" indication of  corruption, write out a "your_system_appears_busted_and_bitcoin_wont_run_until_you_test_it_and_remove_th is_file.txt" that gets checked for at startup.

There have been Java bitcoin software, e.g. a vanity-generator that generated predictable keys, altcoin software that failed in various ways, bouncycastle causing inconsistency in node software from throwing surprise null pointer exceptions on weird inputs. I wasn't saying that there was any language issue there, but pointing out that even using the most confined language you can find will not prevent people from writing unsound cryptographic software. (And perhaps even making things worse, if the protection against idiotic mistakes makes people forget that they're playing with fire.)

Actually no, you're catching the point I'm making but missing it.  Cryptographic systems in general have the property that you live or die based on implicit details. Cryptographic consensus makes the matter worse only in that a larger class of surprises which turn out to be fatal security vulnerabilities. It's quite possible, and has been observed in practise, to go end up with exploitable systems because some burred/abstracted behaviour is different than you expected. A common example is propagating errors up to to the far side when authentication fails and leaking data about the failure allowing incrementally recovering secret data.  Other examples are that implicit padding behaviour leaking information about keys (there is an example of this in Bitcoin core: OpenSSL's symmetric crypto routines had implicit padding behaviour that make the wallet encryption faster to crack than had been intended.)

I'm certainly a fan of smarter tools that make software safer (I'm conceptually a big fan of Rust, for example). But what I'm seeing deployed out in the wider world is that more actual deployed weak cryptography software is resulting from reasons unrelated to language.  This doesn't necessarily mean anything about non-cryptographic software. And some of it is probably just an attitude correlation; you don't get far in C if you're not willing to pay attention to details. So we might expect other languages to be denser in sloppy approaches. But that doesn't suggest that someone equally attentive might not do better, generally, in something with better properties. (I guess this is basically your demographic correlation).  So I'm certainly not disagreeing with these points; but I am disagreeing with the magic bullet thinking which is provably untrue: Writing in FooLang will absolutely not make your programs safe for people to use. It _may_ be helpful, indeed, but it is neither necessary nor sufficient, as demonstrated by the software deployed in the field.

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.)

It was an issue in OpenSSL (bitcoind doesn't expose SSL to the public in a default, or even sane, configuration at least).  Every other language also depends on system libraries too. So the language Bitcoin core was written in was irrelevant in this example.

I'm sorry you feel that I'm nitpicking, but I'm not trying to.

So far our experience in this space is that there is more irresponsible and broken software written in higher level languages, there has been virtually no issues in this space from cryptographic weaknesses (or even conventional software security) in Bitcoin applications written in C / C++. I agree that sounds somewhat paradoxical... but it's not that shocking: The security of these systems depends on the finest details of the behaviour of each part of the software and the interactions, when your system obscures the details some extra work is required to review though the indirection. This somewhat offsets the gains. In cryptographic (and especially consensus) systems it's much harder to "fail safe" and a much wider spectrum of unexpected behaviour is actually bad and exploitable. Languages like Java make some kinds of errored software "more safe" when the software is incorret, but making software more correct is still something that is largely not reaching production industrial software development yet (languages with dependant types and facilities for formal analysis seem like they _may_ result in more correct software).  

There is no replacement for hard work and many view higher level languages as an escape from drudgery, so there may be some language selection bias from the attitude of the authors that has nothing to do with the language itself.  In any case, I think your barb was misplaced, at least in this thread: We've seen bad RNG behaviour from Java software several times, and not just in system libraries. (And not just RNG safety, also things like attempts at full node code being shattered by underlying crypto libraries bubbling up null pointer exceptions that cause false block rejections which would have created forks if it were widely used).

(I do agree though that using untyped languages is basically suicide for any, even moderately large, system where correctness matters.)

Except the issues with poor cryptographic security Mike is talking about have only been observed-- so far-- in tools written in Java, Javascript, and Python in our ecosystem. None of these are low level languages.

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.

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.

No it wouldn't, adding a new signature system is just a soft forking addition, of a smaller scale than we've made several times before (e.g. with the introduction of p2sh).  Not something to do lightly but not that big a deal.

But blinding alone isn't enough, because you actually want the signer to see the message (because the signer needs to display what the message will do to act as an independent check or to enforce business logic).  Though there is probably a very narrow and very efficient ZKP that can be used to unblind only the message.

Yes/no. I thought it was nice at first but then I realized it's no better than my two move scheme, I think.

The signer knows the resulting r that will show up in the signature so he can grind u to stuff bits into it.

I was referring to the two move protocol in Adam's message (apparently originally by hhanh00 but lost?). not the ordinary commitment there by Sergio.  And I refereed to it as blinding because it makes the numbers in the transcript statistically uniform to a party who doesn't know the secret, and because it's similar in construction to a full blinding scheme-- effectively it's blinding the nonce used by the signer but not the message. Thats all.

Interestingly, the TPM 2.0 signing stuff computes the nonce this way: https://eprint.iacr.org/2013/667.pdf (Section 3), it lets you use a arbitrary point for the nonce multiply.

I wonder if they'd been thinking of s similar blinding scheme?

I don't think the determinism detection is all that interesting.

An evil signer can use the message input as the 'random state' needed to leak data, and be completely deterministic over the inputs.

Take your secret, encrypt it with the attackers pubkey, boost it up with an infinite rate code, use the message to select which codeword of the infinite rate code you're leaking. Thats how I was able to get a 'deterministic' signer that could leak arbitrary sized secrets with enough signatures.

If the concern is the 1 bit failure channel, you can even pre-process the code to make it binary unbalanced so most of the time it's successful, which may make it less obvious that it's using a failure channel to communicate...  (uh, decoders for this may be more complicated however) Though if you don't know the messages that triggered failures, only the successes, your data rate will be very very low unless the failure probability is close to 50%.

Also new wallets created.  And "this time period" is somewhat ambiguous due to caching. For all I know there is some browser tab up someplace running this code that could generate an address and and receive 1000 BTC at any moment.

I can make this non-interactive at a cost of not eliminating the side channel, only drastically reducing it.

This is effectively a scheme  for "sign-to-contract" I was thinking thinking about using for zero-overhead timestamping as a side effect of transactions.

User sends picks a random 256 bit integer t.
Users sends t and the signature request to the signer.

Signer picks a nonce k, computes R = G*k.
Signer computes h=hmac(msg=r,key=t)
Signer computes k' = k+h mod order and R' = R + G*h
Signer signs like normal, using k'
Signer emits signature along with R.

User verifies that R + G*h mod order == signature.r.

This leaves open a side-channel that has exponential cost per additional bit, via grinding the resulting R' mod order.  Using the FEC schemes that I've discussed before it's possible to leak a message of any size using even a single bit channel and enough signatures...  But it eliminates the obvious and very powerful attacks where everything is leaked in a single signature.

This is clearly less good, but it's only a two-move protocol, so many places which wouldn't consider using a countermeasure could pick this up for free just as an element of a protocol spec.

BC.i sometimes uses forced pushes which conceal the prior revisions.

Yep, as everyone says here.. You're misreading the report. Bitcoin is using 1.2GB ram and you have plenty of available memory.

This does a lot less than what most people think it does...


And yet what the poster goes on to describe does not actually accomplish that.  (and, technically, as an aside being first it not really as relevant for copyright, since independent creation is possible and permitted)

Say you invent something.  Now I can go timestamp it.  And claim to have invented it.

Say you invent something and timestamp it.  I can say "I invented it first, he just timestamped a copy of my idea."

We can both timestamp the same thing (or substantially the same thing) and interdependently go show our timestamps to third parties who will never be aware of the other claim.

These ideas are not new... people were commuting to things back in 2010. These ideas reoccur ever couple of months when people don't bother to do any research and see it's all been done before... people just lose interest in it because its limited enough that the value isn't so great.

Worse, most of the reoccurring proposals are highly inefficient (e.g. require a transaction per commitment, when technically no transactions are required _at all_ to get timestamps), or even outright insecure. (Competent folks have mostly given up reviewing ideas from people who don't spend even a moment doing research.)

Combine the amounts. The interface is a dictionary. Your input is not well formed if there is duplication.

Presumably your guideline will recommend users _never_ use uncompressed public keys?