>Try XORing the first block of 8 bytes with the second block of 8 before
>encrypting the second block. Perhaps the first 8 is meant to be used as an
>IV for what follows.
No, it doesn't work. I tried different XORing combination, before and
after encryption, with cleartext block and enrypted text block.
I think I know where the problem lies. SSH version 2 and version 1
differ in implementation of 3DES. While in SSH2 it is probably the 3DES
with CBC remebered at the level of the whole 3DES cipher (not separate
initialization vectors for each of three DES engines).
And in SSH1 there are three independent CBC-DES engines with independent
initialization vectors. And that is something i could not achieve with
the code I posted.
Actually, description is like this:
The variant of triple-DES used here works as follows: there are
three independent DES-CBC ciphers, with independent initializa-
tion vectors. The data (the whole encrypted data stream) is
first encrypted with the first cipher, then decrypted with the
second cipher, and finally encrypted with the third cipher. All
these operations are performed in CBC mode.
The key for the first cipher is taken from the first 8 bytes of
the session key; the key for the next cipher from the next 8
bytes, and the key for the third cipher from the following 8
bytes. All three initialization vectors are initialized to
(Note: the variant of 3DES used here differs from some other
Can someone verify if I am correct with above assumptions? I am actually
trying to write the proper decoding code, but it still doesn't work.
Maybe someone can help me?
> Hi, maybe you can forward Davids solution to your problem to the
> mailing list. thanks, kind regards, Thomas
Well, if you are still interested (I see you have found the solution
already) - I wrote a class to use in SSH version 1 protocol 3DES CBC
mode - it is different than bouncycastle 3DES implementation, so it
requires special handling.
Works for me, although I noticed some problem lately, received packets
have wrong CRC - some unexpected data is being read from socket - maybe
it's just a race condition problem, but may be truncating the encrypted
message or not shifting the key when expected as well. So do not treat
it as a complete or a safe code.
/* SSH1 uses different 3DES than standard BouncyCastle DESedeEngine,
* so this is the implementation
* @author Pik Master
public class CBCDESedeSSH1Engine extends CBCBlockCipher
protected static final int BLOCK_SIZE = 8;
private CBCBlockCipher des1, des2, des3;
private boolean encrypting; //are we ancrypting or decrypting
CBCDESedeSSH1Engine (BlockCipher cipher)
super(cipher); //create fake instance - only for
public void init(boolean encrypting, CipherParameters params)
if (!(params instanceof KeyParameter))
throw new IllegalArgumentException("invalid parameter passed
to DESede init - " + params.getClass().getName());
this.encrypting = encrypting;
des1 = new CBCBlockCipher (new DESEngine());
des2 = new CBCBlockCipher (new DESEngine());
des3 = new CBCBlockCipher (new DESEngine());
byte SessionKey = ((KeyParameter)params).getKey();
if (SessionKey.length > 24)
throw new IllegalArgumentException("key size greater than 24
byte key = new byte; //subkey
System.arraycopy(SessionKey, 0, key, 0, 8);
des1.init (encrypting, new KeyParameter(key)); //false =