6
$\begingroup$

Fernet is a described as a "high level symmetric encryption recipe" (source) that seems to be the default high level encryption scheme in the cryptography python library. The construction is described in full here, it basically takes a message $m$ and produces a token as follows:

  • Encrypt $m$ via AES-CBC i.e. $IV \gets \{0,1\}^{128}$, $c = \text{AES-CBC}_{k1}(m, IV)$
  • Take a timestamp $t$, version number $v$ and compute $tag = \text{HMAC}_{k2}(v || t || IV || c)$
  • Send $token = v || t || IV || c || tag$ to the recipient

The recipient then takes the $token$ and decrypts as follows:

  • Verify that $\text{HMAC}_{k2}(v || t || IV || c)$ == $tag$
  • Decrypt $c$ via AES-CBC i.e. $m = \text{AES-CBC}_{k1}(c, IV)$ (only if tag is correct of course)

Key exchange is not included and it is assumed two 128 bit keys $k1, k2$ can be securely established. My questions are the following:

  • The spec states that

    Fernet tokens are not self-delimiting. It is assumed that the transport will provide a means of finding the length of each complete fernet token.

    Does this allow us to tamper with the tokens in a way we shouldn't be able to by adding data to the front or the end of a token? My intuition says no as HMAC is computed over all the data and the composition is Encrypt-then-MAC.

  • Is there any danger in computing HMAC (with SHA256 as the underlying hash function) using only a 128 bit key? My understanding is that the standard key size would be 256 bits in this case.

Improve this question
$\endgroup$
3
  • 1
    $\begingroup$ #1 since the ciphertext is the only part of the token that is variable in size, and the rest are in clearly defined locations, I would say no... HOWEVER, modification of the timestamp field gives an attacker a wide range of options ($2^{64}$) to forge a valid ciphertext if it is not validated, I would have done it differently $\endgroup$
    – Richie Frame
    May 10, 2016 at 0:11
  • $\begingroup$ Read stackoverflow.com/questions/12207343/…. $\endgroup$
    – v7d8dpo4
    May 10, 2016 at 10:30
  • 1
    $\begingroup$ Also interesting: this answer of poncho regarding key size and HMAC. In hindsight a 256 bit key would of course be better, but it seems at least questionable if a 128 bit key would be vulnerable. Disclosure: I performed a review of Fernet some time ago. $\endgroup$
    – Maarten Bodewes ♦
    May 10, 2016 at 11:08

1 Answer 1

Reset to default
2
$\begingroup$

  • The spec states that

    Fernet tokens are not self-delimiting. It is assumed that the transport will provide a means of finding the length of each complete fernet token.

    Does this allow us to tamper with the tokens in a way we shouldn't be able to by adding data to the front or the end of a token? My intuition says no as HMAC is computed over all the data and the composition is Encrypt-then-MAC.

HMAC is not vulnerable to length extension attacks, and prefixing or removing data from the start of end should indeed result in a different HMAC (assuming that the HMAC is indeed over that part of the data).

  • Is there any danger in computing HMAC (with SHA256 as the underlying hash function) using only a 128 bit key? My understanding is that the standard key size would be 256 bits in this case.

No, HMAC is surprisingly resilient and has been defined for smaller key sizes. 256 bits key would give you (at least) a 256 bits of security, but 128 bits is plenty.

Note that this answer tries to answer the given questions directly, rather than to perform a full review of Fernet. Note that Fernet has gone through several revisions by now; please check if the questions / answers are still valid.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.