Source
r/Iota•
ColdDayApril

One easy explanation why the DCI is horribly wrong.

If you followed https://twitter.com/c___f___b/status/967812658899668992 you may have noticed that Come-from-Beyond repeatedly asked this same, simple yes or no question over and over again, yet all cryptographers refused to answer. Why?

This is the answer:

https://pbs.twimg.com/media/DW1hHUWX0AAk5qP?format=jpg

EU-CMA requires the challenger to generate a random private key. But in the attack provided by the DCI, Ethan did not randomly generate it. He cherrypicked it. Because forging the signature of a bundle would only work on a negligible number of private keys.

So, according to the rules of EU-CMA, Ethan did not break Curl. There was no evidence provided that his attack would work to steal money on any randomly chosen private key.

That's why everyone refuses to answer, because by doing so, they would admit defeat.

Dear DCI, you just got busted. End of the story, let's move on.

Posted Feb 26, 2018, 11:19 AM UTC · edited

13349
Hyetigran•

rekt!

Thanks for making this easy to understand for the rest of us.

24
cybergibbons•

It works on a randomly chosen private key though: https://twitter.com/spudowiar/status/967858633680850944

11
philcutz•

so.. cfb got rekt? I am unable to follow all the back and forth. Maybe someone want to explain me who is in the lead of their claims

1†
cybergibbons•

Not keen on the term "rekt"...

But anyway, CFB didn't state if it was or wasn't possible. He just kept saying things like this:

"EU-CMA game requires to choose the private key randomly. Were the keys of those two examples from the paper chosen randomly? If yes, why do you think so?"

So he was inferring that the original collisions didn't have a randomly chosen private key. I don't know why this is, as it was quickly demonstrated that it does work for a random key.

What has been demonstrated is that two different messages with the same hash can produce the same signature for a random seed. There is no proof that this is the case for all seeds, but it works for all seeds tried so far.

What CFB may be saying (but isn't clear) is that you can't create two colliding bundles using addresses generated by a random seed. This doesn't seem to be the case - if you can choose the messages (it is CMA, after all), you can always get a collision.

10
Apocrypton•

I can still only see this comment, not your replies for some reason but I read it in your history, I'll just reply to this one again. Very odd.

Thanks for taking the time to lay it out, I think your right, much of the confusion seems to stem from misunderstandings about what the "vulnerability" or "exploit" actually does. If I'm understanding you correctly, it's an attack vector that most likely hasn't been fully exploited as far as we know, but is still an issue that could be a potential problem, especially when they pull the Central Coordinator. It's interesting that CfB acknowledged this is possible in that twitter thread, just that currently it can't be used to waste or spend coins. Up until now I thought they disagreed that it was possible at all.

In your opinion is this something that can be updated or is an integral part of the Tangle? I know your not affiliated with them, I just haven't had a chance to talk to someone that seems to understand what's going on. Thanks.

7
cybergibbons•

(not sure if I have been banned or something?)

Your understanding matches mine. The whole process of disclosure became adversarial due to personality. I've been on both sides of bad disclosures many times now and it's a familiar pattern.

It's not integral to the Tangle IMHO, Keccak likely fixed it.

6
Apocrypton•

I responded previously asking why it hadnt been exploited, but Reddit is going crazy for me, it wouldnt display your comment and it showed my post as a double post, I deleted one and both disappeared. I looked up your reply from your username though.

So its not so much that it can be exploited currently, it's just that there is a vulnerability which could potentially be a weak point down the line?

3
cybergibbons•

Two things (if Curl-P continued to be used):

  1. It could be exploited further down the line due to code changes.
  2. There could already be another path to exploit it that we don't know about.
  3. CFB stated that he could attack copy-cat systems using Curl-P using collisions and that the COO prevented that from working. What happens if the COO fails?

2 has happened a lot in the past, so cryptographers urge the use of fundamentally secure primitives.

4
cybergibbons•

So, to be very clear, the thought process works like this:

Was the proposed attack facilitated by the use of Curl-P? Yes.

Is this attack now not possible with Keccak? Yes.

Is IOTA now more secure? Yes.

Was IOTA less secure with Curl-P? Yes.

Therefore IOTA was vulnerable. It had a vulnerability. That's what is being claimed, and oddly is being denied.

2
Apocrypton•

That's what I gathered from the emails as well, they addressed the issue in the Aug snapshot, they discussed the transition to Keccak in letters #42 through #51. I just wasn't clear if this vulnerability persisted past that point.

Thanks for helping clear some things up.

2
crypto_antredditor for < 1 month•

So he was inferring that the original collisions didn't have a randomly chosen private key. I don't know why this is, as it was quickly demonstrated that it does work for a random key.

a hash function doesn't have the concept of a key (until you key it). a collision here is without keys. notice how those two messages hash to the same thing ... no key involved anywhere.

What has been demonstrated is that two different messages with the same hash can produce the same signature for a random seed. There is no proof that this is the case for all seeds, but it works for all seeds tried so far.

is that because it's not exactly a chosen-message attack but that there's some validation on messages, not every chosen message attack will work in practice. but that's got nothing to do with how signature keys are generated ...

2
cybergibbons•

Yes, a non-keyed hash function doesn't have a concept of a key. So what do we infer from CFBs messages? It's either the seed used for signing (which is what is shown here, it clearly doesn't have impact) or the seed used for address generation (and we have lots of collisions already).

It could be the case that there is no way to produce pairs colliding messages with all addresses/keys, but it's highly unlikely given the examples.

2
[deleted]•

[deleted]

1
cybergibbons•

This is just an misunderstanding of the term "vulnerability".

In information security, we consider something vulnerable if a change in the software would reduce the chance of an attack succeeding. There doesn't need to be a full exploit there for it to be classified as a vulnerability.

So say we have this situation at the present time:

Safe code -> Hash function which allows collisions

At this moment, we can't reach the vulnerable hash function to create a full exploit.

But all it would take is altering the code:

Unsafe code -> Hash function which allows collisions

And we then have the ability to carry out an exploit.

The problem with cryptography is the interactions between components can be really complex, and we don't understand them well. So although you can say "collisions in Curl don't matter because you can't exploit them this way", it's hard to say "collisions in curl don't matter at all". Especially given it is still used in certain places in the code - not just signatures.

4
Apocrypton•

Good summary, its hard to keep up with this argument haha. I think David is right, its time to just move on.

1
fortenforge•

Sure, DCI (and the cryptography community at large) are in the lead. cfb (and the IOTA community at large) are losing.

-3
tehbagend•

Do I understand this correctly?:

The DCI were able to show that for certain addresses collisions can be created but for any randomly selected address there is a negligible chance that a collision can be created?

So if I said to an attacker here is my address "CFBISANAIFROMTHEFUTURESENTBACKTOBRINGFORTHTHEMETHODOFHISOWNCREATION...9999" there is no guarantee that the attacker could create a valid collision?

What do you make of this claim? https://github.com/saleemrashid/iota-eu-cma

4
cybergibbons•

The attack is chosen message, so the attacker gets to choose both messages.

This is a massive issue in certain systems, such as SSL certificates, where you don't even need to coerce someone to sign a certificate: http://www.win.tue.nl/hashclash/rogue-ca/

It's less of an issue in Iota, as it's not normal for a user to sign arbitrary data. It is however possible for it to happen, and there are no other controls in place to stop two bundles with the same signatures being validated by two different nodes.

3
tehbagend•

Nodes don't confirm bundles. The Coo does, and it would only accept the first one submitted.

4
cybergibbons•

I should have used the word validated.

Regardless, it has now become a race between two transactions with the same signature.

1
durchgerutscht•

It's less of an issue in Iota, as it's not normal for a user to sign arbitrary data. It is however possible for it to happen [...]

How is this possible to happen?

The sole purpose of an address private key is to be used to sign a one-time spend from that address. Why would a wallet allow to ignore that purpose, only for signing some arbitrary data specified by a random person?

Why not giving it a globally accessible seed export functionality instead?

1
cybergibbons•

The way that we work in cryptography is to look for weaknesses.

Imagine you have a black box containing the private seed. No one can access the seed. Alice can request that it signs messages.

Eve coerces Alice or otherwise manages to cause the black box to sign an arbitrary message.

Eve now has a signature. She did not require access to the key and does not have access to the key.

It's false to say the attack is equivalent to leaking the private key.

2
durchgerutscht•

Well, you are implying that the blackbox's only purpose is to sign any data that's given by Alice.

Now, what if we make the whole thing even more secure by letting the blackbox completely control the wallet with the only available command being 'send x amount to address y and return signed data'.

Now even if Eve can persuade Alice to do anything she wants, the blackbox doesn't allow signing Eve's data.

That makes perfectly sense in the context of IOTA transactions because there is no use-case in signing other arbitrary data.

1
faintingoat•

Ethan Heilman is a Bitcoin-Core contributor who was fast to broadcast his mistake. He should have been patient and at least a bit more cooperative with Sergey Ivancheglo.

2
[deleted]•

[deleted]

1
xenomorph113•

REKT!

0
Godless3•

Here's the EU-CMA proof https://github.com/saleemrashid/iota-eu-cma

CfB doesn't know what he's talking about. Curl has been broken, CfB thinks this doesn't matter because it is theoretically "hard" to steal funds by this method.

-5†
FutureIsHere123•

lol this ^ idiot is here for months..going from post to post and trolling..fucking idiot with no life..gtfo!

8
Godless3•

LMAO. The post says there is no EU-CMA proof. There is and you can see it yourself. That isn't trolling, it's science. Go back to bed.

-2†
FutureIsHere123•

Dude if u are so cleaver put ur real name and put 12,5 btc on cfb’s bet and proove him wrong thats all what is asked..but ofc none of u cant do that so its easier to open fake acc “iota fan” and talk shits for months..look at posts of this guy and u will see what I’m talking about..

4
Godless3•

CfB should make it a bounty, not a bet. This isn't a game of poker where you can bluff your opponents by betting large amounts of money. CfB is an amateur, the academics say it's been broken and have provided the code to prove it. It is up to CfB to prove them wrong not the other way round. That isn't even my point, this post says there is no EU-CMA-GAME proof and THERE IS. That is all.

-5