String #167
String #167
Conversation
|
The ecdsa_sig stuff is a bit horrible.. I'm unsure whether we should go through Z instead? The downside is that we would construct a Z just to validate (non-negative) and deconstruct it again -- and on the encoding site, just to add or remove some 0x00... What needs to be done for encoding:
For decoding, the asn.1 integer already takes care of avoiding the redundant form (no superfluous leading 0x00 bytes) -- all we need to check that nobody gave us a negative number (thus first byte must be < 0x80). We cut away a potentially leading 0 since mirage-crypto-ec doesn't like these potentially too long (in terms of too many bytes, although they are 0) values... |
|
Still issues on 32bit architectures and ppc64... need to investigate, will do with some local system to test with. |
Cstruct.create does this. If we don't initialize bytes with '\000', Field_element.zero can be something else than '\000'. It's a fix for mirleft/ocaml-x509#167.
|
Tested locally with docker and mirage/mirage-crypto#226 and it's work 🎉. |
Cstruct.create does this. If we don't initialize bytes with '\000', Field_element.zero can be something else than '\000'. It's a fix for mirleft/ocaml-x509#167. Co-authored-by: Hannes Mehnert <hannes@mehnert.org>
On top of #166