how to use the gnupg for authenticated logins

Carl L. Gilbert
Sat Aug 9 05:52:02 2003

On Fri, 2003-08-08 at 18:49, Neil Williams wrote:
> On Friday 08 Aug 2003 10:10 pm, Carl L. Gilbert wrote:
> > On Fri, 2003-08-08 at 14:08, Neil Williams wrote:
> > > On Thursday 07 Aug 2003 11:40 am, Sharad Sahu wrote:
> > This whole thing must be automated or its going to be inconvenient.
> I'd like to agree, but I am cautious and cynical.
> > server sends a random key encrypted.
> Why a random key? How can a random key be trusted? How will the client know 
> that this is a suitable random key and not an attacking random key? IP's can 
> be spoofed.

if its random, then you don't need to trust it by definition.  That key
is sent so that the server can auth the client only.  no information can
be gained by a false server sending a key because the client would never
be able to decrypt it.

> If the key can be trusted, why send it at all? It must be known to the client 
> to be trusted, so the client doesn't need the key. Use the 'secret message' 
> (which might as well be random text) and encrypt that. The client decrypts 
> it, sends it back re-encrypted to the server key.

see above.  their is no trust in that key, servers benefit only.

> > client decrypts random key, and uses it to encrypt a secret message that
> Automated decryption = lack of passphrase = weakness. This weakness must be 
> compensated by a strong identity/trust in the key being used to encrypt the 
> return packet. (lack of passphrase = command-line passphrase / non-human 
> stored passphrase). 

The decryption is as it is today, passphrase optional.  Your first false
assumption is now mushrooming.  You do NOT care about the random key. 
if someone sends you a key, you fully expect them to be able to decrypt
a message encrypted to it.

this passphrase is just an old issue.  if you cant trust the computer
with your keys, you certainly wont be decrypting anything on it.

> Why is it weak? It is weak beacuse the security of the server .gnupg/ becomes 
> your only protection. Also, anyone can encrypt something to my key, I don't 

If the server is not secure, your done.  If the client is not secure,
your done.  If you can find a way around that, patent it.

> want to decrypt and automatically process something that could be malformed - 
> possibly exposing an exploit in another part of the system. This decryption 
> wouldn't be a simple script - the error-handling and security routines could 
> get quite involved and need regular patches according to intrusion logs and 
> aborted attack methods. With automation, you get the War Games scenario - the 
> script will automatically respond to any machine that sends the right 
> packets. Mechanisms must be in place to patch the weakness - prevent repeat 
> attempts > a fixed #, halt processing and alert a real human if certain 
> methods are attempted, etc. Not impossible, just something else to add to the 
> protocol.

I'll leave these complications to the GnuPG writers.

> > the server and the client already know from previous communication (like
> The client doesn't need to have any prior knowledge of the message or token, 
> only a trusted key. The less the client knows about the content of the 
> message in advance of receipt of the token, the harder it will be to return 
> valid content in an attack.

I said secret message, you said trusted key.  same thing.

> > a password).
> > server decrypts message.
> >
> > if all is well, we have mutual authentication with both ways encryption.
> Alternative:
> Server sends random text encrypted to a KNOWN and TRUSTED client key

Then you need to tell me how the server is first authenticating this
client that it KNOWS and TRUSTS, before it sends this encrypted random

> This would be better signed, but then we lose the passphrase again. Not 
> insurmountable, but security of the server becomes imperative - you don't 
> want someone hacking the server box and sending signed tokens to themselves 
> to create a lovely back-door.
> Client must rely on a secondary protocol to identify the server if encrypted 
> packet is not signed. The secondary protocol just adds complexity and cannot 
> be as secure as the encryption (or else you'd just use the secondary protocol 
> for the entire transaction). The secondary protocol would have to be public 
> (the client needs to be able to verify the content), so the protocol standard 
> becomes essential background reading for the attacker.
> The registration part of the authorisation would be completely human dependent 
> (as in a normal keysigning). 

Ahh, so this is the KNOWN and TRUSTED part.  I agree. The buck stops

> The server sends the token to the client, encrypted with the trusted client 
> key. Once this is verified, the process can be automated from the client end:
> 1. Client requests connection.
> 2. Server sends a token encrypted with the trusted client key. (Fail if no 
> trusted key)
> 3. Client can decrypt this token (preferably using a human entered passphrase) 
> and then return the token re-encrypted to the trusted server key. (Fail if 
> decrypted token doesn't exactly match text sent to the client identified by 
> the token.)

can't this fall to a record and playback attack?

> Personally, I don't need a system that is fully automated - I'm looking at a 
> system of semi-automation where the server responds but a human (not a 
> process) is logged in. In my scenario, I can (must) insist on a human 
> operating the client machine during the authentication process (after all, 
> the purpose of the login for my system is for the authenticated user to 
> achieve something personal and variable within the site, like update personal 
> details, check reports and data, send messages etc.).

yes, not full automation.  but like ms passport is using, or like
browsers that use recorded passwords.  My objective is to trade in a
password for a PGP key.  So every time I go to a new web board or new
web store, I can trade the password they give me, for my PGP key.

> I'm looking more at a server-automated Biglumber mechanism that does not 
> involve entering the token as clear text over normal HTTP_POST. 
> The process could be fully automated by adapting the client side script, but 
> precautions would be needed to ensure that the login process cannot be 
> initiated by a new member who has not been verified by the usual keysigning 
> party process. (This is why I'm interested in a two-tier login system - 
> higher privileges for encrypted login, less access for pre-verification 
> username/password (HTTP:AuthType:Basic) authentication.) Making a key 
> trustworthy without verification is inviting anyone to create a authenticated 
> back door.
> BTW. Does anyone here have in-depth knowledge of Kerberos? Is this thread just 
> trying to re-invent Kerberos for GnuPG?

This is my feelings.  I am actually telling about a true system that I
have worked on that is used in cars.  just to show how its done there. 
But not really recommending it because computers already have so many
encryption systems.  ssh is a dually authenticated and encrypted
channel.  Its basically what we want to mimic here.

Thank you,

CL Gilbert
"Then said I, Wisdom [is] better than strength: nevertheless the poor
man's wisdom [is] despised, and his words are not heard." Ecclesiastes

GnuPG Key Fingerprint:
82A6 8893 C2A1 F64E A9AD  19AE 55B2 4CD7 80D2 0A2D
GNU Privacy Guard (Encryption and Digital