dontspam-tzeruch(_at_)ceddec(_dot_)com says:
2. The algorithm allows variable-length key. I say - make it 128 bits
for the sake of simplicity.
I assume this is the key material.
Hm... "Key material" isn't "officially" standard, so...
When people say "56-bit DES' - this is the key they mean.
When they say "80-bit SKIPJACK" or "128-bit IDEA" - that's the key.
So here the key can be whatever you wish (between 40 and 256 bits),
and I suggest to fix it at 128, because [in my understanding] a
user isn't likely to input that key directly anyway. On the
other hand, if you see it feasible to allow variable-ness,
I of course won't mind. Or if you prefer a different length
value (say, 256, or 80, or 96) - I can live with it too.
3. Key schedule is described completely and explicitly in the paper
I e-mailed to several list participants a while ago.
Is there a URL? You may want to upload it
(to ftp://www.cryptography.org/pub/incoming if it is nonexportable).
Steve Bellovin has it on his Web:
http://www.research.att.com/~smb/papers/ides.ps
I have a slightly updated copy (basically explains how and why DES/SK
is immune to related-key attacks).
Oh, and my attempt to upload it failed miserably - ftp doesn't get
a login prompt.
4. Parts of the source code are available (alas, very incomplete).
This creates a problem. If I can't do something like encrypt
"abcdefghijklmnopqrstuvwxyz" and verify that it encrypts to 0x365ef2a or
whatever.
Look at it from a different prospective: whatever you do IS the
etalon for verification. (:-)
5. The main "crypto" engine uses straight DES rounds, so everything
applicable to DES (source code, docs etc) applies here.
What it does is: takes the user key, does some funny things with
it that are described on the algorithmic level in the paper, use
the result as a longer key schedule for DES but iterate not 16
but 32 rounds.
I would have to see the details.
Try to take a look at the paper, OK? Please let me know if it isn't
sufficiently clear, or if something doesn't jive...
6. The mode can be PGP-CFB. Text prefixed with <BLKSIZE>+2 random bytes,
zero IV.
and BLKSIZE is?
Since DES is 64-bit, and since it used part of the DES key schedule and
all of the DES round finction - it's 64-bit. [It isn't worth extending
to 128-bit, because the main idea was to preserve the "original" DES...
All the cryptanalytic tests done on DES apply fully. Once we start doin'
something to the rounds (besides increasing their number :-), many bets
are off.]
--
Regards,
Uri uri(_at_)watson(_dot_)ibm(_dot_)com
-=-=-=-=-=-=-
<Disclaimer>