NOKEY(1)                        Authentication                        NOKEY(1)

NAME
       nokey - safe autentication using Shamir's no key protocol

SYNOPSIS
       nokey [options] [file] [number]

DESCRIPTION
       nokey is a utility for providing secure authentication through an inse-
       cure channel using Shamir's no key (or three-pass)  protocol  over  the
       group  of  units Z/p (p being a large prime number, designated from now
       on as the modulus).

       The advantages of the three-pass protocol for authentication are mainly
       two:  that  passwords  are not sent in the clear over the communication
       channel and that it needs no certificates or the overload of Public Key
       Infrastructure (the authentication server might as well fix a new modu-
       lus  for  each  authentication  attempt,  though  this  would  be  very
       resource-intensive).

       Moreover,  many  of the Web 2.0 services, such as blogs, chat services,
       and wikis require only secure authentication (in other words, that  the
       login/password  pair  is only known to the owner) because virtually all
       of their content is made public.

       Users of webmail servers may also be  eager  to  trade  non-privacy  of
       their  mail  (letting  it  go  through the web on the clear) for secure
       authentication (safe encryption of the login protocol). Actually,  they
       are trading for nothing nowadays in most cases.

THE PROTOCOL
       Shamir's  no  key  protocol with modulus p works as follows (assume the
       key -password- is a integer number k between 2 and p-1):

       init           The authentication server provides the client  with  the
                      modulus p

       encryption 1   The  client  chooses a random number u1, which is a unit
                      modulo p-1 and computes q1 = k^u1 mod(p) [k to the power
                      u1 modulo p]. The client sends q1 to the server.

       encryption 2   The  server  chooses  another random unit u2 modulo p-1,
                      and computes q2 = q1^u2 mod(p), sending this back to the
                      client.

       decryption 1   The  client  computes v1 = 1/u1 mod(p-1) (the inverse of
                      u1 modulo p-1) and  sends  q3  =  q2^v1  mod(p)  to  the
                      server.

       decryption 2   Finally, the server computes v2 = 1/u2 mod(p-1) and q4 =
                      q3^v2 mod(p). By Fermat's little theorem, one has q4 = k
                      mod(p),  and  the  server  can  now  verify the password
                      against its database.

       The command no_key_server runs the server-side of  the  protocol.   The
       client  side  has  to  be implemented specifically (although the source
       code includes a test client for convenience). As the algorithm requires
       keeping  track  of  the modulus (unless it is stored in a configuration
       file) and of the unit u2, the server behaves differently  depending  on
       the number of parameters it receives:

       (no params)    When called with no parameters, nokey assumes the client
                      is initiating the communication, and sends back a  file-
                      name (without path) and the modulus (either computing it
                      or reading it from a configuration file), separated by a
                      space.  The  filename  is  used  as a 'session-tracking'
                      mechanism.

       no_key_server file q1
                      If nokey is called  with  exactly  two  parameters,  the
                      first  one  is  assumed  to  be  a filename (the session
                      tracking file) without leading path (the session  direc-
                      tory  is known by the server) and the second is the num-
                      ber q1 (as described above in encryption 1). The  server
                      returns  a  string composed of the same filename and the
                      number q2 separated by a space.

       no_key_server file q3 1
                      When called with exactly three parameters (the last  '1'
                      may  be  anything), nokey performs the decryption 2 step
                      and returns the number q4 in binary form.

       After all these steps, if the cilent has sent q1 and q3  properly,  the
       last output coincides with the 'password' (modulo p). If the password k
       is, as a number, less than p, then q4 = k.

       The size of p, by default, is 512 bits. This allows for  512/8=64  bit-
       long  passwords, which "ought to be sufficient" for most practical pur-
       poses.

OPTIONS
       no_key_server supports the following options:

       -c filename    Specify a different modulus file filename.  If  it  does
                      not  exist,  then  nokey will compute a new modulus and
                      try to store it at filename (for later  use),  but  will
                      not  complain  or  fail if it cannot write to that file.
                      Default: /etc/nokey.mod.

       -t dir         Use a dir to store temporary files. Default: /tmp.

       -p number      Use number as the modulus, instead of reading it from  a
                      file  or  computing it. In this case, number must be the
                      hexadecimal expression of a prime number. nokey makes  a
                      fast check about its primality, but it mostly trusts the
                      user.

       -s             Run as a TCP server. This is still undocumented.

       -P port        Use port port to listen on, when  running  as  a  server
                      with the -s option, otherwise useless.

NOTES ON USAGE
SECURITY
       The  security  of nokey relies on the difficulty of the discrete- loga-
       rithm problem, which up to date is assumed enough for the same sizes as
       RSA  keys  (that  is, about 2048 bits in 2008). For most practical pur-
       poses, though, a key size of 1024 should be enough.

       There are two steps at which a random integer (modulo p)  needs  to  be
       generated.  On the server side, this is done using OpenSSL's big number
       random generator BN_rand, which "generates a  cryptographically  strong
       pseudo-random  number"  (see  man  3 BN_rand). On the client side, each
       implementation should take care of this, as knowledge of the  exponents
       voids the logarithm problem.

EXIT STATUS
       The exit status is 0 on successful completion and non-zero otherwise.

BUGS
       There are no known bugs up to date.

VERSION
       1.0

AUTHORS
       Pedro Fortuny Ayuso <info at pfortuny.net>
       Rafael Casado Sanchez <rafacas at gmail.com>

COPYRIGHT
       Copyright (C) 2008 Pedro Fortuny Ayuso and Rafael Casado Sanchez

       Permission to use, copy, modify, and/or distribute  this  software  for
       any  purpose  with  or without fee is hereby granted, provided that the
       above copyright notice and this permission notice appear in all copies.

       THE  SOFTWARE  IS  PROVIDED  "AS  IS" AND THE AUTHORS DISCLAIM ALL WAR-
       RANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL  IMPLIED  WARRANTIES
       OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ANY OF THE AUTHORS BE
       LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL  DAMAGES  OR
       ANY  DAMAGES  WHATSOEVER  RESULTING  FROM LOSS OF USE, DATA OR PROFITS,
       WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS  ACTION,
       ARISING  OUT  OF  OR  IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
       SOFTWARE.

Version 1.0                      October 2008                         NOKEY(1)