Arcfour in Ada

Arcfour in Ada

[Julian Morrison]

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.

Re: Arcfour in Ada

[Thomas Boschloo]

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"

Re: Arcfour in Ada

[Julian Morrison]

"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.

Re: Arcfour in Ada

[Thomas Boschloo]

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"

Re: Arcfour in Ada

[Julian Morrison]

"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.

Re: Arcfour in Ada

[Larry Kilgallen]

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.

Re: Arcfour in Ada

[Benjamin Goldberg]

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.

Re: Arcfour in Ada

[Julian Morrison]

"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...

Re: On RC4 in C

[Roger Schlafly]

"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.

Re: On RC4 in C

[William Hugh Murray]

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.

Re: On RC4 in C

[phil hunt]

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).
               

Re: On RC4 in C

[Anne & Lynn Wheeler]

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/

Re: On RC4 in C

[Guy Macon]

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?

Re: Arcfour in Ada

[Thomas Boschloo]

-----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

Re: Arcfour in Ada

[Sam Simpson]

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/

Re: Arcfour in Ada

[Julian Morrison]

"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 :-)