Topic: Is the ECDSA public key hashed as a extra level of protection? (Read 7510 times)

I wrote "suppose".
I am only clarifying that [advertising the design choice to encode the hash of the public key is a safety feature] corresponds to [claiming it is harder to generate enough collisions to find a weak key with same bitcoin adress than it is to crack ECDSA of the public key (requiring to crack a specific public key)].

I do not actually believe these are planted backdoors, but it is our duty to consider all angles of attack, that is what security is about.

How do you make money these days if you find a fundamental security flaw in any crypto system? The prizes like RSA-Challenge numbers are symbolic and often discontinued. Even if you had the ability to generate a false transfer to your account in the fiat system, how long would it be before things get noticed. It seems like one would prefer to attack an anonymous banking system.

That's a very interesting claim considering that the a 512 bit factorization would come in at number 5 on the GNFS records page on
http://xyyxf.at.tut.by/records.html#gnfs

If you can really factor 512 bit numbers trivially, then the project would greatly benefit from your ability.
Please let me know the size and weight of an average matrix for the linear algebra step for your 512-bit factoring program.


Even using the British "billion" = million million, 4 billion operations is less than a 42 bit keyspace. Please outline the attack you have in mind.

ByteCoin

There is a lot less reason to suppose that the NSA, or anyone else, can currently generate collisions on RIPEMD160(SHA256()) then can shortcut ECDSA.

I mean— we already know how to compromise ECDSA in about 4 billion operations. It's "Just an engineering problem".

To the extent that there are basically no security implications (i.e. mapping larger public keys to smaller adresses), this reduction in combinatorial space is not dangerous. If it is not dangerous (and I probably agree) we could have simply used smaller keys (why then use secp256k1?). It does complicate matters for a potential attacker but it is certainly not advertisable as a security feature (suppose NSA can easily generate SHA256 collisions, then inspect the "public keys" for weak public keys, I dont think the signature check algorithms feature a check on how safe the key is).

In my original post I described how I feel that the original developer should have posted more design considerations, more documentation.

I can read a part of the code and concoct a reason why something is done a certain way. I can ask on the forums, but Satoshi (if it even is a single individual) is not around.

Simply coming up with an explanation does not mean it was the motivation.

At first I could only think up: an added layer of security, to only publish the public key once after which you never intend to use it again.
This made some but not enough sense to me (it is basically a cryptographic claim that it must be easier to crack secp256k1 public key, than it is to collide sha256/RIPEMD combo to generate compatible public keys, of which one might be much easier to crack)

Then I get a reply which makes a lot more sense: adresses become shorter for usability...

Then somebody elaborates my first interpretation and advertises it as a security feature...

This shows my prediction that I would like to see more DESIGN CONSIDERATIONS (think S-boxes) instead of having to resort to speculation.

The person/group that created bitcoin originally, could still elaborate their design considerations, perhaps write a book about it.

Now we have 2 reasons. Perhaps if we can find enough different explanations/speculations for why the public keys are hashed into adresses, Satoshi might feel the need to explain some of his decisions?

As others have answered, it's a more secure way of making addresses shorter.

However— it does have a theoretical security benefit:  It makes bitcoin a little less brittle against weak but semi-practical attacks on ECDSA.

E.g. imagine if bitcoin used RSA-512 for signatures today.  RSA-512 is horribly week, many people (including myself) have cracked it on their own at home.  Even so,  if this weakness was known bitcoin users could change practices to only ever send once from an address (transferring all value to a new address) and so an attack would have to be performed in the narrow window between the transmission of the spending TXN and the mining of the block (or somewhat longer if also coupled with a high hash power attack).   This is _much_ harder, and while I can trivially crack RSA-512 at home or using EC2 I don't believe I could pull off that attack.

It's likely that when there is some practical attack on ECC it will creepy up slowly— initially taking a very long time and a lot of resources. When this happens concerned bitcoin users could move to more conservative practices (especially for large stores of wealth) while the long process of upgrading bitcoin happens.

It has basically no security implications and makes coding for bitcoins only a little bit more complicated. Seems like a win-win to me.

Ah that makes complete sense, i completely forgot about the ergonomic considerations of the adress...
But the public key would take about 64 bytes * 8bit/byte=512 bits compared to 8+160+32=200 bits, thats only 2.5 times bigger, I think few people actually type over an adress, the future will probably have bitcoin adress mime types...
It still seems a bit strange to care about a factor 2.5 in adress size when the main focus is security?

It's to make the public keys shorter. You could just truncate the key and say that any key with the same start is OK, but this is probably less secure than hashing the entire key.

AFAIK it's for convenience of typing only. Satoshi envisioned direct-to-IP transactions being a lot more common than they actually are today (ie, they don't happen at all anymore). In those transactions there are no addresses and the public keys are used directly.

did you create this account just to post this topic?

If I understand correctly the bitcoin adresses are
Base58(Version+RIPEMD160(SHA256(PublicKey))+FirstFourBytes(SHA256(SHA256(Version+RIPEMD160(SHA256(PublicKey))))))

Since Base58 is easily invertible (just encoding and not encrytion) we can ignore the inner outer brackets.

Now if ECDSA is considered trusted, why hide public key with a hash?

Consider the following use case: a web shop owner decides to use a fixed Bitcoin adress. The first time he receives bitcoins nobody can determine the public key, let alone its private keys. Suppose the shopkeeper spends some Bitcoins, now the public key must be known publicly to verify the transaction. Now if the shopkeeper keeps making money on the same Bitcoin adress, the extra "layer of protection" is gone so that an entity if existant can crack ECDSA keys, can steal the money from this point on.

I try to understand bitcoin better, but from nearly all perspectives, it is just already implemented, without the design considerations being public.

Perhaps it was done for extra layer of protection for those who decide to never reuse the same adress (call them paranoids or just cautious netizens)
But that is still me speculating, a lot of bitcoins design decisions stay a complete mistery.

In the end nobody knows if backdoors were planted in any algorithms, or vulnerabilities are about to show up.

Among all the bitcoin doom scenarios, perhaps the most effective one from goverment standpoint would be to make sure to produce the first convincing p2p money system, only to pull the plug, buying time before the majority of citizens will ever try to trust such a system again.
If this theory is correct, they would pull the plug as soon as it has been the major mode of payment. This could generate a lifelong distrust with a lot of citizens.

Assuming this theory is correct what we actually have is a race: the goverment/organisation that built bitcoin to undermine or delay the arrival of real cryptocurrencies by undermining the credibility in this category of money, they want the bitcoin community to grow quickly (convince people of cryptocurrency) right in time before they pull the plug (cold shower of hard-knock reality lesson to crypto currency users). The people who actually believe in cryptocurrencies, must try to identify the built-in kill switch(es?) and adapt the code. How much time is left before the organisation decides to pull the plug?