[CiPHPerCoder]

A lot of crypto engineering problems go out the window if you just trust the messages you're receiving. That doesn't mean it's okay to use unauthenticated encryption in 2017.

> EDIT: (Since HN won't let me reply to you): There is no mode of operation in which it's safe to use Hardbin without trusting the messages you're receiving, authenticated encryption or not.

> Since the code and the data are both served out of IPFS at the same time, checking the message integrity is pointless. If somebody controlled the IPFS node you're using and wanted to do something malicious, they could more easily just add some code to ship the decryption key off to a remote server than perform an attack on the unauthenticated encryption.

http://www.cryptofails.com/post/121201011592/reasoning-by-le...

[jstanley]

Your HN profile describes you as a Cryptography Engineer, and I'm sure that's true.

You're just not presenting a convincing argument for why it's OK to trust the code but not the data when they're both served out of the same place. Do you understand that they're both served from the same place? If somebody can modify the data, they can just as easily modify the code and make it do whatever they want. Do you understand that?

You're just linking me to things other people have written instead of presenting a persuasive argument. So I'm not going to bother doing what you say. Sorry.

[CiPHPerCoder]

If you call your project "the most secure X" and you're doing something related to X in a very sub-optimal way (i.e. not using AEAD modes), what happens if someone uses your code as a reference point for writing their own crypto for a protocol that doesn't use IPFS? What if, instead of a specific instance of copying code out of context, people learn bad habits from your code and then defend their choices until they're blue in the face because they copied it off of "the most secure" reference implementation?

A lot of problems, many unforeseeable, are easily prevented by using authenticated encryption.

> You're just not presenting a convincing argument for why it's OK to trust the code but not the data when they're both served out of the same place. Do you understand that they're both served from the same place? If somebody can modify the data, they can just as easily modify the code and make it do whatever they want. Do you understand that?

Yes, and this has been covered to death to the point that I'm sick of hearing it: https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

One could easily build a Chrome extension that still uses your IPFS gateway for shipping ciphertext. Now you've got the code at rest (so transport-layer integrity doesn't undermine the code being executed), but the data is still reliant on IPFS.

Let's do a thought experiment.

First, move your code to a Chrome extension (which makes the code immutable), then give the attacker an enormous amount of power. For a moment, assume that an attacker can totally defeat IPFS. It doesn't matter how they do it. Is your application-layer cryptography protocol still secure?

[jstanley]

> First, [completely change your application and its core security assumptions]. Is your application-layer cryptography protocol still secure?

No.

[CiPHPerCoder]

If your application-layer cryptography protocol is not secure in isolation, what argument do you have against making it secure in isolation?

[jstanley]

I have none. I'd merge a sensible pull request.

But characterising it as a huge security flaw is disingenuous. It's neither here nor there.

[CiPHPerCoder]

I'm characterizing it as a protocol/design flaw in something that bills itself as the most secure X, sure, but I haven't done anything to describe it as "huge".

Are you being needlessly defensive?