[FUTURE] Future Enhancement: Libsodium for Illuminate\Encryption

[paragonie-scott]

I've been working on a pure PHP implementation of the cryptography features offered by libsodium. It rests at paragonie/sodium_compat.

One important detail: sodium_compat opportunistically uses the PHP extension in PECL if it exists. Additionally, sodium_compat includes a lot of built-in design decisions to reduce the risk of cache-timing vulnerabilities.

The algorithms implemented include:

• Symmetric Cryptography
  • HMAC-SHA-512-256 (crypto_auth())
  • Xsalsa20-Poly1305 (crypto_secretbox())
• Asymmetric Cryptography
  • Ed25519 (EdDSA over Curve25519) (crypto_sign())
  • X25519 (ECDH over Curve25519) (crypto_scalarmult(), crypto_kx())
  • X25519-Xsalsa20-Poly1305 (crypto_box(), crypto_box_seal())
• Other Cryptography
  • BLAKE2b (crypto_generichash(), etc.)
  • SipHash-2-4 (crypto_shorthash())

However, sodium_compat has yet to be audited by an independent third party. I'm filing an issue now to kick off any planning or discussion necessary to make sodium_compat available to Laravel users as soon as it gets audited. (I'd also like to gauge interest in seeing this in a future Laravel release.)

Sodium_compat v1.0.0 will only be tagged after it has passed said cryptography audit, so please don't adopt it until that has come to pass. See the release notes for sodium compat v1.0 for why we deviated from this plan.

[paragonie-scott]

Hi again.

Sodium_compat 1.0 is out, if anyone wants this to happen.

[morloderex]

@paragonie-scott I should point out that sodium extension will be in core for php version 7.2 :)

[barryvdh]

I think it's very unlikely Laravel will be making any major changes like this in 2017. We've still got users recovering from the migration away from mcrypt. If Laravel does switch in the future, I think it'd be important that the library is stable and mature.

As the sodium extension has been moved to the PHP core, would it be safe to assume that this API itself is stable enough, perhaps not the fallback library?

The default AES-256-CBC cipher is not support by Sodium right? So that means that all data has to be converted (again). But the longer we wait, the bigger the problem.

Would it be an idea to add a crypto 'driver', like openssl or sodium, so both can be used together. Or atleast can be deprecated in advance?

[morloderex]

@taylorotwell What's your take on this?

[paragonie-scott]

The default AES-256-CBC cipher is not support by Sodium right? So that means that all data has to be converted (again). But the longer we wait, the bigger the problem.

The existing construction (AES-256-CBC + HMAC-SHA-256) is actually fine (assuming your server has proper hardware support), so adopting libsodium shouldn't require deprecating OpenSSL.

Would it be an idea to add a crypto 'driver', like openssl or sodium, so both can be used together. Or atleast can be deprecated in advance?

That would be fine.

[taylorotwell]

I would be fine with PRs for this kind of thing.