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
Messages (byte arrays) must be mapped or encoded to points in the curve to be signed.
The same hashing process/strategy must be followed where the signature is produced and in all places that verify that signature.
Our current algorithm produces a SHA-256 hashed value of the message to sign, then gets a random curve point as if the hash was a random seed.
As explained by the S.C. team, cc: @Nana-EC@AlfredoG87 and @david-bakin-sl, at least the hashing method should be changed to 'keccak256` (alternate to SHA-256) to ensure cross-chain compatibility.
function hashToG1(bytes memory _message) internal view returns (G1Point memory) {
uint256 h = uint256(keccak256(_message));
return curveMul(P1(), h);
}
P1 is the generator point of G1. @rsinha pointed out we cannot use that implementation.
Given that the method for computing the message coordinate from a message hash has to be the same across the parings API and the possible implementations in smart contracts, this task will depend on finding a suitable algorithm for hashing that can be implemented in both places. @rsinha.
Tasks
Check if the TSS Library uses the pairings-api to map points to a curve
Decide if the logic described in this ticket should be implemented in the pairings-api or the signature-api
Implement
Dummy Code Example:
Signature sign(byte[] array) {
Hash keccak256Hash = java.library.keccak256(array);
For (int i = 0....i < MAX_TRIES) {
Point point = RustLibrary.getPointOnCurve(keccak256Hash); // calls arkworks at some level
<more rust calls - 3?>
if (some check on point) {
return point.toSignature();
}
keccak256Hash = java.library.keccak256(combine(array, i));
}
}
The text was updated successfully, but these errors were encountered:
can use the try-and-increment hashing technique, which will have an efficient EVM and arkworks implementation.
This is an implementation on top of arkworks: https://github.com/ARPA-Network/BLS-TSS-Network/blob/main/crates/threshold-bls/src/hash/try_and_increment.rs
We want to use keccak for the use of hasher in line 87
The corresponding EVM implementation is https://github.com/ARPA-Network/BLS-TSS-Network/blob/main/contracts/src/libraries/BLS.sol
Messages (byte arrays) must be mapped or encoded to points in the curve to be signed.
The same hashing process/strategy must be followed where the signature is produced and in all places that verify that signature.
Our current algorithm produces a
SHA-256
hashed value of the message to sign, then gets a random curve point as if the hash was a random seed.As explained by the S.C. team, cc: @Nana-EC @AlfredoG87 and @david-bakin-sl, at least the hashing method should be changed to 'keccak256` (alternate to SHA-256) to ensure cross-chain compatibility.
A POC implementation of the hashing mechanism in solidity can be observed here: https://github.com/hashgraph/hedera-smart-contracts/blob/main/contracts/bls-signature/Pairing.sol#L57-L59
P1 is the generator point of G1. @rsinha pointed out we cannot use that implementation.
Given that the method for computing the message coordinate from a message hash has to be the same across the parings API and the possible implementations in smart contracts, this task will depend on finding a suitable algorithm for hashing that can be implemented in both places. @rsinha.
Tasks
Dummy Code Example:
The text was updated successfully, but these errors were encountered: