Clarify nonce hashing #7
Conversation
Fixes: #5 Signed-off-by: Raul Metsma <raul@metsma.ee>
| #### Clarification on `nonce` (challenge) processing | ||
| - The `nonce` value is supplied by the Relying Party (RP) as a **Base64-encoded string** representing a cryptographically strong random value (at least 16 bytes of entropy recommended). | ||
| - The Web-eID application **verifies that the `nonce` is valid Base64** but does **not decode** it into raw bytes. |
There was a problem hiding this comment.
We do not verify that nonce is valid Base64, we only require that byte length is at least 44, the length of 32 Base64-encoded bytes to require at least 256 bits of entropy, see
https://github.com/web-eid/web-eid-app/blob/main/src/controller/command-handlers/authenticate.cpp#L107-L116
Also worth noting that we don't allow nonces longer than 128 characters.
Remove bold emphasis to align with the style of the rest of the document.
| The value that is signed by the user’s authentication private key and included in the `signature` field is `hash(origin)+hash(challenge)`. The hash function is used before concatenation to ensure field separation as the hash of a value is guaranteed to have a fixed length. Otherwise the origin `example.com` with challenge `.eu1234` and another origin `example.com.eu` with challenge `1234` would result in the same value after concatenation. The hash function `hash` is the same hash function that is used in the signature algorithm, for example SHA256 in case of RS256. | ||
| #### Clarification on `nonce` (challenge) processing |
There was a problem hiding this comment.
This document is actually historic and should in principle no longer be updated. But as there is value in clarifying nonce handling here, let's get your changes in.
But please also update the main format reference here:
https://github.com/web-eid/web-eid-system-architecture-doc/blob/master/README.md?plain=1#L386
| #### Clarification on `nonce` (challenge) processing | ||
| - The `nonce` value is supplied by the Relying Party (RP) as a **Base64-encoded string** representing a cryptographically strong random value (at least 16 bytes of entropy recommended). |
There was a problem hiding this comment.
| - The `nonce` value is supplied by the Relying Party (RP) as a **Base64-encoded string** representing a cryptographically strong random value (at least 16 bytes of entropy recommended). | |
| - The `nonce` value is supplied by the website as a Base64-encoded string representing a cryptographically strong random value containing at least 32 bytes of entropy. |
Relying Party is an OpenID Connect term that does not apply in this context. Arnis used website elsewhere in the text, so we should use the same term.
We require 32 Base64-encoded bytes, see next comment and source reference.
Remove bold emphasis to align with the style of the rest of the document.
| - The `nonce` value is supplied by the Relying Party (RP) as a **Base64-encoded string** representing a cryptographically strong random value (at least 16 bytes of entropy recommended). | ||
| - The Web-eID application **verifies that the `nonce` is valid Base64** but does **not decode** it into raw bytes. | ||
| - Instead, the **literal Base64 string** is UTF-8 encoded and used in the hashing step. |
There was a problem hiding this comment.
I think this explanation makes it confusing. The nonce can actually not be Base64 encoded (some imaginary special cases during command-line use) and as we need to use some encoding in this case, we use standard UTF-8 which is a superset of the Base64 ASCII encoding. But for Base64 strings UTF-8 encoding is a no-op.
The point is we don't really require it to be Base64, but Base64 is the sanest encoding for transmitting bytes through the web layer. So we treat the nonce as a "constant in presumably Base64 encoding that we don't Base64 decode".
Can this be explained better?
Fixes: #5
Signed-off-by: Raul Metsma raul@metsma.ee