OPRF(P-384, SHA-512) vs OPRF(P-384, SHA-384)

[FredericJacobs]

Is there a compelling reason to use SHA-512 with P-384 as opposed to matching P-384 with SHA-384 like is commonly done for ECDSA signatures for instance? The number theoretical assumptions for ECVOPRF with P-384 make it such that you get below 192-bit of security, so is it warranted to require SHA-512 over SHA-384?

[chris-wood]

This was done for alignment with the corresponding hash-to-curve suite, which uses SHA-512 with P-384. It's probably reasonable to update that suite, since SHA-384 meets the criteria needed for a 192-bit level. @kwantam, I'm not aware of any existing uses of the P384_XMD:SHA-512_SSWU_RO_ suite, so perhaps we can just update this in both places?

[jedisct1]

Certainly not a bad change to make now, before applications start using P-384 with SHA-512.

[kwantam]

My vote would be to stick with SHA-512 rather than to move to SHA-384, for two reasons:

• SHA-512 is, in general, much more widely deployed than SHA-384.
• There's no speed advantage to SHA-384: it's just SHA-512 with a different IV and a truncated output.

But on the other hand, it looks like switching to SHA-384 in hash-to-curve doesn't really hurt anything---both of the P-384 suites end up using the same number of hash invocations in expand_message whether we use -384 or -512. And since it's apparently the case that P-384 is commonly paired with SHA-384, maybe SHA-512's general deployment level is beside the point.

In reality this is a pretty low-stakes decision given how infrequently P-384 is used; my recollection is that P-384 implementations tend to be slow.

[kwantam]

One more thought, in favor of SHA-384: we switched the '25519 suites from SHA-256 to SHA-512 because that matches up well with EdDSA. So it stands to reason that we would also match up the P-384 suite with the existing signature standard.

[chris-wood]

Performance-wise, here's a quick benchmark of SHA-384 from BoringSSL:

✗ ./tool/bssl speed -filter SHA-384
Did 2917000 SHA-384 (16 bytes) operations in 1000173us (2916495.4 ops/sec): 46.7 MB/s
Did 1318000 SHA-384 (256 bytes) operations in 1000514us (1317322.9 ops/sec): 337.2 MB/s
Did 402000 SHA-384 (1350 bytes) operations in 1001386us (401443.6 ops/sec): 541.9 MB/s
Did 74000 SHA-384 (8192 bytes) operations in 1008212us (73397.3 ops/sec): 601.3 MB/s
Did 40000 SHA-384 (16384 bytes) operations in 1018670us (39266.9 ops/sec): 643.3 MB/s

And here's SHA-512:

✗ ./tool/bssl speed -filter SHA-512
Did 2704000 SHA-512 (16 bytes) operations in 1000117us (2703683.7 ops/sec): 43.3 MB/s
Did 1342000 SHA-512 (256 bytes) operations in 1000413us (1341446.0 ops/sec): 343.4 MB/s
Did 435000 SHA-512 (1350 bytes) operations in 1001122us (434512.5 ops/sec): 586.6 MB/s
Did 80000 SHA-512 (8192 bytes) operations in 1008565us (79320.6 ops/sec): 649.8 MB/s
Did 41000 SHA-512 (16384 bytes) operations in 1003932us (40839.4 ops/sec): 669.1 MB/s

So there is a difference for larger inputs, but most things being hashed in this context are on the smaller end. @FredericJacobs, does this mostly align with your perceived performance differences?

[kwantam]

The performance differences are almost certainly illusory. It is literally the same algorithm with different constants.

[chris-wood]

Yep =)