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
we could use the same method that we generate private keys in BLS where some 32 bytes entropy bytes are an input, in our case the whole digest. However @asonnino it's very common for rogue key protection to use half scalars, because we care about pre-image attacks; you try to cancel-out another pub key, so combinatorics are already very expensive.
We do use half scalars in many apps (ie in the EdDSA half aggregation) for performance reasons to make that exponentiation half-expensive. In fact though, here we don't care, as this applies once at private key randomization (and with our mode where new-priv_key = old_priv_key \times this_scalar, we don't even have an ECC operation).
@asonnino: You remember the discussion we had at overleaf, shall we update the private key or for each signature we multiply by this scalar? if we do the former half or full scalar doesn't really matter. In the second you have to pay that cost every time you sign.
@kchalkias There's a method called get_128bit_scalar given an RNG in the bls12381 module which is used to randomise signatures in verify_batch_empty_fail_different_msg. If half scalars are enough, we could change this method to take 16 bytes instead. Using the generate method, as you suggest, is also possible but then we would have to either extract the scalar from the private key afterwards, or use the private key type to represent the scalar.
we could use the same method that we generate private keys in BLS where some 32 bytes entropy bytes are an input, in our case the whole digest. However @asonnino it's very common for rogue key protection to use half scalars, because we care about pre-image attacks; you try to cancel-out another pub key, so combinatorics are already very expensive.
We do use half scalars in many apps (ie in the EdDSA half aggregation) for performance reasons to make that exponentiation half-expensive. In fact though, here we don't care, as this applies once at private key randomization (and with our mode where new-priv_key = old_priv_key \times this_scalar, we don't even have an ECC operation).
@asonnino: You remember the discussion we had at overleaf, shall we update the private key or for each signature we multiply by this scalar? if we do the former half or full scalar doesn't really matter. In the second you have to pay that cost every time you sign.
Originally posted by @kchalkias in #236 (comment)
The text was updated successfully, but these errors were encountered: