Third Party Cryptography Audit #8

Closed
paragonie-scott opened this Issue Dec 29, 2016 · 9 comments

Projects

TODO in Version 1.0.0

3 participants

@paragonie-scott
Member

After I'm confident that this library is...

  • Secure, even against sophisticated attackers
  • Correctly implemented
  • Adequately pedantic about types, etc.
  • Perfectly API compatible with the relevant libsodium features we're bringing over

...then the next step will be to obtain an independent third party security assessment.

@paragonie-scott
Member
paragonie-scott commented Jan 17, 2017 edited

So far the plan is as follows:

  1. Get quotes/estimates from a few companies qualified to perform this sort of audit.
  2. Figure out a way to pay for it.
  3. ????
  4. VERIFIABLE SECURITY!

I'll update this thread later when I have even rough estimates on hand.

@paragonie-scott
Member

After hearing back from four different companies on this, the total cost is going to be in the $30,000 to $50,000 range.

One quoted a bit lower, but they don't specialize in cryptography and might not know what they're getting into.

Two didn't provide a time estimate, but rather a day-rate (which is, I guess, pretty standard), so their contribution to the total cost estimate is based on the time estimate provided by the other two.

None of the numbers given are totally unexpected.

@paragonie-scott
Member
paragonie-scott commented Jan 19, 2017 edited

Proposed Auditing Scope

These are the sort of questions I'm hoping can be answered.

  • Does our PHP code contain any addressable bad practices?
  • Does the PHP interpreter introduce any exploitable side-channels (e.g. integer multiplication)?
    • PHP 5.6 on 32-bit Linux is safe?
    • PHP 5.6 on 64-bit Linux is safe?
    • PHP 7.0 on 32-bit Linux is safe?
    • PHP 7.0 on 64-bit Linux is safe?
    • PHP 7.1 on 32-bit Linux is safe?
    • PHP 7.1 on 64-bit Linux is safe?
    • PHP 5.6 on 32-bit Windows is safe?
    • PHP 5.6 on 64-bit Windows is safe?
    • PHP 7.0 on 32-bit Windows is safe?
    • PHP 7.0 on 64-bit Windows is safe?
    • PHP 7.1 on 32-bit Windows is safe?
    • PHP 7.1 on 64-bit Windows is safe?
    • Although PHP < 5.6 is worth considering overall since they're tentatively supported, the first run should focus on supported versions of PHP. Argument: If you're running PHP < 5.6 in 2017, you don't care about security, so we shouldn't burden the auditors to analyze these version too.
  • Are there any inputs for which our implementations produce incorrect results?
  • Are there any concerns about int/float conversion? (Timing leaks, etc.)
  • Does PHP's use of signed ints everywhere pose any security risk?
@AshleyPinner

Argument: If you're running PHP < 5.6 in 2017, you don't care about security

Counter-argument: OS vendors are backporting security fixes to versions < 5.6, so they should, IMO, be given due care for checking this library in.

@paragonie-scott
Member
paragonie-scott commented Jan 23, 2017 edited

Counter-counter-argument: Those OS vendors aren't funding the audit.

If this statement becomes false, then the scope can be widened.

@AshleyPinner

Counter-clockwise-argument: Reach out to Ubuntu/RHEL and see if they're willing to chip in?

@paragonie-scott
Member
paragonie-scott commented Jan 23, 2017 edited

If you know any contacts at either organization, can you link them to this Github issue? I'd rather these discussions happen out in the open as much as possible.

Also, that will probably double the time needed, and therefore the cost of the audit.

@defuse
defuse commented Jan 23, 2017

The scope looks good to me.

The only thing I would add is: "Are there kinds of automated tests or tools we should be running against the codebase to help uncover bugs in future versions?" They usually build some sort of custom tooling/tests to help with the audit, so I would see if it's possible to get some of the code they happen to write (even if it's shitty and needs to be fixed up), or at least get their opinion on what kinds of additional automated tests would be most effective.

@paragonie-scott
Member

The purpose of sodium_compat was largely motivated by a desire to make WordPress more secure against its own infrastructure, which was in turn motivated by ethics. If you could prevent 27.5% of the Internet from getting erased or conscripted into a botnet just because one server got compromised, almost anyone would say, "I should do that."

However, given that WordPress will not be considering signing their updates any time soon, I don't see any point in asking the PHP community to reach into their own wallets to cover the cost of something that will currently not help the situation.

If someone else wants to pursue collecting the funds and hiring an auditor for this library: Feel free.

I'm still not tagging v1.0.0 unless this is audited by a team of crypto experts. If that never happens, then neither will v1.0.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment