[Cryptography] Dumb Question about Pair-Wise Authentication

Patrick Chkoreff pc at fexl.com
Sun Apr 5 11:33:48 EDT 2020


Kent Borg wrote on 4/4/20 3:35 PM:

> The "right" way to do this would be to sign each request, right? The
> other side uses a public key to verify the request.
> 
> But I'm lazy, every infrequent time I look at the man pages for any of
> the standard public key software my head hurts and I don't trust I am
> doing it right.

Is there any chance you could use TweetNaCl?  http://tweetnacl.cr.yp.to/

Even there, his extensive use of nested macros, even multi-hop
forward-referencing macros, made my head hurt, so I refactored the
living daylights out of it and arrived here:

https://github.com/chkoreff/Fexl/blob/master/src/nacl.c

Then, the requirement for "just so" padding and fixed-length buffers
made my head hurt again, so I wrapped it with a dynamic "string" type
and arrived here:

https://github.com/chkoreff/Fexl/blob/master/src/crypto.c

(Then, I made bindings for my language Fexl, which is not especially
relevant here.)

Then, I created a bunch of test cases, since I couldn't find anything
ready-made.

I'm not saying it would be a super-easy slam-dunk, but once you got
everything hooked up you'd have a pretty powerful toolset, with built-in
authenticated encryption.


> Can't I do it much more simply? This is a pair-wise data syncing
> problem, it can only every be for a pair of machines, I don't have the
> key distribution problems that public key signatures solve. So why can't
> I just have a shared secret?
> 
> When I want to send a message I do a hash of the message plus the
> secret, and append that hash. On receipt I strip the hash, do a new hash
> of the message plus the secret and compare the result. So simple. What
> is wrong with it? Seems radical.
> 
> There must even be a name for this.

It sounds awesome, but I'll leave it to others to pounce on any weaknesses.

In your scheme, you'd be sharing a single symmetric encryption key.  Now
with TweetNaCl, you could use two separate public keys -- but you could
also just share a single private key if you preferred.  So what's really
the point of using TweetNacl, if you do that?  I guess the only possible
advantage would be using a fully established existing protocol for
authenticated encryption.  It may be complete overkill, if you already
have the ready tools to implement your scheme.


-- Patrick


More information about the cryptography mailing list