[Verifpal] (feature request) Better unused outputs

Loup Vaillant David loup at loup-vaillant.fr
Thu Aug 29 17:13:37 CEST 2019


Hi,

Looking a bit more closely at HMACVERIF, I see that its syntax is
currently not ideal (I can sense why: this simplifies your parser,
letting you (Nadim) concentrate on more important stuff).

Currently, we have to declare a new constant for each call of
HMACVERIF:

    unused1 = HMACVERIF(tag1, real tag1)
    unused2 = HMACVERIF(tag2, real tag2)
    unused3 = HMACVERIF(tag3, real tag3)

But we never use those constants! So I was thinking of two possible
alternatives. The first one is simply to allow some primitives to not
have otuputs at all (currently only HMACVERIF):

    HMACVERIF(tag1, real tag1)
    HMACVERIF(tag2, real tag2)
    HMACVERIF(tag3, real tag3)

The second one is to have a special keyword for ignored outputs:

    _ = HMACVERIF(tag1, real tag1)
    _ = HMACVERIF(tag2, real tag2)
    _ = HMACVERIF(tag3, real tag3)

We could use "null" or "nil" instead of "_". The Ocaml programming
language does this: "_" is a place holder for ignored variables (useful
for pattern matching), so the compiler doesn't complain with "unused
variable".

We could also interpret that keyword as a known public constant
(without requiring users to declare it). This would facilitate some
questionable uses of HKDF, such as:

    key1, key2 = HKDF(_, ikm, _)

But that's a separate feature, and a potentially confusing one. We
might want to force the user to be explicit there.

---

My personal preference would be to use "_" as a special keyword for
unused values (on the left of the "=" sign). It's a clear marker that
the user intend to ignore that output, and keeps the syntax simple and
regular.

Ideally, I think we would:

- Mandate that HMACVERIF use "_" as its output.
- Allow SIGNVERIF to use "_" as its output.
- Forbid the other primitives to use "_" as their output.

(Personally, I'm not sure the output of SIGNVERIF has any use. NaCl
wanted to make sure users didn't forget to verify the signature, but
Verifpal is not a C program: if we forget to verify a signature, the
model will likely be vulnerable, and Verifpal will catch the problem.)

Loup.





More information about the Verifpal mailing list