1. 18
  1.  

  2. 5

    Is this token local or public? local: shared-key authenticated encryption, public: public-key digital signatures.

    If someone doesn’t know whether to pick between encrypting or signing or tagging [1] a token, it seems that asking whether the token is local or public could only confuse them. SWEs implementing their own encryption might be foolish, but not understanding the primitive cryptographic operations you can utilize seems to err in the other end of the possible delineations between researchers and practitioners.

    1. since this one is slightly less commonly known — https://en.wikipedia.org/wiki/Message_authentication_code
    1. 1

      If it’s local, you get authenticated encryption. No other choices.

      If it’s public (i.e. the token is signed by one party and verified by another), you get digital signatures.

      That’s the only choice that needs to be made.

      1. 4

        That misses quite a few use-cases, no? Most importantly, tagging, where I don’t need asymmetric signatures and I don’t need encryption, but I want to give you a token you can read but not modify before you pass it back to me.

        Also, why does “local” mean “authenticated encryption”? And “public” mean “digital signatures”? I might be getting dense towards the end of a long week, but the linguistic intuition seems non-obvious.

        1. 3

          Most importantly, tagging, where I don’t need asymmetric signatures and I don’t need encryption, but I want to give you a token you can read but not modify before you pass it back to me.

          If you want unencrypted-but-authenticated tokens, stick the raw data in the unencrypted footer. Strictly speaking, your options are AEAD or Ed25519.

          Also, why does “local” mean “authenticated encryption”? And “public” mean “digital signatures”?

          Local means local to a system. The issuer is the verifier.

          Public means it’s not local to a system, it’s going to be transmitted over the public Internet. The issuer is a different entity than the verifier. (It doesn’t make sense to use public-key cryptography for a purely-local use case.)

          1. 2

            If you want unencrypted-but-authenticated tokens, stick the raw data in the unencrypted footer.

            So instead of buttons and levers, there’s more the one place I can stick my data?

            The issuer is the verifier.

            The word for that use case is “symmetric”.

            Public means it’s not local to a system, it’s going to be transmitted over the public Internet.

            And if the data is public, but the token verification is local (i.e. symmetric), then you stick it in the unencrypted footer. Got it.

            Hope you don’t take it personally if I stick with { data, tag: SHA(secret + data) } and call it a day ;)

            1. 7

              { data, tag: SHA(secret + data) }

              I hope you don’t stick with that, since I can add my own data and produce a new, but valid SHA, via a length extension attack, no?

              1. 4

                Just to really drive this home @anfedorov - the tldr from @apg’s link:

                HMAC is the real solution. HMAC is designed for securely hashing data with a secret key.

    2. 3

      Nice that this is being pushed forward now. I’ve written a C implementation of (for now) v2.local with bindings to Java and C# (latter by a colleague). I’ve been wanting to publish it, but had my hands full. I hope I manage to get it out on the web in the next two weeks, hopefully including Python bindings!

      1. 2

        That sounds amazing :O

        Can you please link them here when they’re released? https://github.com/paragonie/paseto/issues/45

      2. 1

        Really well written and motivating blog post. Paseto wouldn’t be useable with OIDC tokens, right? That’s the place from which JOSE starts entering a project and expanding.

        1. 2

          Not currently, getting Paseto to be usable with OIDC is something I haven’t gotten to yet, but hope to soon.

          1. 1

            Do you mean that an existing JWT could be consumed using Paseto? Or that a translation layer would need to be created?

            I looked all over the docs for an example of the structure of a Paseto token but couldn’t find one. I was curious if it’s formatted exactly like JWT or not.

              1. 1

                Oh perfect! Sorry I didn’t check the readme - I got all my backstory from the blog post so didn’t check the readme. Yeah, looks quite different from jwt, so idk how it would work with OIDC. I’ll have to read the spec, I’ve only read the oauth 2 spec.

        2. 1

          Why not establish a JOSE subset with said “secure implementation” and give a name to your subset?

          JOSE is a broad standard providing a basic framework to do many things. At times it just provides guidelines (just look at rfc 7800). It’s not designed to be the end all “secure solution”. That’s simply not its stated design goals.

          JOSE assumes that specific applications will use a small subset a features for specific things. It’s assumed that the developer has some clue what they are doing. Based on the JOSE philosophy, I would assume that standard libraries for specific usages would be established which would in turn be used by end developers. The article doesn’t seem to consider this organization.

          As the larger industry moves to adopt JOSE for specific secure applications, why not build your solution on something JOSE like? https://xkcd.com/927/ The reason JOSE doesn’t use “ver” is because it’s assumed specific applications should have foreknowledge of a particular JOSE usage. The application would define “ver”. BUT there is no reason why you can’t fit your “ver” philosophy into JOSE. Moreover, JOSE is designed to accommodate this sort of extension. The article lead the read to conclude, “alg”:“none” is proof of JOSE’s fallacy. This is not the case. It is only proof of JOSE’s objectives.

          Now to change from criticism to commendation, I commend paseto’s continued use of json. https://github.com/paragonie/paseto/blob/master/docs/01-Protocol-Versions/Version2.md I’m glad to see it’s remarkable like JOSE, but that leads me to wonder could you really not figure out how to fit your philosophy in something considered by some great minds in the industry?

          1. 4

            The blog post explains why, dude. In security world, it’s bad practice to enable devs to do the wrong insecure thing.

            1. 2

              Why not establish a JOSE subset with said “secure implementation” and give a name to your subset?

              Secure cryptography is inherently incompatible with insecure cryptography, and since most of the vulnerabilities in cryptography protocols occurs at the joinery rather than the primitives, bolting a massive backward compatibility with JOSE would be self-defeating.

              The goal of Paseto is to be boring (PDF).