[jstanley]

I'm aware it's only 190 bits of keyspace. I mentioned this in my blog post[0], and would in fact be more likely to decrease it than increase it, in order to make the URLs shorter. I don't think it's a problem, but am interested in being proven wrong.

It's using CBC mode.

[0] http://incoherency.co.uk/blog/stories/hardbin.html

EDIT:

> And that would be in the best case, if it were sampling uniformly from the distribution - it is not.

Can you please point out how it's not? It's intended to sample uniformly. It would be non-uniform if it were "randombytes[i] % alphabet.length".

EDIT2:

I see now how it's non-uniform. 256 values in randombytes doesn't map 1:1 onto 62 values in alphabet. I will fix this tonight, thanks for pointing it out.

[garrettr_]

> I'm aware it's only 190 bits of keyspace. I mentioned this in my blog post[0], and would in fact be more likely to decrease it than increase it, in order to make the URLs shorter. I don't think it's a problem, but am interested in being proven wrong.

I understand that you're trying to balance the tradeoff between security and usability here, which is tricky. If quantum computers are part of your threat model, remember that Grover's algorithm provides a quadratic speedup for brute-forcing a symmetric key, so 2^190 would become 2^95 against a quantum adversary. Personally I prefer the margin of safety provided by using a full-strength 256-bit key :)

> It's using CBC mode.

Phew! That would've been truly catastrophic.

[CiPHPerCoder]

CBC mode isn't exactly a saving grace here, since it's unauthenticated.

[jstanley]

The code and data are shipped together out of IPFS. If you don't trust the data, you don't trust the code anyway, so it makes no difference whether the data is authenticated.

[CiPHPerCoder]

First, read this: https://tonyarcieri.com/all-the-crypto-code-youve-ever-writt...

Second, what is the threat model where you trust IPFS but still need to encrypt client-side? Unauthenticated CBC mode totally defeats the point of encryption, but encryption totally defeats the point of trusting IPFS.

Why not just-- crazy idea!-- use authenticated encryption even if you trust IPFS?

[jstanley]

I don't think you understand IPFS.

If you trust your IPFS node, you know that you're retrieving the correct content. You still don't want others to be able to read it.

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.

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

[erikbye]

You mean truly catastrophic if it was codebook?