* Arcfour in Ada @ 2001-02-26 3:27 Julian Morrison 2001-02-26 22:41 ` Thomas Boschloo 0 siblings, 1 reply; 16+ messages in thread From: Julian Morrison @ 2001-02-26 3:27 UTC (permalink / raw) http://download.sourceforge.net/fling/arcfour-ada-1.0.0.tar.gz This code has been created for use with the Fling project (http://fling.sourceforge.net/). This is ArcFour (Alleged RC4), CipherSaber variant, capable of CipherSaber-1 and CipherSaber-2. It is coded in Ada, and is dependent on AUnit and Formatted_Output (available via the AdaPower site). It's probably pretty GNAT-dependent too, since I've had no need to compile it anywhere else. If you want fixes, send patches and/or bug reports via Fling's SourceForge patch tracker. This code has been placed in the public domain by its author. Release notes: first full release, all unit tests pass, but it may be implementation dependant. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Arcfour in Ada 2001-02-26 3:27 Arcfour in Ada Julian Morrison @ 2001-02-26 22:41 ` Thomas Boschloo 2001-02-26 23:20 ` Julian Morrison ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Thomas Boschloo @ 2001-02-26 22:41 UTC (permalink / raw) Julian Morrison wrote: > > http://download.sourceforge.net/fling/arcfour-ada-1.0.0.tar.gz > > This code has been created for use with the Fling project > (http://fling.sourceforge.net/). > > This is ArcFour (Alleged RC4), CipherSaber variant, capable of > CipherSaber-1 and CipherSaber-2. It is coded in Ada, and is dependent on > AUnit and Formatted_Output (available via the AdaPower site). It's > probably pretty GNAT-dependent too, since I've had no need to compile it > anywhere else. If you want fixes, send patches and/or bug reports via > Fling's SourceForge patch tracker. > > This code has been placed in the public domain by its author. > > Release notes: first full release, all unit tests pass, but it may be > implementation dependant. 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). 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? 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? AES seems so much more secure in the long run than RC4! (note: I am not a cryptographer nor have I every implemented a cypher) Thomas (BTW I do sympathize with your cause of an anonymous TCP/IP protocol. Good luck!) -- Jessica "I'm not bad, I'm just drawn that way" ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Arcfour in Ada 2001-02-26 22:41 ` Thomas Boschloo @ 2001-02-26 23:20 ` Julian Morrison 2001-02-27 0:58 ` Thomas Boschloo 2001-02-27 1:39 ` Larry Kilgallen 2001-02-27 3:54 ` Benjamin Goldberg 2 siblings, 1 reply; 16+ messages in thread From: Julian Morrison @ 2001-02-26 23:20 UTC (permalink / raw) "Thomas Boschloo" <nospam@multiweb.nl> wrote: > Why did you decide to go for arcfour and not the AES > http://www.nist.gov/aes ? > [...] > > AES seems so much more secure in the long run than RC4! AFAIK, the AES cypher is more secure in that you can safely reuse keys. It's also newer, though, and new crypto is less trustable. AES is also a very gread deal more CPU churn and overhead than Arcfour. Since you can only encrypt in blocks of four bytes, you need extraneous header info to show where the contents end, and you need to CBC the blocks together. If you're encrypting a lot of small things (such as in Fling's routeballs) the overheads will add up. From what I've understood from older messages here, Arcfour is "good enough" for the task at hand. Of course, if anyone knows I got this wrong, please do say. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Arcfour in Ada 2001-02-26 23:20 ` Julian Morrison @ 2001-02-27 0:58 ` Thomas Boschloo 2001-02-27 5:07 ` Julian Morrison 0 siblings, 1 reply; 16+ messages in thread From: Thomas Boschloo @ 2001-02-27 0:58 UTC (permalink / raw) Julian Morrison wrote: > > "Thomas Boschloo" <nospam@multiweb.nl> wrote: > > > Why did you decide to go for arcfour and not the AES > > http://www.nist.gov/aes ? > > [...] > > > > AES seems so much more secure in the long run than RC4! > > AFAIK, the AES cypher is more secure in that you can safely reuse keys. > It's also newer, though, and new crypto is less trustable. AES is also a > very gread deal more CPU churn and overhead than Arcfour. Since you can > only encrypt in blocks of four bytes, you need extraneous header info to > show where the contents end, and you need to CBC the blocks together. If > you're encrypting a lot of small things (such as in Fling's routeballs) > the overheads will add up. That makes sense. I believe you could perhaps use an escape character to identify the end of a string. Like (and I have to dig deep into my memory now) when you send a bit string, you could say that '000' marks the end of your bit string. If you need to actualy send '000' you pad it like '0010' or something like that. I am a bit rusty, have to look it up in my old study books. A better example might be the way printf and scanf work in C. '/' is the escape character (like '/n', '/0', etc.) and if you actually want to send a '/' you just send a '//'. It need not take up a lot of bandwidth/space I think. But I don't know much about implementing TCP. I do know that the freedom network stopped using fixed sized packages in version 2.1 or something, because it took up too much bandwidth. I seem to remember that they also use UDP for something but I am confusing myself now. The good thing about UDP is that you don't have to set up a connection to send data. It doesn't have to point back to you (which is good if you want to be anonymous). Well, who do I think I am :-) I'm sure you already know all you need to know and more ;-) Regards & Good luck, Thomas -- Jessica "I'm not bad, I'm just drawn that way" ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Arcfour in Ada 2001-02-27 0:58 ` Thomas Boschloo @ 2001-02-27 5:07 ` Julian Morrison 0 siblings, 0 replies; 16+ messages in thread From: Julian Morrison @ 2001-02-27 5:07 UTC (permalink / raw) "Thomas Boschloo" <nospam@multiweb.nl> wrote: > That makes sense. I believe you could perhaps use an escape character to > identify the end of a string. Like (and I have to dig deep into my > memory now) when you send a bit string, you could say that '000' marks > the end of your bit string. If you need to actualy send '000' you pad it > like '0010' or something like that. I am a bit rusty, have to look it up > in my old study books. Problems with that: you have to scan and escape, scan and de-escape every byte or byte-pair. Also over any nontrivial length of binary data, you are likely to need many escaped characters. Worst case, this can double your packet length. Contrast this with say a 64 bit "expect thus many bytes" header. Either way tho, you need to waste some overheads on that. > [...] I don't know much about implementing TCP. I > do know that the freedom network stopped using fixed sized packages in > version 2.1 or something, because it took up too much bandwidth. Yeah. Likely because most network traffic is small, so padding up to a fixed packet size mostly wastes space. The idea of padding is to make it impossible to use packet sizes to do traffic analysis. The way I'm thinking of doing that for my system, is: - each machine has a queue of multiple "inboxes", and one "outbox". - there is one inbox per intended recipient - inboxes are created on a first come first served basis - any packets recieved for a recipient with an existing inbox, go into that existing inbox - the sender part moves the first inbox off the queue and sends it all, then discards it and moves on to the next, etc - to send packets, they are crammed together but then padded at then end to an integer number of fixed size blocks. Then the bandwith wastage is only at most a block minus one byte. Of course in reality the algorithm will be a tad more complex, for example having a maximum size for inboxes to prevent popular recipients typing up the outbound line. This relies on the assumption that in most cases, although traffic is small, it's going repetitively to the same recipient. > I seem to remember that they also use UDP for something but I am > confusing myself now. The good thing about UDP is that you don't have to > set up a connection to send data. It doesn't have to point back to you > (which is good if you want to be anonymous). Thanks, you gave me a useful idea there - UDP outbound can have a forged "from" IP. Although I don't know how useful it will be in this system; each relay needs to send an "ack" back upstream after sending its messages. But it might be useful; I'll give it some thought. > Well, who do I think I am :-) I'm sure you already know all you need to > know and more ;-) Heh, I'm much of a newbie too. I built my Arcfour code from the ciphersaber cookbooks online; I'm no mathematician. Just a coder with an algorithm and some test data to validate against. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Arcfour in Ada 2001-02-26 22:41 ` Thomas Boschloo 2001-02-26 23:20 ` Julian Morrison @ 2001-02-27 1:39 ` Larry Kilgallen 2001-02-27 3:54 ` Benjamin Goldberg 2 siblings, 0 replies; 16+ messages in thread From: Larry Kilgallen @ 2001-02-27 1:39 UTC (permalink / raw) In article <3A9ADBAE.EFF0B8AC@multiweb.nl>, Thomas Boschloo <nospam@multiweb.nl> writes: > 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). Regardless of the merits of various algorithms, it helps to use the same algorithm as the person with whom you are trying to communicate. RC4 is present in several widely used applications. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Arcfour in Ada 2001-02-26 22:41 ` Thomas Boschloo 2001-02-26 23:20 ` Julian Morrison 2001-02-27 1:39 ` Larry Kilgallen @ 2001-02-27 3:54 ` Benjamin Goldberg 2001-02-27 5:28 ` Julian Morrison ` (2 more replies) 2 siblings, 3 replies; 16+ messages in thread From: Benjamin Goldberg @ 2001-02-27 3:54 UTC (permalink / raw) Thomas Boschloo wrote: > > Julian Morrison wrote: > > > > http://download.sourceforge.net/fling/arcfour-ada-1.0.0.tar.gz > > > > This code has been created for use with the Fling project > > (http://fling.sourceforge.net/). > > > > This is ArcFour (Alleged RC4), CipherSaber variant, capable of > > CipherSaber-1 and CipherSaber-2. It is coded in Ada, and is > > dependent on AUnit and Formatted_Output (available via the AdaPower > > site). It's probably pretty GNAT-dependent too, since I've had no > > need to compile it anywhere else. If you want fixes, send patches > > and/or bug reports via Fling's SourceForge patch tracker. > > > > This code has been placed in the public domain by its author. > > > > Release notes: first full release, all unit tests pass, but it may > > be implementation dependant. > > 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. 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. > 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. 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. > 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. Whereas, with ARC4/Ciphersaber, there's only a 80 bit overhead for an IV, and no need for this kind of blocking. > 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. -- A solution in hand is worth two in the book. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Arcfour in Ada 2001-02-27 3:54 ` Benjamin Goldberg @ 2001-02-27 5:28 ` Julian Morrison [not found] ` <oXb8ZDqjoLyP@eisner.encompasserve.org> 2001-03-04 12:49 ` Arcfour in Ada Thomas Boschloo 2 siblings, 0 replies; 16+ messages in thread From: Julian Morrison @ 2001-02-27 5:28 UTC (permalink / raw) "Benjamin Goldberg" <goldbb2@earthlink.net> wrote: > 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. Besides, someone else has already written AES in ada... ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <oXb8ZDqjoLyP@eisner.encompasserve.org>]
[parent not found: <3A9BC5FA.FA89B58A@optonline.net>]
[parent not found: <nMQm6.157$ms6.82520192@twister1.starband.net>]
[parent not found: <3A9BF442.7E840E64@optonline.net>]
* Re: On RC4 in C [not found] ` <3A9BF442.7E840E64@optonline.net> @ 2001-02-27 21:03 ` Roger Schlafly 2001-02-27 22:57 ` William Hugh Murray 0 siblings, 1 reply; 16+ messages in thread From: Roger Schlafly @ 2001-02-27 21:03 UTC (permalink / raw) "William Hugh Murray" <whmurray@optonline.net> wrote in message news:3A9BF442.7E840E64@optonline.net... Getting off-topic here ... > I was with IBM when the DoJ was even more unhappy with their business practices > than they are with Microsoft's. There was never a final judgement in IBM's > case but my reading of history suggests that the issues are, for the most > part, moot. Moot now, yes. Not in the 1970s. > DoJ abandoned its requests for relief and IBM never achieved the > kind of dominance which the DoJ seemed to fear. Some have suggested that that > was because, if IBM ever dreamed of such dominance, it took its eye off the > ball while it battled the government. IBM used to have 70% of the computer biz. IBM did change its business practices significantly as the result of its various antitrust legal difficulties. Some people argue that the rise of Microsoft was only possible because IBM was restrained. > I await the final judgement of the > courts in the Microsoft case, though I might prefer a settlement. However the > battle now joined ends, I hope that MS is not guilty of such an error. However > it ends, I doubt seriously that it will make anybody, much less everybody, > happy with any, much less all, of Microsoft's business practices. (Does that > sentence scan?) On the other hand, I also doubt that, at least in the long run, > it will make any difference. Perhaps, but the MS lawsuit has already had the effect of curbing some MS business practices. Companies from AOL to RealNetworks have prospered as a result. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: On RC4 in C 2001-02-27 21:03 ` On RC4 in C Roger Schlafly @ 2001-02-27 22:57 ` William Hugh Murray 2001-02-28 0:29 ` phil hunt 2001-02-28 5:07 ` Anne & Lynn Wheeler 0 siblings, 2 replies; 16+ messages in thread From: William Hugh Murray @ 2001-02-27 22:57 UTC (permalink / raw) Roger Schlafly wrote: > "William Hugh Murray" <whmurray@optonline.net> wrote in message > news:3A9BF442.7E840E64@optonline.net... > Getting off-topic here ... > > > I was with IBM when the DoJ was even more unhappy with their business > practices > > than they are with Microsoft's. There was never a final judgement in > IBM's > > case but my reading of history suggests that the issues are, for the most > > part, moot. > > Moot now, yes. Not in the 1970s. > > > DoJ abandoned its requests for relief and IBM never achieved the > > kind of dominance which the DoJ seemed to fear. Some have suggested that > that > > was because, if IBM ever dreamed of such dominance, it took its eye off > the > > ball while it battled the government. > > IBM used to have 70% of the computer biz. IBM did change its business > practices significantly as the result of its various antitrust legal > difficulties. The question remains as to whether or not that had anything to do with their change in fortune. I will grant you that we are all better off in that they no longer dominate. It is less obvious to me that there is a causal relationship between or prosperity and their loss of it. I will grant you that we will probably be better off when, rather than because, MS no longer dominates. I still question whether litigation and regulation are a necessary or efficient remedy. > Some people argue that the rise of Microsoft was only possible because > IBM was restrained. Perhaps. I would argue that IBM's change of fortune was rooted in * failure to recognize the reasons for the success of hardware competition from Digital, Apple, Prime, and Compaq * investing where its revenues were at the expense of investing where its growth was (mainframes v. small systems) * continuing to sell at the top as the scale of computers changed and decision making moved down in the enterprise * selling exclusively to the enterprise and ignoring the consumer * investing in OS/2 at the expense of Windows, SNA/SDLC and ISO/OSI at the expense of TCP/IP, token-ring at the expense of ethernet, host-guest at the expense of client-server, etc. * investing in closed/proprietary systems (e.g., AS/400) at the expense of open/industry-standard systems (e.g., Unix) In other words, they were protecting their market rather than growing it, protecting their advantage rather than innovating. I argued some of this at the time, certainly the first two, but most of it is easy to see in hind-sight. They shot themselves in the foot. They were driving over a rough and windy road while looking through the rear-view mirror. With this aim and vision, they needed no help from DoJ and were ill prepared to deal with Microsoft. (Speaking of MS, does any of this remind you of them?) > > I await the final judgement of the > > courts in the Microsoft case, though I might prefer a settlement. However > the > > battle now joined ends, I hope that MS is not guilty of such an error. > However > > it ends, I doubt seriously that it will make anybody, much less everybody, > > happy with any, much less all, of Microsoft's business practices. (Does > that > > sentence scan?) On the other hand, I also doubt that, at least in the long > run, > > it will make any difference. > > Perhaps, but the MS lawsuit has already had the effect of curbing some > MS business practices. Companies from AOL to RealNetworks have > prospered as a result. (Notice that many already complain about the dominance and business practices of both of these companies. We seem to have a penchant for attributing to predatory practices the results of wise, not to say courageous, investment and novel business models.) Having been through this once, I have more faith in the markets and competition than in litigation and regulation. Time will tell. In any case, this too is a discussion for another day and another forum. Perhaps over a glass of bubbly some time. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: On RC4 in C 2001-02-27 22:57 ` William Hugh Murray @ 2001-02-28 0:29 ` phil hunt 2001-02-28 5:07 ` Anne & Lynn Wheeler 1 sibling, 0 replies; 16+ messages in thread From: phil hunt @ 2001-02-28 0:29 UTC (permalink / raw) On Tue, 27 Feb 2001 22:57:28 GMT, William Hugh Murray <whmurray@optonline.net> wrote: > >Perhaps. I would argue that IBM's change of fortune was rooted in > >* failure to recognize the reasons for the success of hardware competition from >Digital, Apple, Prime, and Compaq >* investing where its revenues were at the expense of investing where its growth >was (mainframes v. small systems) >* continuing to sell at the top as the scale of computers changed and decision >making moved down in the enterprise >* selling exclusively to the enterprise and ignoring the consumer >* investing in OS/2 at the expense of Windows, SNA/SDLC and ISO/OSI at the >expense of TCP/IP, token-ring at the expense of > ethernet, host-guest at the expense of client-server, etc. >* investing in closed/proprietary systems (e.g., AS/400) at the expense of >open/industry-standard systems (e.g., Unix) I'd say the proximate cause of IBM's downfall in the 80s and early nineties was the decision to go over to PS/2 and OS/2, which were market failures and resulted in IBM losing control of the microcomputer market. In more general terms, they lost because other suppliers were undercutting them with cheaper computers. For reasons why this situation is, in general, hard to counter, read _The Innovator's Dilemma_ especially the chapter "What goes up can't come down". -- *****[ Phil Hunt ***** philh@comuno.freeserve.co.uk ]***** "Mommy, make the nasty penguin go away." -- Jim Allchin, MS head of OS development, regarding open source software (paraphrased). ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: On RC4 in C 2001-02-27 22:57 ` William Hugh Murray 2001-02-28 0:29 ` phil hunt @ 2001-02-28 5:07 ` Anne & Lynn Wheeler 1 sibling, 0 replies; 16+ messages in thread From: Anne & Lynn Wheeler @ 2001-02-28 5:07 UTC (permalink / raw) William Hugh Murray <whmurray@optonline.net> writes: > (Notice that many already complain about the dominance and business practices of > both of these companies. We seem to have a penchant for attributing to > predatory practices the results of wise, not to say courageous, investment and > novel business models.) > > Having been through this once, I have more faith in the markets and competition > than in litigation and regulation. Time will tell. In any case, this too is a > discussion for another day and another forum. Perhaps over a glass of bubbly > some time. there was some case made regarding some execs that might have been accused of taking a one time shot to quarterly earnings and their bonus converting a significant number of lease machines to purchased in the 70s. there was also june 23rd, 1969 with the separate charging for people services (aka unbundling; which had been packaged for "free" as part of customer support). following has comments supposedly attributed to testimony in the trial http://www.garlic.com/~lynn/94.html#44 -- Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: On RC4 in C [not found] ` <nMQm6.157$ms6.82520192@twister1.starband.net> [not found] ` <3A9BF442.7E840E64@optonline.net> @ 2001-02-28 5:36 ` Guy Macon 1 sibling, 0 replies; 16+ messages in thread From: Guy Macon @ 2001-02-28 5:36 UTC (permalink / raw) Roger Schlafly wrote: >Actually, a lot of people are unhappy that MS Windows is closed source, and >that MS uses it together with its monopoly power to enforce undocumented >APIs, >bundled products, and system insecurities. Witness the recent Anna K virus, >the explosive growth of Linux, and yesterday's antitrust hearing. Imagine yourself writing an email reader. You give the incoming email the ability to do various things (some with user permission only) such as display on the screen, be saved to disk, etc. Now imagine yourself giving the incoming email the ability to: [1] Send emails without telling the user or asking permission, [2] Read your address book so as to know who to send to. Now imagine the media jumping on the 13 year old moron who decided to eploit your little "feature", and never questioning your part in all of this. ...Pretty sweet deal Microsoft has, eh? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Arcfour in Ada 2001-02-27 3:54 ` Benjamin Goldberg 2001-02-27 5:28 ` Julian Morrison [not found] ` <oXb8ZDqjoLyP@eisner.encompasserve.org> @ 2001-03-04 12:49 ` Thomas Boschloo 2001-03-04 13:18 ` Sam Simpson 2001-03-04 21:08 ` Julian Morrison 2 siblings, 2 replies; 16+ messages in thread From: Thomas Boschloo @ 2001-03-04 12:49 UTC (permalink / raw) -----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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Arcfour in Ada 2001-03-04 12:49 ` Arcfour in Ada Thomas Boschloo @ 2001-03-04 13:18 ` Sam Simpson 2001-03-04 21:08 ` Julian Morrison 1 sibling, 0 replies; 16+ messages in thread From: Sam Simpson @ 2001-03-04 13:18 UTC (permalink / raw) Thomas Boschloo <nospam@multiweb.nl> wrote in message news:3AA239E8.BB9AA911@multiweb.nl... > > 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. It may be illegal now, but the the public release of RC4 predates DMCA. <SNIP> > Funny that DoD doesn't have Rijndael in Ada, as they developed Ada in > the first place :-P I'm sure they do have AES in Ada, but that doesn't mean they have to publish the fact? > > > 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. Use one of the chaining modes that can encrypt single bytes etc. > > > AES seems so much more secure in the long run than RC4! > > > > But AES is slower, more awkward, and has more overhead. Only if used in CBC. > > Also, even if > > ARC4 might not be not quite as secure as AES, it is surely *secure > > enough* for this application. Good point.... -- Regards, Sam http://www.scramdisk.clara.net/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Arcfour in Ada 2001-03-04 12:49 ` Arcfour in Ada Thomas Boschloo 2001-03-04 13:18 ` Sam Simpson @ 2001-03-04 21:08 ` Julian Morrison 1 sibling, 0 replies; 16+ messages in thread From: Julian Morrison @ 2001-03-04 21:08 UTC (permalink / raw) "Thomas Boschloo" <nospam@multiweb.nl> wrote: > But I figure that Arcfour has some overhead because of the extra keys > you have to send :-) You don't send extra keys, you send one partial key, you complete it with a new IV each time it's used, and prepend the IV to the message. > 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. There is Rijndael in Ada, available from the Adapower site. Unlikely to be guv'mint code - bureaucrats are born with "security through obscurity" hardwired into the soul. > To Julian (if he still frequents this newsgroup, my reply is a bit > overtime) I do :-) > , 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). I can switch to Rijndael easily, since there's Ada code for it, but it's fiddly and more bother than I care for, and the potential gain isn't great enough to justify the hassle. > And you wouldn't have the 'key' overhead in Arcfour (no idea how big > that would be in the long run). There isn't any, really, at least not any I wouln't need just as bad with Rijndael. > 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. Thanks for that info :-) ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2001-03-04 21:08 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-02-26 3:27 Arcfour in Ada Julian Morrison 2001-02-26 22:41 ` Thomas Boschloo 2001-02-26 23:20 ` Julian Morrison 2001-02-27 0:58 ` Thomas Boschloo 2001-02-27 5:07 ` Julian Morrison 2001-02-27 1:39 ` Larry Kilgallen 2001-02-27 3:54 ` Benjamin Goldberg 2001-02-27 5:28 ` Julian Morrison [not found] ` <oXb8ZDqjoLyP@eisner.encompasserve.org> [not found] ` <3A9BC5FA.FA89B58A@optonline.net> [not found] ` <nMQm6.157$ms6.82520192@twister1.starband.net> [not found] ` <3A9BF442.7E840E64@optonline.net> 2001-02-27 21:03 ` On RC4 in C Roger Schlafly 2001-02-27 22:57 ` William Hugh Murray 2001-02-28 0:29 ` phil hunt 2001-02-28 5:07 ` Anne & Lynn Wheeler 2001-02-28 5:36 ` Guy Macon 2001-03-04 12:49 ` Arcfour in Ada Thomas Boschloo 2001-03-04 13:18 ` Sam Simpson 2001-03-04 21:08 ` Julian Morrison
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox