Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Libsodium #25

Closed
rugk opened this issue Jul 9, 2016 · 5 comments
Closed

Libsodium #25

rugk opened this issue Jul 9, 2016 · 5 comments

Comments

@rugk
Copy link
Member

rugk commented Jul 9, 2016

So currently we use AES. But in which mode is it used? See e.g. how Owncloud did it, which was a problem.

The mode should also be documented in the Readme...

Because PHP does not support AES in GCM mode yet, but GCM has many advantages - the biggest one being that it is authenticated encryption so it cannot be modified.

However there is a method to use GCm mode right now, but it requires libsodium installed on the server. However libsodium is a great cryptographic tool with many features and they have a PHP wrapper.
So we could e.g. even switch to ChaCha20-Poly1305. Libsodium also allows one to use better hashing algorithms, a strong way to generate random numbers and even using the memory securly is possible.

We should evaluate whether/what/how we want to use (it).

@elrido
Copy link
Contributor

elrido commented Jul 9, 2016

PHP or the server isn't involved in the Crypto at all. We use SJCLs default, which is CCM mode (Counter with CBC-MAC). GCM (Galois Counter mode) would also be supported.

A 256 bit key is, as far as I understand the docs, automatically generated from the low entropy password using PBKDF2 and a random salt.

So we currently use AES 256 CCM.

Changing this would not break support for older pastes, as the SJCL library stores the mode in the encrypted result.

@rugk
Copy link
Member Author

rugk commented Jul 9, 2016

Ah of course. I am stupid. 😆

So I am splitting this issue as Libsodium still would maybe provide some advantages.

@rugk
Copy link
Member Author

rugk commented Jul 9, 2016

So AES issue moved here: #27

As for libsodium there are still a few things we might use:

  • Stronger hashing, which is much more resistant to brute-force attacks. E.g. here?
    Con: Especially for the traffic limiter it might be bad as it takes very long...
    Maybe we could use this?
  • Random numbers: Are at some point random numbers used in the PHP code?
  • Memory: Removing data out of memory. Are there any secrets used in the PHP code?

Of course we should use the current code as a fallback if Libsodium is not installed.

@elrido
Copy link
Contributor

elrido commented Jul 9, 2016

I would rather like to move towards the Web Crypto API. There are already many browsers supporting this and it would be a native implementation instead of a JS based one.

Regarding the other points:

  • Stronger hashing: Does not solve the problem of IPv4 only having 4 Billion addresses. This is not really a security problem, because if someone has access to your traffic limiter hashes, it is easier to access the access log directly. And the more paranoid admins could disable the traffic limiter and the logs to leave no traces.
  • Yes, the salt used for hashing the deletion HMAC and the traffic limiter entries is based on a 256 byte long random number generated using PHP's mcrypt_create_iv.
  • Depending on your PHP install the PHP processes get recycled a few times. Under normal operation variables can't be accessed between multiple executions. Apart from unset I am not aware of methods to remove data from memory in PHP. And I would not bet on its GC to actually remove it from memory.
  • I see that there are multiple options for installing libsodium as a PHP module. Which one would we need to support?

Bottom line: I currently see no need to switch to this. But please feel free to look into libsodium integration if you see a risk in the current implementation.

@rugk
Copy link
Member Author

rugk commented Jul 9, 2016

I would rather like to move towards the Web Crypto API.

That's of course a different topic, but I'd highly suggest it too.
So I created a new issue for this: #28

  • Stronger hashing: No I don't think so. I think the current solution is okay.

Yes, the salt used for hashing the deletion HMAC

This might be a good reason for libsodium there.
I make a new issue for this: #29

And I would not bet on its GC to actually remove it from memory.

That's why there is libsodium...
But it sounds in our case we don't need this.

Which one would we need to support?

It does not matter. Use it if it is installed (the use is always the same) and don't use it (fallback to native PHP) if not. We may only leave a note in the installation guide saying that one can install Libsodium and PrivateBin uses it when available.

So the only thing for libsodium would be RNG. As I created a new - more general issue - for this, I am closing this one. I think we have evaluated where we can use libsodium.

@rugk rugk closed this as completed Jul 9, 2016
@rugk rugk added this to the Next release milestone Jul 9, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants