From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9d00a7db22818139 X-Google-Attributes: gid103376,public X-Google-Thread: fb57f,9d00a7db22818139 X-Google-Attributes: gidfb57f,public X-Google-ArrivalTime: 2001-03-04 04:54:55 PST Path: supernews.google.com!sn-xit-03!supernews.com!newsfeed.wirehub.nl!surfnet.nl!news-x2.support.nl!news-x.support.nl!news-feed.nld.sonera.net!news.soneraplaza.nl!not-for-mail Message-ID: <3AA239E8.BB9AA911@multiweb.nl> From: Thomas Boschloo Organization: Cypherpunk X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada,sci.crypt Subject: Re: Arcfour in Ada References: <983158039.27320.0.nnrp-08.9e98cc46@news.demon.co.uk> <3A9ADBAE.EFF0B8AC@multiweb.nl> <3A9B242E.D7D177A8@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 04 Mar 2001 13:49:44 +0100 NNTP-Posting-Host: 212.127.192.186 X-Complaints-To: abuse@sonera.nl X-Trace: news.soneraplaza.nl 983710345 212.127.192.186 (Sun, 04 Mar 2001 13:52:25 MET) NNTP-Posting-Date: Sun, 04 Mar 2001 13:52:25 MET Xref: supernews.google.com comp.lang.ada:5401 sci.crypt:18831 Date: 2001-03-04T13:49:44+01:00 List-Id: -----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 ) 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 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: boschloomultiwebnl