Why do you have to provide the mlen parameter for verify (or maybe it should be an out param)

[DavyLandman]

I'm thinking of using qDSA for a small IOT project that I'm working on, and while exploring the API, I had a question.

int verify(
        unsigned char *m, long long mlen,
        unsigned char *sm, unsigned long long smlen,
        const unsigned char *pk
        );

the long long mlen, shouldn't it be either not there, or actually a pointer, since the first thing you do is override the value with smlen - 64?

[kaspar030]

qDSA is re-using the NaCl API (IIRC). Without looking at the code, it is possible that mlen always equals smlen - 64 and the parameter is not necessary for qDSA. But the API is fixed...

[DavyLandman]

Okay, that sounds reasonable, but that argues in favor of my remark, NaCl has the mlen as a pointer.

See nacl's kinda header (the header files are generated automatically, so that's a bit annoying to read)

extern int crypto_sign_open(unsigned char *,unsigned long long *,const unsigned char *,unsigned long long,const unsigned char *);

and the implementation:

int crypto_sign_open(
    unsigned char *m,unsigned long long *mlen,
    const unsigned char *sm,unsigned long long smlen,
    const unsigned char *pk
    )
//...
*mlen = smlen-64;

[joostrenes]

Indeed this is an error in the code, the API should be identical to crypto_sign_open; it was actually intended to resemble the SUPERCOP API (https://bench.cr.yp.to/call-sign.html), which I believe NaCl also follows. As NaCl and us always have 64-byte signatures the use of mlen is technically unnecessary (since it is just smlen-64), but I suppose SUPERCOP wants to leave open the option of variable-length signatures which would explain the use of both mlen and smlen.

[DavyLandman]

thanks for your confirmation.