Package net.kano.joscar.rvcmd.trillcrypt

Provides a default implementation of the RV commands used in initializing and communicating over an encrypted IM session via the protocol created by the developers of Trillian, an IM client for Windows.

See:
Description

Class Summary

AbstractTrillianCryptRvCmd	A base class for the five Trillian Secure IM rendezvous commands provided in this package.
TrillianCryptAcceptRvCmd	A rendezvous command used to accept a Trillian Encryption session.
TrillianCryptBeginRvCmd	A rendezvous command used to "begin" a Trillian Encryption session.
TrillianCryptCloseRvCmd	A rendezvous command used to end a Trillian Encryption session.
TrillianCryptMsgRvCmd	A rendezvous command used to send an encrypted message over a Trillian Secure IM connection.
TrillianCryptReqRvCmd	A rendezvous command used to initiate a Trillian Secure IM session.

Package net.kano.joscar.rvcmd.trillcrypt Description

Provides a default implementation of the RV commands used in initializing and communicating over an encrypted IM session via the protocol created by the developers of Trillian, an IM client for Windows.

Note that as of this writing, it is unknown how exactly the sessions are encrypted. The Trillian website claims the encryption is Blowfish with a key negotiated using a Diffie-Hellman system, but such a system seems not to yield the correct results. This is probably due to something wrong with the key exchange algorithm. Below is what is currently known about Trillian Encryption's key exchange system:

• Not enough arguments are passed between two clients to satisfy a true Diffie-Hellman key exchange. In Diffie-Hellman, there are three variables normally transmitted by one client, and one sent back by the other. The Trillian Encryption protocol only transmits two and one.
• It appears that the missing variable is g, the "generator" or exponent base. This value appears to always be 5. This was discovered by passing in different modulus values in the TrillianCryptReqRvCmd: a value of 5 causes Trillian to crash every time. This appears to be because if the generator is 5 and the modulus is 5, 5x mod 5 is always 0, which could concievably cause Trillian to crash if it attempted to divide by that value.
• Normally, a Diffie-Hellman key exchange is 512 or 1024 bits. In fact, the Sun JCE provider's implementation only allows keys whose sizes are a multiple of 64 between those values. This could be irrelevant; Diffie-Hellman can be performed with a key of any size.
• It seems, then, that it should be easy to implement Trillian Encryption (with a working knowledge of Diffie-Hellman and the JCE's Blowfish implementation, of course). However, the key exchange simply doesn't work with the parameters specified above and in the protocol. Perhaps the generator is actually some other number that happens to be a multiple of 5. Watch this space.

Note that the normal sequence of commands in a Trillian Secure IM connection is as follows:

• A: TrillianCryptReqRvCmd to request a session
• B: TrillianCryptAcceptRvCmd to accept a session
• A: TrillianCryptBeginRvCmd to begin the session
  
• A and B: TrillianCryptMsgRvCmds containing message text
  
• A or B: TrillianCryptCloseRvCmd to close the connection

See Also:

CapabilityBlock.BLOCK_TRILLIANCRYPT