New install generating weak paste encryption keys

[tygs]

New install generating weak paste encryption keys

[manvari]

zerobinpaste can use different key sizes, even though the default size is 48 bits. This means that 0bin does support different key sizes; the code needs to be looked into to find what actually handles that.

EDIT: it's sjcl: the relevant code is here and is pretty well highlighted/explained in this commit.

[securitygeneration]

Thanks iceTwy, I missed that bit of the script. The default value should really be "zerobin.makeKey(256)", otherwise people are running a vulnerable install out of the box. If anything, this should be made clear in the FAQ or README.

[sametmax]

Doh, so much for having several accounts :(

Let's say nobody has seen anything ^^

So, make the PR, I'll accept it.

[manvari]

I'm all for it, but there's one thing that puts me back: a 256-bit key is unbelievably long, and the resulting URL will also be long. This isn't exactly convenient if you intend to share the URL (which is the whole point of having a paste service).

[securitygeneration]

If you want to share the URL, use a URL shortener. Security > Convenience ;)

[sametmax]

Or just change the settings in your own instance.

Le mar. 08 avril 2014 17:34:58 CEST, securitygeneration a écrit :

If you want to share the URL, use a URL shortener. Security >
Convenience ;)

—
Reply to this email directly or view it on GitHub
#62 (comment).

[manvari]

@securitygeneration: "url shortening was a fucking awful idea" - ArchiveTeam

[securitygeneration]

@sametmax I did. But am pointing out that you talk about encrypting using AES256 when in reality you are using AES48. At the very least inform the users.

@iceTwy I agree that URL shortening was a bad idea from the greater web's perspective, but for pastes whose URLs will expire within a matters of days/months, it largely doesn't matter.

[sametmax]

@securitygeneration, I meant that for @iceTwy
https://github.com/iceTwy. I agree we should provide a better security
by default and let people set up a smaller key for convenience.

In fact, it was the original settings, then it got changed. I don't
remember what was the rational, but it does seem logical to reverse it.

Le 08/04/2014 17:40, securitygeneration a écrit :

@sametmax https://github.com/sametmax I did. But am pointing out
that you talk about encrypting using AES256 when in reality you are
using AES48. At the very least inform the users.

@iceTwy https://github.com/iceTwy I agree that URL shortening was a
bad idea from the greater web's perspective, but for pastes whose URLs
will expire within a matters of days/months, it largely doesn't matter.

—
Reply to this email directly or view it on GitHub
#62 (comment).

[Natim]

We should definitely reverse this, the key should be 32 bytes which is 256 bits, we should also address comment #43 so we can have both security and shorter urls.

[sametmax]

Ok, we are starting to get some activity here :)

Any PR ?

Le ven. 20 juin 2014 13:54:22 ICT, Rémy HUBSCHER a écrit :

We should definitely reverse this, the key should be 32 bytes which is
256 bits, we should also address comment #43
#43 so we can have both
security and shorter urls.

—
Reply to this email directly or view it on GitHub
#62 (comment).