Re: Arcfour in Ada

[Thomas Boschloo <nospam@multiweb.nl>]

-----BEGIN PGP SIGNED MESSAGE-----

Benjamin Goldberg wrote:
> 
> Thomas Boschloo wrote:

> > http://fling.sourceforge.net/wiki/index.php?full=arcfour
> >
> > Why did you decide to go for arcfour and not the AES
> > http://www.nist.gov/aes ? AFAIK Arcfour or RC4 was originally a
> > 'security by obscurity' cypher (Arcfour was (now illegal) reverse
> > engineered from RC4 by www.rsa.com).
> 
> Arcfour is not illegal, but the name "RC4" is trademarked.  To use a
> cipher called "RC4" without liscencing that trademark is illegal.  To
> use the algorithm is perfectly legal.

I guessed with the new DMCA (digital millenium copyright act), reverse
engineering RC4 might be deemed illegal as it possibly could be seen as
some form of 'protection' that is circumvented. I mean, what is all the
fuzz about DeCSS, 2600, eff about?! IANAL.

> The algorithm of RC4 was a trade secret, meaning that some "security by
> obscurity" was involved, but in spite of that, the algorithm is still
> fairly secure.

It got secure once the "security by obscurity" got circumvented by
Arcfour. But what if they had used "tamper resistant software", or even
hardware? I know these things won't work, but they make the job of
reverse engineering just a tiny bit harder.

> > I understand that you might like the idea of a stream-cypher for data
> > transmission, but aren't stream and block cyphers thought to be
> > somewhat identical in functionality by cryptographers?
> 
> Whoa!  No way, man!  Where did you get that wierd idea?  Stream and
> block ciphers are *very* different.  I'm not going to explain how they
> work, but here's the pros and cons of each:
> 
> Stream cipher, pros:
> You can encipher one byte [one word] at a time, fairly quickly.
> Stream cipher, cons:
> You can't use the same key to encipher more than one message.
> 
> Block cipher, pros:
> You can use one key to encipher more than one message.
> Block cipher, cons:
> You must encipher multiples of the block size.
> Fairly CPU intensive; slow.

Thank you for explaining this so clearly. I got my 'weird' (hey, you
write it the same way I used to also <vbg>) idea from the knowledge that
serial and parallel data can be expressed in each other. I didn't know
about the IV (but I should have) and the large difference in speed (in
fact, I still find 5 clocks a byte hard to grasp). But I figure that
Arcfour has some overhead because of the extra keys you have to send :-)

> ARC4 pros:
> Well known, easily memorized, hard to incorrectly implement.
> 5 clocks per byte of keystream.
> ARC4 cons:
> Minor bias in first bytes, (avoidable, discard first N bytes).
> Tiny correlation over large amounts of data (hard for enemy to detect).
> 
> AES pros:
> Fairly secure, well cryptanalysed.  No known weaknesses.
> AES cons:
> Complicated, easy to screw up... you almost have to copy someone elses
> implementation if you want it to be correct.

Funny that DoD doesn't have Rijndael in Ada, as they developed Ada in
the first place :-P I had a large interest in Ada because the design
philosophy appealed to me, but I figured it would be largely 'dead' by
now and replaced by C++ and Java :-( I don't like C++, it's a mess.

> > Couldn't you just use the 128 bit block size of Rijndael as a
> > (somewhat small) buffer for your traffic? Be honest, what would be the
> > overhead from the 128 bit boundaries?
> 
> How much overhead?  I'd say up to 128 bits.  Plus having a 128 bit IV.

Well, 128 bits is only 16 bytes/octets. And at least IP packages are up
to 64kb (but mostly 1500 bytes on a LAN and I think 500 bytes on the
internet).

To Julian (if he still frequents this newsgroup, my reply is a bit
overtime), I figured you could just use one of those 16 bytes as a
'length' field. You would even keep 4 bits of that 'octet' for other
purposes or future additions! The overhead doesn't seem as bad as you
presented at first (I seem to remember somehow that you thought it was
64 bytes, I might be mistaken).

And you wouldn't have the 'key' overhead in Arcfour (no idea how big
that would be in the long run).

Here are some RFC's you might consider reading (if you hadn't done so
already):

RFC 793 (TCP), 1122 (fixes), 1323 (extensions) => TCP protocol
RFC 768 => UDP (very easy and simple to understand)
RFC 791 => IP version 4
RFC 1883 => IP version 6 (longer addresses for the future)

Protocols like TCP/UDP are layered on IP and the RFC's can tell you the
sizes of the datagrams you can send with them.

> Whereas, with ARC4/Ciphersaber, there's only a 80 bit overhead for an
> IV, and no need for this kind of blocking.

Thank you again for your detailed and practical information, BG.

> > AES seems so much more secure in the long run than RC4!
> 
> But AES is slower, more awkward, and has more overhead.  Also, even if
> ARC4 might not be not quite as secure as AES, it is surely *secure
> enough* for this application.

I'm almost convinced ;-)

Thank you all for your time,
Thomas J. Boschloo
(Holland)

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>

iQB5AwUBOqIrzAEP2l8iXKAJAQHvfQMfcQpQRKWqDce5r+abXPGvqHQz7PLSUOmY
FqmvzQCr+i82kAOngHmmAc3Dp90YvZG6/TQhSNM0D7pRAbwcZ5RY40p40df2D2Fg
CXSEq3YigidkVGlImP5EGvWfDOe2W494B+3Qfg==
=8DuU
-----END PGP SIGNATURE-----
-- 
Jessica "I'm not bad, I'm just drawn that way"
My E-mail address: boschloo<at>multiweb<dot>nl