GROGGS Shared Secrets
Though you don't (usually) need any special priveleges (or to
register) to read GROGGS, you do need to register in order to be able
to reply. This is because the GROGGS server needs to know who to
attribute replies to (you may also need to register to access
restricted information in the form of edit logs and the like
via. something like greadedits).
GROGGS registration (at least for people in the University) is quite
nearly automatic - you send your registration request to the GROGGS
server, and recieve in response a mail message (sent to an address
based on your userid) containing a secret number in
hexadecimal format. You must keep this number secret - anyone who
obtains it can masquerade as you. If anyone steals your secret number,
you should report this to the editors at once.
In general, you will be issued with a different secret number for
each server, and if you use more than one server regularly, you'll
have to use an extended grogsecret
In order to prevent people looking over your shoulder when you're
viewing your profile, unless the switch
/secureterm is on, grogprofile won't display your
secret on the screen unless you change it.
By default, your shared secret is kept in the file ~/.groggsecret,
which is set up so that it is readable only by you. You should take
care not to let this file fall into the wrong hands.
The format of the file is the word 'md5-secret' followed by some spaces
and then your secret in hexadecimal format.
greadnew just uses .groggsecret, but WrenGROGGS allows for two
secrets files - .groggsecret for level 2 secrets, and
.rogroggsecret for level 1 secrets (WrenGROGGS does not support
editoral access yet - when it does, there will be a separate
file for level 3 secrets). WrenGROGGS can also read the
extended grogsecret format,
which allows you to specify different secrets for combinations
of server and userid. However, if you use this facility, you
can no longer use greadnew (greadnew chokes on the files). A
future release of WrenGROGGS will circumvent this problem.
For the very interested (or the chronically bored), the protocol
used by the GROGGS server goes something like this :
At present, WrenGROGGS (and the server) only support an md5-based
A is the client, S is the server, N_X is a nonce, U_A is A's userid,
^(X) is the bitwise inverse of X, S is the shared secret,
and MD5() is an md-5 hash of its arguments
(MD5 is specified in RFC 1321). All nonces are 16 bytes long, and the
userid is truncated to 16 characters or padded to 16 characters with ' '.
A fuller description can be found in the protocol spec.
S -> A : N_S
A -> S : MD5(N_A, N_S, U_A, ^(S)), N_A
S -> A : MD5(N_S, N_A, U_A, S)
(note the inversion of S and the switch of N_S and N_A - these eliminate
a pair of attacks).
Some points about the protocol :
.. and some points about GROGGS security in general. You should probably
read the protocol before reading this :
- Secrets are currently 64 bits long, so barring a cleverer attack on the
protocol, it should take an search on the order of 2^64 MD5 hashes
to guess a secret.
- Off-line guessing attacks are possible.
- Attack is trivial if you can persuade the server to give the
same nonce twice.
- The server's confidence that the client is genuine arises from
its belief that it has not been tricked into repeating a nonce, and
the client's belief that the server is genuine arises in the
same way. It is therefore imperative that both parties are
confident that their nonces have not repeated.
- Nonce predictability is not an issue as long as no nonce is repeated.
It is quite in order for either party to use a counter to generate
nonces, though any failure in the counter represents an opportunity
- There is an obvious middle-person attack.
- The swapping of N_S and N_A in the two messages effectively prevent
you exploiting anything you might find out about the correlation
between MD5(X,A) and MD5(X, ^(A)).
- The inversion of S prevents attacks based on setting N_A and N_S equal,
and prevents you exploiting anything you might discover about the
correlation between MD5(X,A,Y) and MD5(A,X,Y).
- Key distribution attacks are easy : specifically, one only has to be
able to trick the server's mail-resolution code and fake mail to
do a middle-person attack on the shared secret.
- Attacks on the secret files themselves via. trojan horses are usually
- Attacks on bugs in clients (temporary files containing secrets just
closed, not overwritten, secret files left world-readable etc.) are
likely to be a feature.
- Attacks on bugs in the server editing commands (in which
you trick the server into believing you hold an EDLK) may be possible.
- Attacks on terminals (as always) will probably be a major feature
(people leaving themselves logged in, etc).
- Attacks via other access mechanisms (password snooping, rlogin spoofing,
that sort of thing to get the secret) are possible.
- Attacks on the nonce generators are also possible.
- Fake replies.
Return to WrenGROGGS configuration, or to
the WrenGROGGS home page.
Last modified: Thu Nov 2 18:17:22 1995
Richard Watts <Richard.Watts@cl.cam.ac.uk>