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
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.
> 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.
"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 http://www.gnupg.org (Encryption and Digital