Cryptography Reference
In-Depth Information
The practical consequence is that RC5a-encrypted texts can be exchanged
between Intel computers and Sun workstations, for example. The reference
implementation in [RivRC5] does not use a binary input and output, which
means that it doesn't solve the byte-order problem.
Cryptographic Details: Passphrase and Ciphering Mode
When entering a passphrase, the
check passphrase()
function currently only
verifies whether it contains both letters and numbers, and whether it is at least
six characters long. It is very easy to modify this function.
The ciphering mode is more interesting. If you set the macro SIMPLE CBC
(compiler switch
-DSIMPLE CBC
) during the compilation, then
rc5a
works
in CBC mode. By default, however, it doesn't XOR the plaintext with the
last ciphertext block, but instead carries two 32-bit words,
CBC A
and
CBC B,
along in parallel for the encryption. In every ciphering step,
CBC A
is increased
by the left half ciphertext block rotated, and
CBC B
is decreased by the right
half ciphertext block rotated. The rotation amounts are determined from the
right or left
plain
text half blocks, respectively:
CBC_A += ROTL(A,B0)
CBC_B -= ROTR(B,A0)
(
B
0
,A
0 are the plaintext half blocks.) Admittedly, this is a willful ciphering
mode and very much tailored to RC5. But I haven't discovered a vulnerability
yet. In the event that you need a self-synchronizing mode, you can convert
'
+=
' and '
−=
' into simple equal signs, while still using a novel type of
mode (meanwhile I'm doubtful of such experiments, but keep the mode for
compatibility reasons).
If you want to use RC5 instead of RC5a, you simply set
#define KEYBOX_BITS
0
to make each keybox consist of one single element only, and RC5a will turn
into RC5. A good compiler will then create a code that's just as short as if you
compiled RC5 directly. The use of RC5a won't have measurable performance
losses anyway.
