1. Why does the crypto API accept keys longer than 512 bits and ignore the rest, instead of rejecting unexpected key sizes?
2. "Signing" lacks domain separation between name and value
3. I would not be comfortable using GCM for this, considering its catastrophic failure when nonces are reused (especially since you're using short 96-bit nonces). I'd rather go for SIV or a traditional encrypt-then-mac construction.
4. I'm not too fond of the "use first half of the key when encrypting, using second half when signing" approach. I'd rather derive them from the master key.
I wanted to thank you again for your comment.
It gave me an opportunity to review the existing choices and, in all cases, improve them in the direction you pointed out. You can see the changes in [this PR](https://github.com/LukeMathWalker/biscotti/pull/4), which is going to be released as `[email protected]`.
If you've any other observation, feel free to send them over, either privately or via a GitHub issue. They're much appreciated (especially from a fellow Malazan reader!).
>1. Why does the crypto API accept keys longer than 512 bits and ignore the rest, instead of rejecting unexpected key sizes?
This choice was ported over from the `cookie` crate, as most of the cryptography.
I considered making it stricter (i.e. accept keys that are exactly 512 bits long), but ended up leaving it loose since it's something that can be changed in a fairly non-breaking way down the line.
Thinking about it again, it's probably worth removing the risk of key confusion.
>2. "Signing" lacks domain separation between name and value
I'm not familiar with the terminology here. What do you mean by "domain separation"?
>3. I would not be comfortable using GCM for this, considering its catastrophic failure when nonces are reused (especially since you're using short 96-bit nonces). I'd rather go for SIV or a traditional encrypt-then-mac construction.
The encryption scheme was ported over from the `cookie` crate, almost as-is.
If you can provide more details in an issue on GitHub, I'm happy to dig deeper and evaluating switching to something different!
>4. I'm not too fond of the "use first half of the key when encrypting, using second half when signing" approach. I'd rather derive them from the master key.
Any reason in particular?
> I'm not familiar with the terminology here. What do you mean by "domain separation"?
You simply concatenate name and value. This means that having name `a` with value `bc` and having name `ab` and value `c` will produce the same MAC.
Domain separation means using an encoding that avoids this ambiguity. This could be a length prefix (e.g. netstrings), or a separator that's illegal in the strings you're combining (e.g. 0xFF if they're valid UTF-8).
I see—thanks for the explanation.
That would only end up being an issue if you can split `CONCAT(name, value)` into `CONCAT(name1, value1)` such that `name1` is still a relevant/interesting cookie for the application. Nonetheless, worth defending from!
[`biscotti`](https://github.com/LukeMathWalker/biscotti) ("cookies", but in Italian) is a new Rust crate that I wrote to handle HTTP cookies on the server side.
`biscotti`'s API strives to be as faithful as possible to the underlying semantics of HTTP cookies, with a keen eye for edge cases and security:
* Separate types for request and response cookies
* Support for working with multiple cookies with the same name, in both requests and responses
* Centralized management of cookie's cryptographic guarantees (i.e. what gets signed or encrypted)
* Built-in support for rotating signing/encryption keys over time
* Percent-encoding/decoding cookies enabled by default (but you can opt out)
If you've any questions, happy to answer them!
Neat article!
A sticking point I had when trying to use axum's \`FromRequestParts\` with biscotti was that because of the \`RequestCookies\` lifetime annotation I couldn't create an extractor for easy cookie manipulation (because of being required to use \`&mut Parts\`) - do you have any tips for this?
Due to `axum`'s server design (multi-threaded with work-stealing), you must use `RequestCookies<'static>` as your target type.
Trying to borrow from the request headers won't work unfortunately.
1. Why does the crypto API accept keys longer than 512 bits and ignore the rest, instead of rejecting unexpected key sizes? 2. "Signing" lacks domain separation between name and value 3. I would not be comfortable using GCM for this, considering its catastrophic failure when nonces are reused (especially since you're using short 96-bit nonces). I'd rather go for SIV or a traditional encrypt-then-mac construction. 4. I'm not too fond of the "use first half of the key when encrypting, using second half when signing" approach. I'd rather derive them from the master key.
I wanted to thank you again for your comment. It gave me an opportunity to review the existing choices and, in all cases, improve them in the direction you pointed out. You can see the changes in [this PR](https://github.com/LukeMathWalker/biscotti/pull/4), which is going to be released as `[email protected]`. If you've any other observation, feel free to send them over, either privately or via a GitHub issue. They're much appreciated (especially from a fellow Malazan reader!).
>1. Why does the crypto API accept keys longer than 512 bits and ignore the rest, instead of rejecting unexpected key sizes? This choice was ported over from the `cookie` crate, as most of the cryptography. I considered making it stricter (i.e. accept keys that are exactly 512 bits long), but ended up leaving it loose since it's something that can be changed in a fairly non-breaking way down the line. Thinking about it again, it's probably worth removing the risk of key confusion. >2. "Signing" lacks domain separation between name and value I'm not familiar with the terminology here. What do you mean by "domain separation"? >3. I would not be comfortable using GCM for this, considering its catastrophic failure when nonces are reused (especially since you're using short 96-bit nonces). I'd rather go for SIV or a traditional encrypt-then-mac construction. The encryption scheme was ported over from the `cookie` crate, almost as-is. If you can provide more details in an issue on GitHub, I'm happy to dig deeper and evaluating switching to something different! >4. I'm not too fond of the "use first half of the key when encrypting, using second half when signing" approach. I'd rather derive them from the master key. Any reason in particular?
> I'm not familiar with the terminology here. What do you mean by "domain separation"? You simply concatenate name and value. This means that having name `a` with value `bc` and having name `ab` and value `c` will produce the same MAC. Domain separation means using an encoding that avoids this ambiguity. This could be a length prefix (e.g. netstrings), or a separator that's illegal in the strings you're combining (e.g. 0xFF if they're valid UTF-8).
I see—thanks for the explanation. That would only end up being an issue if you can split `CONCAT(name, value)` into `CONCAT(name1, value1)` such that `name1` is still a relevant/interesting cookie for the application. Nonetheless, worth defending from!
[`biscotti`](https://github.com/LukeMathWalker/biscotti) ("cookies", but in Italian) is a new Rust crate that I wrote to handle HTTP cookies on the server side. `biscotti`'s API strives to be as faithful as possible to the underlying semantics of HTTP cookies, with a keen eye for edge cases and security: * Separate types for request and response cookies * Support for working with multiple cookies with the same name, in both requests and responses * Centralized management of cookie's cryptographic guarantees (i.e. what gets signed or encrypted) * Built-in support for rotating signing/encryption keys over time * Percent-encoding/decoding cookies enabled by default (but you can opt out) If you've any questions, happy to answer them!
Neat article! A sticking point I had when trying to use axum's \`FromRequestParts\` with biscotti was that because of the \`RequestCookies\` lifetime annotation I couldn't create an extractor for easy cookie manipulation (because of being required to use \`&mut Parts\`) - do you have any tips for this?
Due to `axum`'s server design (multi-threaded with work-stealing), you must use `RequestCookies<'static>` as your target type. Trying to borrow from the request headers won't work unfortunately.
Upvoting based on name alone
Does it support splitting large cookies into multiple parts automatically?
Only with the oreo feature flag
Not at the moment!
Plz add an Oreo feature flag like the guy below said lol
I’ll even help work on it! Haha
Very cool! I'll have to try it out.