craving cryptography commentary

Chris Muller chris at funkyobjects.org
Mon Aug 8 18:18:39 UTC 2005


Now that Magma has power-outage security, I'm designing security to protect
against hacking and would like to get feedback on the following approach.

Basically, I want to punish senders of invalid or forged transmissions by
blocking their IP for a period of time.

The basis of this (punitive) defense is authentication.  When member users are
initially set up in the repository, the public-key of their key-pair is
associated with their id in the system-area of the repository, the member
guards their private-key.  Every repository is also assigned a key-pair (to
start the server the repository owner must have its private-key on-hand).

Ordinarily, the simplest solution would be for clients to sign each request and
the server to sign each response.  Any incorrect signature would be rejected
and the offending IP punished.  Unfortunately, signing is not very fast:

	| message keyGenerator publicKey privateKey sig |
	keyGenerator _ ElGamalKeyGenerator bits: 128.
	privateKey _ keyGenerator privateKey.
	publicKey _ keyGenerator publicKey.
	[ message _ UUID new asString36.
	sig _ privateKey signMessage: message.
	publicKey
		verifySignature: sig
		onMessage: message ] bench

Therefore, to maintain performance, digital-signature authenticatation is
performed on a random message (UUID new asString36) only once, during the
initial connection.

Simultaneously, a DiffieHellman session-key negotiation also occurs in order to
seed Random oracles on each end.  All future transmissions must contain the
next random number, hashed to avoid anyone guessing the seed or finding
patterns, so the other end can more quickly verify it came from the party
originally authenticated.

(Maybe I should forget the DiffieHellman built-in key negotiation and just
encrypt the random message and then sign it.  The random message itself could
then be used as the seed..).

On the server-side, an incorrect next-random results in punishment of that IP
(blockage for a period of time).  On the client-side, an incorrect next-random
results in immediate disconnection from the server with a Warning signaled.

Commentary is greatly appreciated,
  Chris




More information about the Squeak-dev mailing list