You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #56 we will re-introduce some customized serde de/serialization again. This is because currently the VOPRF spec still actually produces zero scalars and identity points and we can't actually use the appropriate types to represent the fact that de/serialization should fail with zero scalars and identity points.
When this is resolved in the VOPRF spec, cfrg/draft-irtf-cfrg-voprf#307, we can use the appropriate types. For elliptic-curve that is PublicKey and SecretKey or NonIdentityPoint (something I was thinking of introducing) and NonZeroScalar, for curve25519-dalek we will have to introduce our own types.
The text was updated successfully, but these errors were encountered:
Theoretically, it's really code quality improvement only, maybe it's a bit overkill to have a whole issue for something like this, so feel free to close.
But yeah, eventually we should get back to it.
In #56 we will re-introduce some customized
serde
de/serialization again. This is because currently the VOPRF spec still actually produces zero scalars and identity points and we can't actually use the appropriate types to represent the fact that de/serialization should fail with zero scalars and identity points.When this is resolved in the VOPRF spec, cfrg/draft-irtf-cfrg-voprf#307, we can use the appropriate types. For
elliptic-curve
that isPublicKey
andSecretKey
orNonIdentityPoint
(something I was thinking of introducing) andNonZeroScalar
, forcurve25519-dalek
we will have to introduce our own types.The text was updated successfully, but these errors were encountered: