-
Notifications
You must be signed in to change notification settings - Fork 211
Ietf #119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrote some comments, the scheme API is good. I need to review the implementation details a little bit more. Apart from addressing the comments, I think the following should be done:
- migrate old C++ tests to new format
- migrate old python tests to new format
- Add some IETF test cases / vectors (https://github.com/algorand/bls_sigs_ref/tree/master/python-impl)
- HD keys using ethereum spec including test vectors: https://eips.ethereum.org/EIPS/eip-2333
- Get automated CI tests passing and fix merge conflicts
- Add an alias for PublicKey to g1 and Signature to G2 to make usage simpler
- Update README.md and SPEC.md
- KeyGen algorithm from IETF spec
Util::secureAllocCallback = allocCb; | ||
Util::secureFreeCallback = freeCb; | ||
} | ||
|
||
/* | ||
void BLS::HashPubKeys(bn_t* output, size_t numOutputs, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove if not in use
} else if (bytes[0] & 0x80) { | ||
uncompressed[0] = 0x03; // Insert extra byte for Y=1 | ||
uncompressed[1] &= 0x7f; // Remove initial Y bit | ||
} else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should throw an error if the serialization is invalid in my opinion. We want to make point have a canonical encoding consistent with the IETF spec.
There are only three valid encodings:
100 (0x80): A compressed point not at infinity, and y is the lexicographically greater value
101 (0xa0): A compressed point not at infinity, and y is the lexicographically lesser value
110 (0xc0): A compressed point at infinity.
https://github.com/zkcrypto/pairing/blob/master/src/bls12_381/README.md#serialization
Also we should add a test case for each case.
static void CompressPoint(uint8_t *result, const gt_t *point); | ||
}; | ||
|
||
class BNWrapper { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is this used?
src/elements.cpp
Outdated
G2Element ele = G2Element(); | ||
uint8_t uncompressed[G2Element::SIZE + 1]; | ||
std::memcpy(uncompressed + 1, bytes, G2Element::SIZE); | ||
if (bytes[0] == 0xc0 && bytes[48] == 0xc0) { // representing infinity |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as G1, enforce serialization is correct and add test case
@@ -51,24 +55,55 @@ friend class Threshold; | |||
|
|||
~PrivateKey(); | |||
|
|||
PublicKey GetPublicKey() const; | |||
// PublicKey GetPublicKey() const; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove comment
|
||
public: | ||
// static PrivateKey KeyGen(... ikm); TODO | ||
static vector<uint8_t> SkToPk(const PrivateKey &seckey); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This depends on the scheme. Maybe rename? Also why is this not in the PrivateKey class instead?
|
||
static G1Element SkToG1(const PrivateKey &seckey); | ||
|
||
static vector<uint8_t> Sign( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should remove this, we can always call G2Element.serialize() right? What's the point of adding the extra method?
|
||
G2Element G2Element::FromMessage( | ||
const std::vector<uint8_t>& message, | ||
const uint8_t* dst, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the user supposed to pass in here for dst? This is confusing
benchAggregateSigsSecure(); | ||
benchAggregateSigsSimple(); | ||
benchDegenerateTree(); | ||
// benchSigs(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uncomment
uint8_t seed1[5] = {1, 2, 3, 4, 5}; | ||
uint8_t seed2[6] = {1, 2, 3, 4, 5, 6}; | ||
uint8_t message1[3] = {7, 8, 9}; | ||
|
||
PrivateKey sk1 = PrivateKey::FromSeed(seed1, sizeof(seed1)); | ||
PublicKey pk1 = sk1.GetPublicKey(); | ||
Signature sig1 = sk1.Sign(message1, sizeof(message1)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uncomment and fix tests
* delete old relic submodule * git submodule add chia's relic * remove travis * bring the ci forward 2 months * bring setup.py forward * add flake8 ini * add mypi.ini * first attempt at FetchContent chia-relic-src * Get cmake almost there * Final cmake fixes * Add lgtm.yml
This pull request introduces 2 alerts and fixes 5 when merging 262c463 into f4ffccd - view on LGTM.com new alerts:
fixed alerts:
|
This pull request introduces 2 alerts and fixes 8 when merging c3cf028 into f4ffccd - view on LGTM.com new alerts:
fixed alerts:
|
This pull request introduces 2 alerts and fixes 8 when merging 9a983a2 into f4ffccd - view on LGTM.com new alerts:
fixed alerts:
|
This pull request introduces 1 alert and fixes 8 when merging b8d2880 into f4ffccd - view on LGTM.com new alerts:
fixed alerts:
|
This pull request introduces 1 alert and fixes 8 when merging 3bbedbb into f4ffccd - view on LGTM.com new alerts:
fixed alerts:
|
This pull request introduces 1 alert and fixes 8 when merging 2e41ded into f4ffccd - view on LGTM.com new alerts:
fixed alerts:
|
This pull request fixes 8 alerts when merging 049a6fd into f4ffccd - view on LGTM.com fixed alerts:
|
This pull request fixes 8 alerts when merging 11fe38a into f4ffccd - view on LGTM.com fixed alerts:
|
This pull request fixes 9 alerts when merging 502f981 into f4ffccd - view on LGTM.com fixed alerts:
|
This pull request fixes 9 alerts when merging a97974c into f4ffccd - view on LGTM.com fixed alerts:
|
This pull request fixes 9 alerts when merging 9a4ee51 into f4ffccd - view on LGTM.com fixed alerts:
|
This pull request fixes 9 alerts when merging 3570dc2 into f4ffccd - view on LGTM.com fixed alerts:
|
This pull request fixes 9 alerts when merging 781f0b7 into f4ffccd - view on LGTM.com fixed alerts:
|
This pull request fixes 9 alerts when merging 963e618 into f4ffccd - view on LGTM.com fixed alerts:
|
This pull request fixes 9 alerts when merging a972a3e into f4ffccd - view on LGTM.com fixed alerts:
|
This pull request fixes 9 alerts when merging 3c105e6 into f4ffccd - view on LGTM.com fixed alerts:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going ahead and merging into master in anticipation of the 1.8 release
Making this pull request so I can see all the changes and start reviewing.