-
Notifications
You must be signed in to change notification settings - Fork 88
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
x25519 vectors #76
Comments
I'd like to work on this issue and thought about implementing it this way:
Would that work for you? In particular, I was wondering if another |
Hello! Thank you for having a look at this. The good news is that @xobs has a port of engine25519 working in Renode, so you may even be able to emulate your solution to see if it works without the need for real hardware. I think your approach works well. Overall, it makes sense to just include the vectors as a .bin file as long as there is a way to do that without having to invoke nightly Rust (iirc it's possible to do in stable, but I can't recall how it's done off the top of my head); alternatively, you could do something like an autogenerated Rust module that compiles into some static variables that can be accessed later on. This is the approach that was taken in absorbing the database of FPGA frames to patch for key injection into the bitstream: https://github.com/betrusted-io/xous-core/tree/main/services/root-keys/src/key2bits; there's a Python file that reads in the database and spits out an included .rs file. The main advantage of that approach is that the binary data gets type annotations around it without having to do some I don't have a strong opinion either way; as long as it's all done with stable features, casting a repr-C struct onto a binary blob with an unsafe operation to conjure test vectors like this feels like no big deal. If there is a correctness issue resulting from the unsafe operation it'd fall out in the actual x25519 tests failing, and it won't have a domino impact on the correctness of other systems. From the memory usage standpoint, 50kiB of extra RAM dedicated to the test routine is not going to break the system. We're currently using about 6.7MiB out of 16MiB available RAM space (and all code is copied into RAM right now before being run). Eventually, we'll make deep diagnostic tests like this a "feature" option so we can save on code space, but for now we have enough memory space to carry all the test frameworks. |
If you have any questions on how to get Redone running or how to navigate the code base, we welcome them. We're still figuring out what needs to be better documented to make the on-boarding process less painful. |
Thanks for the detailed feedback, it's much appreciated! I think I found a way to use a .bin file without the need for nightly features by adapting what you were already doing with So far, I did not have any problems getting Xous running on Renode or navigating the code base. However, I was just gathering information for a bug report when @xobs latest commits unbroke the system for me. Hosted mode worked fine, so I was able to play around a bit. Can't wait to see the hardware go into production. :) |
Closes betrusted-io#76 The test vectors in wycheproof-import/x25519_test.json correspond to the upstream commit C2SP/wycheproof@4672ff7. For details see wycheproof-import/README.md. Signed-off-by: Fabian Weißberg <[email protected]>
Closes betrusted-io#76 The test vectors in wycheproof-import/x25519_test.json correspond to the upstream commit C2SP/wycheproof@4672ff7. For details see wycheproof-import/README.md. Signed-off-by: Fabian Weißberg <[email protected]>
Closes betrusted-io#76 The test vectors in wycheproof-import/x25519_test.json correspond to the upstream commit C2SP/wycheproof@4672ff7. For details see wycheproof-import/README.md. Signed-off-by: Fabian Weißberg <[email protected]>
Closes betrusted-io#76 The test vectors in wycheproof-import/x25519_test.json correspond to the upstream commit C2SP/wycheproof@4672ff7. For details see wycheproof-import/README.md. Signed-off-by: Fabian Weißberg <[email protected]>
Closes betrusted-io#76 The test vectors in wycheproof-import/x25519_test.json correspond to the upstream commit C2SP/wycheproof@4672ff7. For details see wycheproof-import/README.md. Signed-off-by: Fabian Weißberg <[email protected]>
Closes betrusted-io#76 The test vectors in wycheproof-import/x25519_test.json correspond to the upstream commit C2SP/wycheproof@4672ff7. For details see wycheproof-import/README.md. Signed-off-by: Fabian Weißberg <[email protected]>
@fweissberg has ported the vectors in, and the following failures are noted running on hardware:
The porting task is finished, but leaving this issue to track progress on fixing the failed tests. |
The issue is fixed in this patch: betrusted-io/gateware@817e284 Specifically: @@ -1413,7 +1413,7 @@ carries that have already been propagated. If we fail to do this, then we re-pro
self.dsp_match3 &
self.dsp_match2 &
self.dsp_match1 &
- (self.dsp_p0 >= 0x1_ffed)
+ (self.dsp_p0[:17] >= 0x1_ffed)
)
] The normalization overflow computation was looking at the entire output of the DSP All vectors now pass with this patch. Thanks @fweissberg for committing the test vectors that caught this very subtle bug! |
Might be a good idea to port these into Xous and check the implementation against this set of vectors:
https://github.com/google/wycheproof/blob/master/testvectors/x25519_test.json
The text was updated successfully, but these errors were encountered: