September 16, 2021 by P.I.E. Staff

Last month, Thomas Ptacek wrote API Tokens: A Tedious Survey on the fly.io blog, which talks about all things API Token.

His post covered JWT, PASETO (our design), and a few other token formats. He went on to clarify, on Hacker News, that:

The one thing I'm not super comfortable about here is my PASETO take. My attitude going in was that PASETO has a lot of boosters and not a lot of critical takes. I can beat up on Macaroons because we're using them, and I'm going to follow up with a post about what our Macaroons like like. I'm not doing that with PASETO. So, like, I stand by it, but take it for what it's worth.

What was his take, exactly? Our succinct understanding of the criticisms laid out in the fly.io article are as follows:

1. There are too many versions; the old ones should be deprecated.
2. PASETO's specification spells out how to avoid algorithm confusion for implementors.
3. Decide between symmetric and asymmetric; don't support both use-cases.
4. NIST algorithm support and CFRG involvement are unnecessary and possibly counterproductive.

Out of these criticisms, the first two are actionable and warrant further inspection, while the latter are Thomas's opinion.

Continue Reading this Blog Post »

August 3, 2021 by P.I.E. Staff

When we designed PASETO, our goal was to provide an easy-to-use, secure-by-default, and simple protocol that solves the same sort of problems as JSON Web Tokens (except actually secure).

This resulted in two types of PASETO token being defined for each version of the protocol:

1. Local tokens: Symmetric authenticated encryption
2. Public tokens: Asymmetric digital signatures

This solved the majority of use cases, but not all: If you wanted to use public-key encryption instead of symmetric-key encryption, you couldn't accomplish that with PASETO. Put flatly, there was no JWK-equivalent for PASETO.

With that in mind, today we'd like to announce the first PASETO extension:

Continue Reading this Blog Post »

August 3, 2021 by P.I.E. Staff

Three years ago, we introduced PASETO to the Internet, as an alternative to the insecure JOSE standards.

PASETO was designed with the philosophy of avoiding in-band negotiation, as well as recognizing that any cryptography key should always be considered to be the raw key material alongside its parameter choices. To that end, PASETO was built with versioned protocols at its foundation (and each key could only be used with a given version and purpose).

Today, we announce the next iteration of the PASETO specification, which includes two new protocols (Version 3 and Version 4).

• Version 3 (if you need NIST-approved algorithms)
  • Local tokens (v3.local) use AES-256-CTR + HMAC-SHA384 (Encrypt-then-MAC)
  • Public tokens (v3.public) use ECDSA over NIST P-384
• Version 4 (Recommended)
  • Local tokens (v4.local) use XChaCha20 + BLAKE2b-MAC (Encrypt-then-MAC)
    • This is very similar to what Halite has always done.
  • Public tokens (v4.public) use Ed25519.

Security teams will mostly be interested in the Rationale page in the PASETO Specification repository. Pay special attention to the section on ECDSA security and questions for security auditors.

Continue Reading this Blog Post »

May 13, 2021 by P.I.E. Staff

Ristretto is a technique for constructing prime order elliptic curve groups with non-malleable encodings. It extends Mike Hamburg's Decaf approach to cofactor elimination to support cofactor-8 curves such as Curve25519.

Ristretto255 is Ristretto defined over Curve25519, which allows cryptographers to extend the Ed25519 signature scheme to support complex zero-knowledge proof protocols without having to deal with the cofactor.

(The cofactor in Ed25519 is what caused the multi-spend vulnerability in CryptoNote cryptocurrencies (n.b. Monero).)

Continue Reading this Blog Post »

October 21, 2019 by Scott Arciszewski

Imagine that you want to build a brick wall.

However, instead of laying each brick deliberately and using mortar to assemble the desired structure, you are instead instructed to assemble a three-dimensional lattice of mortar, like so:

This might seem strange, so naturally you ask what the purpose is for such a design. You are told: "This will allow the inhabitants to hot-swap bricks whenever they need to. For example, if an influx of termites that can eat clay brick infest the area, they might want to switch to concrete bricks to protect their house."

Would you trust such a wall to support the weight of a roof?

Clearly not.

So why do we expect cryptography designed this way to be secure?

Continue Reading this Blog Post »