Plumbing for ECC#87
Conversation
2536423 to
0cd72c4
Compare
|
First stage is approaching review readiness; still open:
|
02051fb to
1b46bd3
Compare
|
I think this is now ready for a first round of review; @WilliamTakeshi, I'd appreciate a test on your hardware as a first step. @franziskuskiefer / @jschneider-bensch, is that a minimal workable interface for you? |
|
Checked against hardware on |
jschneider-bensch
left a comment
jschneider-bensch
left a comment
There was a problem hiding this comment.
I think we can try to implement an abstraction layer based on this in libcrux-p256. We'd need to implement the high-level operations in libcrux-p256 generically over an implementor of ec::plumbing::EcPrimitives<P256> and also implement ec::plumbing::EcPrimitives<P256> using the existing libcrux implementation of the functionality in the trait, right?
I'm not sure I understand at the moment how we'd extend embedded-cal-libcrux based on that, though.
| } | ||
| } | ||
|
|
||
| impl core::error::Error for ImportError {} |
There was a problem hiding this comment.
Do we have any requirements regarding the minimum supported Rust version? E.g. I think core::error::Error is stable since 1.81.
(I don't know what the current MSRV is of embedded-cal, or of its intended primary users, and I don't know if we have to think too much about it. Just wondering if there are some thoughts around it, when I saw the impl here again.)
| /// compilation error), but that will need some testing w/rt ergonomics. | ||
| fn import_scalar_bytes(&mut self, scalar: &[u8]) -> Result<Self::Scalar, crate::ImportError>; | ||
|
|
||
| fn point(&mut self, x: Self::Scalar, y: Self::Scalar) -> Self::Point; |
There was a problem hiding this comment.
As I understand the signature, this assembles a Point from an affine representation as two scalars. Should it do any kind of validation of this affine representation, i.e. be fallible?
There was a problem hiding this comment.
The way it is used here so far is with the caller's assertion that this is a point on the curve – as the input comes from point reconstruction.
So at this stage I'll fix this in the docs to say that the point is required to be on the curve (and it's the caller's responsibility to check that – after all, this is the plumbing and it's there to just give access to the accelerator).
(Also, now I remember why that function is not documented – because that question was not answered.)
The outer layer remains because the EC plumbing layer does not yet have import and export functions -- otherwise, it could become the software-demo layer. A future refactoring step should move the CRACEN implementation into the plumbing module (but that might be moot if the current dh module is refactored into software-demo).
The high-level layer does not yet use those new types.
As common with plumbing, they are welcome to be empty (with the supported consts false), and can easily be implemented that way.
… as DH plumbing may have it too.
This helps higher layers store exporeted secrets.
…ds being purely on plumbing
Recent history has shown that all users of EmptyCal<false> eventually use EmptyCal<true> and just forward or not forward implementations they need or don't need; let's simplify things.
|
Had to rebase because changes to the libcrux AEAD parts conflicted with a change (and it'd have taken a rebase anyway due to the fixups). |
3 participants
No description provided.