I'd also throw in that HMAC is overrated. It's a workaround for bad hash algorithms that are vulnerable to length-extension attacks.

If you're using a "good" hash algorithm, then MAC-ing is simple: hash over your key and message.

It's pretty weird that SHA-256 has been king for so long, when SHA-512/256 (which, as I've noticed people don't understand, means SHA-512 truncated to 256 bits) was there from the beginning and is immune from this attack.

Anyway, in general it's a pet peeve of mine that many people so often say "HMAC" when really they just mean MAC.

Ah yes of course in 2018 it's still HMAC.

It's mostly about performance. If you can store all the required info about the user inside the cookie then you can avoid a DB query roundtrip before sending a response.

Now that your cookie looks like this (probably also base64 encoded):

  {"id": 42, "display_name": "John", "is_admin": false, "session_end_at":1726819411}

You could also create a cookie that is just random bytes

  F2x8V0hExbWNMhYMCUqtMrdpSNQb9dwiSiUBId6T3jg

But even if you are using random bytes as your session identifier, you should still wrap it in a HMAC so that you can drop invalid sessions early. Just for making it harder for someone to DDOS your DB.

Premature optimisation. We have a diverse set of clients but of all the ones I've audited with JWT and similar crypto-solutions, not one (of those that used sessions at all, not like a CDN or so) could not have run on a single database server. Some more comfortably than others, but also embedded devices with a handful of users at most will use cryptographic sessions nowadays. Some also choose to pack a session cookie into the JWT data and now you've got two things to validate instead of one

I understand it's nice to never have to worry about it regardless of scale, but generating sessions with an established CSPRNG and being able to invalidate them at will is an order of magnitude simpler. It's also standard and abstracted away for you already if you use any framework

Mostly incompetence.

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo...

http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-...

This is how many (most?) session cookies work. Track the data on the backend, only send an identifier to the frontend.

The JWT and similar cookies exist for when you want to do scaling and such. You don't need much more than a user ID and a user name for many pages of a web application, your database may be in another continent, so you may as well store some variables in the client side. This has the added benefit of being able to put down as many frontends as you may need, integrating nicely with technologies like Kubernetes that can spawn more workers if the existing workers get overloaded.

By also encrypting the cookie, you can get rid of most of the backend state management, even for variables that should be hidden from the user, and simply decrypt+mutate+encrypt the cookie passed back and forth with every request, stuffing as many encrypted variables in there as can you can make fit.

They're also useful for signing in to other websites without the backend needing to do a bunch of callbacks. If a user of website A wants to authenticate with website B, and website B trusts website A, simply verifying the cookie with the public key (and a timestamp, maybe a n\_once, etc.) of website A can be enough to prove that the user is logged into website A. You can stuff that cookie into a GET request through a simple redirect, saving you the trouble of setting up security headers on both ends to permit cross-website cookie exchanges.

In most cases, signed cookies are kind of overkill. If all your application has is a single backend, a single database, and a single frontend, just use session cookies. This also helps protect against pitfalls in many common signed cookie variants and their frameworks.

Originally it was about scalability - signed/encrypted cookies are stateless, and hence (in theory) allow easy horizontal elastic scaling: just share the key with the new nodes. But I suspect that in a lot of cases now it is because it is easier initially to throw a key into an environment variable than standup a database, sort out caching, etc. It’s only later that you start thinking about revocation and idle timeouts and key rotation and all the other stuff that it becomes clear that it's not that simple to do well.

> "&" inside JSON strings but yours escapes it

What escaping of "&" inside JSON are you talking about? Some unholy mix of JSON and urlencode?

Shitty software developers will always find ways to screw things up unfortunately

I think AWS SigV4 tries (and succeeds?) in solving this issue?

I'm no cryptographer, but I would say that it is indeed the case that you can assume that two parties can derive a shared key over an untrusted channel. The post Cryptography Right Answers PQ [1], linked in another comment, addresses this in the section "Key Exchange". Rather than thinking about Diffie-Hellman directly, you would turn to a Key Exchange Mechanism (KEM).

Before post-quantum cryptography concerns, KEM were indeed mostly built on top of Diffie-Hellman key agreement, but you could also build one on top of RSA, or on top of some lattice constructs. But you wouldn't build one yourself, there are good constructions to choose from! The OP actually has a 3-part series on KEMs, although I don't think it addresses post-quantum issues [2].

[1]: https://www.latacora.com/blog/2024/07/29/crypto-right-answer... [2]: https://neilmadden.blog/2021/01/22/hybrid-encryption-and-the...

One thing to note about authentication in DH-like systems is that you can derive symmetric key without authenticating the parties, establish secure (but unauthenticated) channel with the resulting symmetric key(s) and the do authentication inside that channel in a way that will only succeed if the symmetric key used by both parties is the same (this is called channel binding). For example SSH2 and many Active Directory related protocols do this.

DH + HMAC on its own doesn't give you authentication, anyone can establish a symmetric key. It's possible to build authentication on top but it requires pre-shared data or PKI.

> It's also super simple: It's almost literally just concatenating the secret and the message you want to authenticate together, and take an ordinary hash (like SHA256) of that, the rest of it is just to deal with padding.

It's not quite as simple as that. The output of the first hash is hashed a second time (to prevent length extension attacks).

To prove that the car rental company has seen the driver licence, they just need to show the judge a copy of the licence which is e-sealed by its issuing authority. No need to include a non-repudiable proof-of-possession signature of the holder. Having that in addition would just introduce legal ambiguity and information asymmetry to the disadvantage of the holder.

The opponent may still claim that the car rental place is showing a copy that was obtained illegally, and not in holder presentation. To avoid such a claim, the car rental company should ask for a qualified e-signature before providing the car key. The signed data can include any relevant claims that both parties confirm as part of the transaction. To provide similar assurance to the customer, the company should counter-sign that document, or provide it pre-sealed if it is an automated process.

Note that with the EU Digital Identity, creating qualified e-signatures is just as easy as presenting digital credentials.

That doesn’t matter. The claim being made by the grandparent post is that the legal system isn’t well-equipped to deal with scenarios like, “yes the digital signature is valid but it was improperly authorized.”

> This reminds me of a specific number that Americans have to give in plain text as proof of digital identity that they only get one of and can't change it ever. Lol.

You can get up to ten replacements of your card in your lifetime. They do all have the same number though.

[1] https://secure.ssa.gov/poms.nsf/lnx/0110205400

Well, at least you can laminate it

Non-repudiation of commitments to a transaction can be good when both parties want to avoid later disputes about the authenticity of these commitments. It requires careful design of the data to be signed, the public key certificates, the policies governing the signature creation and validation processes, and the signature formats to enable validation as long as needed.

Attribute presentation is not designed for this feature. When attribute presentation becomes non-repudiable, it creates legal uncertainty:

1. In court, the verifier may now present the proof of possession as evidence. But this is, at least in the EU, not recognised by default as an e-signature. It is yet unknown if it would be interpreted as such by a court. So the verifier keeps a risk that will be difficult for them to assess.

2. Even if it would be recognised as evidence, the holder may argue that it is a replay of a presentation made in another transaction. Presentation protocols are not designed for timestamp assurance towards third parties, and generally do not include verifiable transaction information.

3. The verifier may protect itself by audit-logging attribute presentation input and output along with publicly verifiable timestamps and verifiable transaction information, and by editing its terms and conditions to claim a priori non-repudiation of any presentation. Typically such a solution would not create the same evidence files at the holder’s side. So the holder would not be able to present as strong evidence in court as the verifier. (This asymmetry aspect needs some more elaboration.)

Non-repudiation is well arranged in EU law for e-signatures. If anyone would want the same for attribute presentation, this should involve changes in law. As far as I can see, non-repudiation is now opportunistically being considered in mDL/EUDI just from an isolated technical perspective.

Another issue with non-repudiation of presentation is that it encourages relying parties to log full transcripts of presentation interactions. It could also encourage supervisory bodies to request such over-complete logging. Instead, relying parties should log the minimum necessary, to avoid developing a honeypot of personal data.

I’m not sure what the German eID uses today, but the German architecture team has explored KEM+MAC for the EU Digital Identity Wallet. Maybe its eID is similar. You can apply KEM+MAC at either or both of two points:

1. plausible deniability of the document’s issuer seal

2. plausible deniability of having presented the document

The second is great for legal certainty for the user. The first has problems. It would be incompatible with qualified e-sealing; stakeholders have no evidence if issuer integrity was compromised.

Also, it would mean that issuance happens under user control, during presentation to a relying party. In a fully decentralised wallet architecture, this means including the trusted issuer KEM key pair on the user’s phone. Compromising the issuance process, for example by extracting the trusted issuer KEM key pair, could enable the attacker to impersonate all German natural persons online.

The advantage would have been that authenticity the content of stolen documents could be denied. This potentially makes it less interesting to steal a pile of issued documents and sell it illegally. But how would illegal buyers really value qualified authenticity e-seals on leaked personal data?

Your last sentence kinda contradicts the fact that the company Google operates the server behind gmail.com.

If Google was evil (but in reality it's not), it could have forged and signed an email from john.smith@gmail.com with valid DKIM, sent on other mail servers or not (since we talk about leaked emails, we just need a file), when in reality the Google user john.smith@gmail.com never sent that email. To me, John Smith could have plausible deniability in court, depending on if everyone trusts Google to be 100% reliable. If the stakes are higher than what the company would risk to lose if found to have forged the email, what's stopping them?

https://youtube.com/watch?v=1FuNLDVJJ_c

This talk from Real World Cryptography 2024 is probably a good place to start.