Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A hacker stole $31M of Ether – how it happened, and what it means for Ethereum

medium.freecodecamp.org

Post reply on HN
Print view View original

21–30 of 440 posts

Re: A hacker stole $31M of Ether – how it happened, and what it means for Ethereum

#21

Post by jaibot »

cbhl wrote: post #13
dsacco wrote: post #11

Earlier quoted context omitted.

> Isn't "unbreakable" a bit of a dirty word in the security community "Dirty" is one way to put it, yes. I'd personally use something like "false god" or "blasphemy" :). "Unbreakable" is a naive way of describing cryptographic algorithms, because it preempts conversations about intractability assertions or complexity analysis...modern cryptography accepts as a premise that "unbreakable" is not a reasonable goal, whic…

One thing I've never understood about the one-time pad: How do you guarantee the third condition? Wouldn't you eventually run into the birthday problem if you sent enough messages?

Yes, so the rule is slightly misstated. Assuming that your messages are all under n bits and you always use an n-length pad, you will reuse the same pad approximately once every 2^n messages. Not coincidentally, 2^n is also the number of possible one-time pads there are, so your adversary gains no information from this fact.

Re: A hacker stole $31M of Ether – how it happened, and what it means for Ethereum

#22

Post by dmcy22 »

formula1 wrote: post #4

The developer shouldn't have executed arbitrary text. Hopefully we can just fork, blacklist the stolen transactions and pretend this didn't happen.

Don't think it'll happen. From the article:

A hard fork would be impractical–what do you do about all of the transactions that occur downstream? What about the people who innocently traded assets with the attacker? Once the ether they’ve stolen gets laundered and enters general circulation, it’s like counterfeit bills circulating in the economy — it’s easy to stop when it’s all in one briefcase, but once everyone’s potentially holding a counterfeit bill, you can’t really turn back the clock anymore.

Also, a tweet from Vitalik:

https://twitter.com/VitalikButerin/status/887782650026631168

Re: A hacker stole $31M of Ether – how it happened, and what it means for Ethereum

#23

Post by dsacco »

InclinedPlane wrote: post #9
CydeWeys wrote: post #7

Earlier quoted context omitted.

One time pad encryption is unbreakable given integrity of the pad material itself.

And, how do you build one time pad encryption into ethereum?

You can't. Or, well, you can, but it's redundant. One-time pads make sense in the Cold War, Vernam Square era of cryptography. But now that we have the internet and public key cryptography, a one-time pad implemented in Ethereum would be inane and frivolous.

Take Alice and Bob, who want to communicate confidentially. Alice doesn't know Bob personally, so she can't securely communicate the one-time pad to Bob in person. Ethereum implements public-key cryptography, so she uses Bob's public key to send him the one-time pad's key. But now we're at the chicken and egg problem: we've just witnessed secure communication, so why do we want to use a one-time pad in the first place?

Alice and Bob might respond, "so we can have perfect secrecy at some point in the future!" Which...alright, sure, let's go with it. So now to implement the one-time pad in Ethereum, Alice needs to feed a source of true randomness as a seed for a secret key which is as long as the plaintext. This is not only a genuinely hard problem, but it's grossly inefficient to encrypt something using a secret key as long as the plaintext itself. But wait - for every new plaintext, Alice has to do this true random seed song and dance each time to generate a new secret key. And every secret key ever used needs to be kept perfectly secret as well.

You really just don't want to do this. One-time pads barely made sense in pre-modern cryptography; they don't solve any practical problems in modern cryptography, and their demands require steep usability sacrifices that are quite easy to screw up.

Re: A hacker stole $31M of Ether – how it happened, and what it means for Ethereum

#25

Post by jessriedel »

cbhl wrote: post #13
dsacco wrote: post #11

Earlier quoted context omitted.

> Isn't "unbreakable" a bit of a dirty word in the security community "Dirty" is one way to put it, yes. I'd personally use something like "false god" or "blasphemy" :). "Unbreakable" is a naive way of describing cryptographic algorithms, because it preempts conversations about intractability assertions or complexity analysis...modern cryptography accepts as a premise that "unbreakable" is not a reasonable goal, whic…

One thing I've never understood about the one-time pad: How do you guarantee the third condition? Wouldn't you eventually run into the birthday problem if you sent enough messages?

Formally, the condition isn't "never use a one-time pad with the same key numbers" it's "make sure the key numbers of each pad are statistically independent of each other".

Not that it matters. The sqrt(n) birthday effect isn't sufficient to overcome the exponentially low chance of a one-time pad collision for pads of any substantial size.

Re: A hacker stole $31M of Ether – how it happened, and what it means for Ethereum

#26

Post by michaelmrose »

EdSharkey wrote: post #12

Stories like this make me consider whether programmers that engage in commerce should be forced (yes, by law) into guilds that have rigid journeyman and apprenticeship stages before the programmer gets to touch the production environment. Specialized, official, bonded developer roles need to be established. Our community cannot continue operating in the hacker mode wherever money is involved.

So now people who are self taught excellent programmers are unemployable without paying a 60,000 tax into the hands of private institutions but morons who graduated from diploma mills in countries with lax educational standards are entirely safe.

I'm also sure that nobody will act to artificially limit the supply of legally employable programmers just to enrich the few at the expense of the rest of us.

I'm also sure that such guilds wont be run by the least talented bureaucrats possible unfit to produce code themselves!

Further I guess we can just cancel open source software.

This is a terrible terrible terrible idea. The cure is worse than the disease.

Re: A hacker stole $31M of Ether – how it happened, and what it means for Ethereum

#27

Post by danblick »

EdSharkey wrote: post #12

Stories like this make me consider whether programmers that engage in commerce should be forced (yes, by law) into guilds that have rigid journeyman and apprenticeship stages before the programmer gets to touch the production environment. Specialized, official, bonded developer roles need to be established. Our community cannot continue operating in the hacker mode wherever money is involved.

What you are proposing:

(1) Is bad economics. In most cases, getting rid of occupational licensing would create wealth. To take law/lawyers as an example, see http://www.econtalk.org/archives/2011/09/winston_on_lawy.htm...

(2) Would have the practical effect of taking away my livelihood and ability to work. Would have radically altered my life, personally, for the worse.

Re: A hacker stole $31M of Ether – how it happened, and what it means for Ethereum

#28

Post by hn_throwaway_99 »

lowpro wrote: post #6
icelancer wrote: post #2

>"It’s important to understand that this exploit was not a vulnerability in Ethereum or in Parity itself." I mean.... I guess. It's a feature of Ethereum, if we're going to weasel around.

I know I'm this situation the dev made a simple mistake, but I wonder if Ethereum is safe as a system assuming developers will make many mistakes, and those mistakes will happen more often as more complicated contracts are written. At some point I wonder if the idea of smart contracts is better than a traditional system, since they seem prone to developer error due to complexity.

> I know I'm this situation the dev made a simple mistake, but I wonder if Ethereum is safe as a system assuming developers will make many mistakes, and those mistakes will happen more often as more complicated contracts are written.

This will probably come off as being assholish, but I honestly don't mean it to be: you should read the rest of the article. It actually covers this topic in depth and has good thoughts on this fundamental issue with smart contracts.

Re: A hacker stole $31M of Ether – how it happened, and what it means for Ethereum

#29

Post by dsacco »

jessriedel wrote: post #25
cbhl wrote: post #13

Earlier quoted context omitted.

One thing I've never understood about the one-time pad: How do you guarantee the third condition? Wouldn't you eventually run into the birthday problem if you sent enough messages?

Formally, the condition isn't "never use a one-time pad with the same key numbers" it's "make sure the key numbers of each pad are statistically independent of each other". Not that it matters. The sqrt(n) birthday effect isn't sufficient to overcome the exponentially low chance of a one-time pad collision for pads of any substantial size.

> Formally, the condition isn't "never use a one-time pad with the same key numbers" it's "make sure the key numbers of each pad are statistically independent of each other".

And to expand on this - this is why it is imperative that a source of true randomness is used as a seed. Pseudorandomness cannot (by definition) satisfy statistical independence.

If you don't have a source of true randomness, you've just implemented a stream cipher, not a one-time pad.

Re: A hacker stole $31M of Ether – how it happened, and what it means for Ethereum

#30

Post by lowpro »

hn_throwaway_99 wrote: post #28
lowpro wrote: post #6

Earlier quoted context omitted.

I know I'm this situation the dev made a simple mistake, but I wonder if Ethereum is safe as a system assuming developers will make many mistakes, and those mistakes will happen more often as more complicated contracts are written. At some point I wonder if the idea of smart contracts is better than a traditional system, since they seem prone to developer error due to complexity.

> I know I'm this situation the dev made a simple mistake, but I wonder if Ethereum is safe as a system assuming developers will make many mistakes, and those mistakes will happen more often as more complicated contracts are written. This will probably come off as being assholish, but I honestly don't mean it to be: you should read the rest of the article. It actually covers this topic in depth and has good thoughts…

Honestly I read the comments first, I enjoy and learn from HN comments often more than the original article. Thanks for pointing out I was missing context.
Post reply on HN