tools: Add experimental code for a pairing protocolseckey-sync-work

* configure.ac (GNUPG_CACHE_DIR): New const.
* tools/Makefile.am (libexec_PROGRAMS): Add gpg-pair-tool.
(gpg_pair_tool_SOURCES, gpg_pair_tool_CFLAGS)
(gpg_pair_tool_LDADD): New.
* tools/gpg-pair-tool.c: New.
--

This is a first try on a protocol to pair two devices so that they can
agree on a shared secret to exchange secret keys.  The idea is that if
you want to sync your secret keys to another machine (e.g. from
desktop to mobile) you have physical access to both devices and thus a
pairing protocol allows to authenitcate the connection using a short
string.  See the source for a protocol description.

How to test:

  $ gpg-pair-tool -va --homedir . --initiate >msg.commit
  $ gpg-pair-tool -va --homedir 2ndhome --respond  \
                                        <msg.commit >msg.dhpart1
  $ gpg-pair-tool -va --homedir . --respond \
                                        <msg.dhpart1 >msg.dhpart2
  $ gpg-pair-tool -va --homedir 2ndhome --respond \
                                        <msg.dhpart2 >msg.confirm

Now set the SAS as printed by the responder into SAS and run

  $ gpg-pair-tool -va --homedir . --respond --sas $SAS <msg.confirm

Storing the secret on disk is obviously not the right thing to do.
With the new PUT_SECRET and GET_SECRET commands of gpg-agent we can
change this to store it all in gpg-agent instead.  This will make it
also easier for gpg to access the secret and we won't need an option
to return it from gpg-pair-tool.  Thus gpg-pair-tool can be dedicated
to run the protocol and maybe to popup info dialogs.

Adding a second expiration time for running the protocol in addition
to the expiration of the secret is probably a better idea than just
that simple catch-all TTL.

Signed-off-by: Werner Koch <[email protected]>

0 files changed, 0 insertions, 0 deletions