Comments (8)
I'd kinda expect a trait instead of an enum for this in Rust, just because cipher suite agility creates many complexities. If it's only a compile time choice, or protocol version number, then differentiating MACs and/or hashes might provide the desired protections. Apologies if I've failed to understand all the goals here.
from mls-protocol.
No, this is a good point. I've chosen in my implementation to treat DH algorithms as trait implementations, and DhPoint
s as data. So I would have something like X25519.diffie_hellman(my_scalar, others_point)
. The reason I've chosen this representation for DH public keys is because these types cannot be known at compile time. If they could be, then I would probably use associated types for the aforementioned trait impls. So I have enums which I unwrap at runtime, and panic if there's a type error then. It's not pretty, but it'll hopefully prevent some bad things from happening.
from mls-protocol.
Oh? I'm curious why the types cannot be known? Is it for linking with C or something?
from mls-protocol.
Well the types of, say, the DH implementor is not known. If DH operations are implemented as a trait DiffieHellman
, then there are structs called X25519
and P256
. So if these are marked by bytes, say 0x00 and 0x01, respectively, then what is the return type of deserialize_dh_from_byte(marker: u8) -> ???
.
Well naturally it would be a dyn DiffieHellman
. So say you do let dh_impl = deserialize_dh_from_byte(b)
. Then what types does dh_impl.multiply_basepoint(scalar: ???) -> ???
take and return? If each DH implementation has their own scalar type and point type, how can I know what to give this function?
from mls-protocol.
I'd love it if Rust had type parameters for modules, but no such luck. Instead, we often create parameters traits for the entire module or crate, commonly called Trait
or Params
. It'd bloat the binary though if you need both X25519 and P256 in the same code, hence my C question. Anyways not a big deal. :)
from mls-protocol.
From a protocol design POV, there are basically two options here:
- Set the ciphersuite once, and force implementations to tell their deserializers what it is
- Set the ciphersuite on every object, and force implementations to verify that all the ciphersuites are consistent
IMO, option 1 is likely to be less error-prone, simply because it touches less code, and it is more likely to fail if you get it wrong. It also doesn't seem that burdensome to implement. Yes, you have to route the ciphersuite around to all the right places, but things like templates and generics can help a lot.
from mls-protocol.
I agree with Richard, the preferable way is usually to do 1 : ) It is more a implementation specific state machine enforcement issue than a protocol issue so I will close this, but feel free to discuss more in the Implementation issues if you feel like it is necessary.
from mls-protocol.
Yeah, I tend to agree with this argument. I think I can find a way to pass state into my deserializer.
from mls-protocol.
Related Issues (20)
- Section 17.6
- Section 10.2 HOT 2
- Section 12 HOT 7
- Section 13.2 HOT 3
- Discuss metadata privacy HOT 3
- Section 15.3 HOT 2
- Citations to security analysis HOT 4
- Section 16.2 HOT 2
- Section 17.1 HOT 2
- Section 17.2 HOT 5
- Nits HOT 1
- Clarify that AS needs to see both signature key and credential
- Create an IANA registry for WireFormat values HOT 1
- Faster remove? HOT 24
- IANA considerations for signature labels? HOT 2
- Change log missing for -16 and -17
- Consider greasing your registries HOT 10
- Loosen chain requirements HOT 5
- Figure 14: "Derivation of ratchet tree keys along a direct path" don't correspond to the prose HOT 1
- Minor problem in transcript hash message formats HOT 1
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 mls-protocol.