
Hardbin: secure encrypted pastebin - natejackdev
https://hardbin.com
======
jstanley
Hi all, I made this.

The reason it is described as "the world's most secure" is because both the
code and the data are served from IPFS. IPFS is a content-addressable storage
system, so as long as you access it over an IPFS gateway you trust (running
one locally is the best way), you know the code and data haven't been meddled
with.

It degrades to the same security model as ordinary encrypted pastebins when
accessed over a gateway you don't trust (e.g. the hardbin.com public gateway).

This article (was on HN a couple of weeks ago) gives a good overview of IPFS:
[https://ipfs.io/blog/24-uncensorable-
wikipedia/](https://ipfs.io/blog/24-uncensorable-wikipedia/)

And you can learn how to set up a local IPFS node here (it's super duper easy
- copy binary into /usr/local/bin, ???, profit):
[https://ipfs.io/docs/getting-started/](https://ipfs.io/docs/getting-started/)

So, please, don't knock it before you understand it :)

EDIT: Although I did try to explain it thoroughly in the About section, I do
take responsibility for not making it easy enough to understand.

IPFS is pretty new technology, and presents a very different set of
assumptions compared to traditional web apps.

If you didn't understand it at first but you do understand it now, please let
me know what the key piece of information was that made it "click" so that I
can put more emphasis on that next time.

~~~
garrettr_
A quick look at the source code shows the generate_key() function [0] to be
insecure. It generates 32 random bytes (good, that's what you need for an
AES-256 key), but then it uses those random bytes to sample from a
distribution which only has 62 characters. This significantly reduces the
security of the key, from 256 bits of entropy to ~190 bits (log2(62^32)). And
that would be in the best case, if it were sampling uniformly from the
distribution - it is not.

I recommend reading Section 9.7 of Cryptography Engineering [1] to understand
why choosing random elements from a set is harder than it seems. A good
example of a similar bug is the nasty bug in Cryptocat's PRNG from 2013 [2].

I assume this step was done so the AES key could be included in the URL
fragment, since a set of random bytes may not be url safe. I recommend feeding
the random bytes of the key directly into the underlying cryptographic
functions, and using a urlsafe encoding at a higher level when necessary.

Also, it appears you are using AES [3], a block cipher, but I cannot figure
out what block cipher _mode_ you are using. I'll have to dig into the CryptoJS
code a little more to see what it defaults to, but I have a sinking feeling
that it's ECB, which is completely insecure. Dan Boneh's Crypto I course on
Coursera is a good way to learn the basics of block cipher modes.

[0]:
[https://github.com/jes/hardbin/blob/c77c2d7eb93586e0e009ea4b...](https://github.com/jes/hardbin/blob/c77c2d7eb93586e0e009ea4b390b75fa3d7c750f/js/hardbin.js#L13-L25)
[1]: [https://www.amazon.com/Cryptography-Engineering-
Principles-P...](https://www.amazon.com/Cryptography-Engineering-Principles-
Practical-Applications/dp/0470474246) [2]:
[https://nakedsecurity.sophos.com/2013/07/09/anatomy-of-a-
pse...](https://nakedsecurity.sophos.com/2013/07/09/anatomy-of-a-pseudorandom-
number-generator-visualising-cryptocats-buggy-prng/) [3]:
[https://github.com/jes/hardbin/blob/c77c2d7eb93586e0e009ea4b...](https://github.com/jes/hardbin/blob/c77c2d7eb93586e0e009ea4b390b75fa3d7c750f/js/hardbin.js#L5-L7)

~~~
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](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...](https://tonyarcieri.com/all-the-crypto-code-youve-ever-written-is-
probably-broken)

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...](http://www.cryptofails.com/post/121201011592/reasoning-by-lego-the-
wrong-way-to-think-about)

~~~
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...](https://www.nccgroup.trust/us/about-us/newsroom-and-
events/blog/2011/august/javascript-cryptography-considered-harmful/)

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?

------
tptacek
_The world 's most secure encrypted pastebin, guaranteed_

What could possibly go right?

~~~
airza
finally, i can combine the security of the browser with the convenience of
seeding torrents!

~~~
nickpsecurity
Great phrasing lol...

------
Veratyr
It's very interesting but the title seems a little hyperbolic as there are
numerous caveats (from the "About" section):

\- "Note that the security benefits of hardbin only apply when accessing it
over a local (or otherwise trusted) gateway. If you access it over a gateway
that you do not control, then the security model degrades to be equivalent to
that of traditional encrypted pastebins."

\- "The content will need to be pinned to make sure it stays around for long
term (the same as any content stored in IPFS)." (though this doesn't impact
the merits of its encryption)

\- "You need to make very sure to use a known-good version of the code when
creating pastes, as it would be trivial to create a malicious version that
looks identical. The best thing to do is write down the hash the first time
you use it, and always use the same hash. If you want to upgrade to a new
version of the software, you'll need to update your hash."

\- "I don't recommend using hardbin for highly critical stuff as the code has
not been thoroughly audited by anyone but me."

The last is perhaps the most worrying thing.

~~~
jjguy
These are all standard security concerns. Anyone who brings you something
similar and does not have a long list like this is in marketing or sales.

~~~
avaer
If these are all standard security concerns, doesn't that make this a standard
security pastebin?

I think the point is that it's an extraordinary claim with unextraordinary
evidence.

~~~
true_religion
Does anyone remember when the phrase "extraordinary claims require
extraordinary evidence" was used regards to truly extraordinary claims? Like
room-temperature superconductors. Or cold fusion. Or that aliens were
responsible for the birth of human civilization?

This is not an extra-ordinary claim. This is the claim of "I made secure
software, and I reckon it's pretty good" wrapped up in the extremely ordinary
common English-language hyperbole of calling something 'the best' when there
is no way to know if it is, or prove it one way or the other.

~~~
bradknowles
However, the use of hyperbole transforms the claim into an extraordinary one.

That is, unless you consider hyperbole to now be standard, in which case we
have to likewise transform the original material being quoted.

Otherwise we're comparing apples to super duper hyper bestest-ever oranges.

~~~
true_religion
Yep, I consider the use of hyperbole to be a standard colloquialism in this
case, not a claim that they did an in-depth experimental study of pastebins
and have compiled a report for peer review.

------
ams6110
Why not just gpg-encrypt and ascii-armor your text for the recipient(s), and
put it in an ordinary pastebin?

~~~
nickpsecurity
Exactly. Some kind of proven cryptosystem implemented with great UI on
untrusted, online storage. Options to do it over various transports with HTTPS
a default that most users can tolerate. This one does all this fancy stuff
which has so much complexity in its trusted computing base (TCB) that it's
likely to get smashed somehow. That's assuming the protocols and interfaces
are correct which is often not true.

Plus, the "world's most secure" would probably use HSM's at some point with
real ones at server and smartcards w/ open standards at user side. I know a
guy working to commercialize stuff like that. Stuff running on a vanilla stack
w/ unvetted code and non-tamper-resistant hardware isn't most secure anything.

------
DonbunEf7
Why not just use Tahoe-LAFS? Then you don't have to trust the server to get
the security guarantee!

~~~
tangent128
If you access hardbin through your own, local, IPFS gateway, then you don't
have to trust a third-party server.

I assume if you used a third-party Tahoe-LAFS gateway instead of running your
own, you would have the same security risks.

------
mproud
I was always a fan of paste.ee, but totally welcome more encrypted paste web
sites.

------
qguv
For a simpler secure pastebin, try [https://sptpb.pw](https://sptpb.pw).

~~~
unsignedint
Also another alternative.

[https://privatebin.info](https://privatebin.info)

------
pizza
Pastebins tend to get caught up fast in very dodgy/shady/even illegal
content.. just a heads up

~~~
arianvanp
But he is not hosting anything. It's a self-hosted peer-to-peer pastebin
storage system

------
sametmax
Time to add IFPS to 0bin.net then ?

