Comments (8)
having two representations of the signatures
"Having" suggests that blst serialization could emit either. And this is not the case, it always produces fully reduced data. More appropriate wording would be "accepting two representations." And implication would be that non-reduced data would be modified by an adversary.
from blst.
Fix is committed. Closing this. Thanks!
from blst.
As for suggested solution, no, it would be more appropriate to add zero and see if the result is different from input. I'm also a bit torn on suggestion that signature would be malleable. I mean malleability implies that at least it would be a signature for a different message, and at most you'd be able to compute this different message. But signature modified as suggested would be valid for the original message...
This is not to say that non-reduced coordinates should be accepted, but then why would it apply just to X in compressed format? It sounds more like that all coordinates should be vetted and "bad encoding" returned if non-reduced one is encountered.
from blst.
each specific field point should be strictly less than the field modulus
Is this constraint specified in the IETF spec?
from blst.
Is this constraint specified in the IETF spec?
If this is a reference to bls signature draft, then it probably can be classified as kind of a trick question. Because the [original] question here is rather a matter of deserialization, while it, the serdes, is not direct part of the said spec. It's specified only indirectly as "whatever [ZCash] says." And the referred section doesn't say much about how stringent the deserializtion procedure should be. As result one can probably argue both ways, i.e. non-reduced inputs should be rejected or may be tolerated. Naturally as long as it doesn't matter from cryptographic viewpoint, which is arguably the case. At least it's the case in the 'blst' context, because the moment non-reduced coordinates are converted to internal representation, they are implicitly reduced. In other words X and X+P yield exactly same internal representation. I naturally can't claim that it's universally the case, but as long as inputs are treated in "true modulo-arithmetic" manner, it shouldn't matter. (Just in case, the quotes are because it's not a real term:-) However, one can naturally argue in favour of "should be rejected" from purely pragmatic purposes, the serialization should be unambiguous.
from blst.
It's specified only indirectly as "whatever [ZCash] says." And the referred section doesn't say much about how stringent the deserializtion procedure should be.
What does the ZCash implementation do?
from blst.
What does the ZCash implementation do?
Note that the draft says "whatever it defines", not what any particular implementation does:-) Either way, the referred section refers to "field elements" and one can legitimately say that the term describes a value less than corresponding modulus. And consequently conclude that non-reduced values should not be tolerated. But this is not what I kind of objected, I objected assertion about malleability and applying the restriction to compressed format alone.
from blst.
Yep you're correct this isn't malleability as both signatures are related to a single message. It is actually just an matter of the injectiveness of field element (and thus also elliptic curve point) deserialisation.
Sorry if I didn't communicate this clearly, I intended to raise this as an issue of field element deserialisation in general rather than strictly the uncompress()
function. I made an example of the uncompress()
function as deserialise()
is already not injective (as you may have compressed or uncompressed forms of points).
The ZCash implementation enforces that a finite field element is less than the modulus here.
I think it's beneficial to have uncompress()
and compress()
functions which are injective. This allows you to take full advantage of the fact the signatures are deterministic. For example drand use a threshold bls signature as input to a hash function to generate randomness, having two representations of the signatures allows for two different outputs of the randomness function. Other benefits are that a network packet with a message and signature will always have the same bytes if the signature uncompression is injective. Thus this will prevent accidental introduction of bugs in implementations for assuming two messages are different due to having different bytes.
from blst.
Related Issues (20)
- LVI countermeasures in assembly HOT 1
- Rust bindings reference non-existent "std" feature HOT 3
- Error building blst Wasm in Rust HOT 2
- Windows: bool is 4-bytes by default HOT 3
- `blst` fails to build in Windows on ARM device HOT 4
- `blst` fails to build macos 13.x HOT 2
- Rust bindings: `PublicKey::key_validate` not linking for `x86_64-fortanix-unknown-sgx` (current master branch) HOT 11
- [Rust-binding] Proposal to implement `std::hash::Hash` for publicly exposed structures HOT 6
- Rust Bindings: Replacing slices of references to iterators of references for aggregation HOT 3
- BLST throws illegal instruction error on AMD K10 CPUs (Windows) HOT 27
- How Derive keys by path? HOT 2
- The same private key but different public key results HOT 2
- Segmentation fault in some machines and not in others using OpenBSD adJ74 HOT 15
- Rust bindings not recompiled on target CPU change HOT 6
- Unable to build on x86 macOS using LLVM 17.0.6 HOT 4
- When might the next release be cut? HOT 5
- ARMv7 optimization HOT 19
- Bug: Incorrect result from blst_fp_inverse()
- Failed to build with `undefined: Message` HOT 1
- Rust bindings broken on Mac Sonoma 14.5. HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from blst.