search

RustCrypto / PAKEs

Password-Authenticated Key Agreement protocols
104 stars 34 forks source link

Add AuCPace protocol to PAKEs #115

Closed tritoke closed 1 year ago

tritoke commented 1 year ago

AuCPace is modern V-PAKE designed for Industrial IOT applications, it's inclusion in RustCrypto/PAKEs should promote the general use of PAKEs and enable their use for microcontrollers.

tarcieri commented 1 year ago

Looks like you'll need a rebase and to bump MSRV to 1.60

tritoke commented 1 year ago

It seems like I might have to bump spake2 and srp to 1.60 as well as I use dep: :(

tritoke commented 1 year ago

Okay this seems to be a problem with password_hash switching to using CryptoRngCore instead of RngCore + CryptoRng.

tritoke commented 1 year ago

got it building now so I'm gonna sneak it into the original commit and add the MSRV bump back on top

tritoke commented 1 year ago

Okay final™ failure is clippy complaining about an unnecessary .to_vec() so I'm just gonna sneak that in the MSRV bump commit.

tarcieri commented 1 year ago

It seems like I might have to bump spake2 and srp to 1.60 as well as I use dep: :(

That's fine. 1.60 is a difficult MSRV bump, especially for workspaces

tritoke commented 1 year ago

Okay all passed, an extra commit snuck in there so I've squashed that into the Add AuCPace commit :) gonna pretend that like 10 force commits just didn't happen 😂

tritoke commented 1 year ago

So I've found an issue in that the crate cannot actually compile for no_std targets with serde because serde_arrays isn't a no_std library, theres no reason for it not to be so I'm drafting a PR to make it no_std compatible. As a replacement serde-byte-array is no_std and provides what we need as [u8; N] is the only type I needed to serialise with serde-arrays.

Should I add another commit on top or just hide it inside of the one before the version bump again?

tritoke commented 1 year ago

Should have looked at the serde_arrays PRs... one has been open for two years about adding no_std support and it has a full implementation so I'm just going to leave it.

tritoke commented 1 year ago

For now I've just added a commit on top but I can squash it if need be.

tarcieri commented 1 year ago

Does serde_bytes do what you need? It's no_std-compatible and maintained by the serde team.

The @RustCrypto org also maintains the serdect crate which may do what you want as well: https://github.com/RustCrypto/formats/tree/master/serdect

tritoke commented 1 year ago

serde_bytes doesn't seem to support arrays from what I can tell, only Vec and &[u8]. serdect I think would be usable, though it would require some modification as serde-byte-array just gives me a serde_with helper that works. I'm also unsure of the benefit of a constant time implementation, the only "secret" value that a message can ever hold is the Registration message, which contains a verifier. I'm going to head to bed now but I will take a look at serdect tomorrow.

tritoke commented 1 year ago

So I've had a look at serdect and I can't see a good reason to switch to it, I would have to manually implement Serialize and Deserialize, the only sensitive value that could be leaked is a verifier, which is only sent once per user as it is part of the registration packet, I thus think the risk is minimal from this attack. I'm going to stick with serde-byte-array, fwiw this crate is also maintained by people doing cryptography on embedded hardware.