Cryptography-Digest Digest #794, Volume #13 Sun, 4 Mar 01 09:13:01 EST
Contents:
Re: Arcfour in Ada (Thomas Boschloo)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: => FBI easily cracks encryption ...? ("kroesjnov")
Re: Arcfour in Ada ("Sam Simpson")
Re: OverWrite freeware completely removes unwanted files fromharddrive ("Dan Beale")
Re: Good Security Products?? ("Simon Johnson")
Re: ARCFOUR and Latin Squares ("Henrick Hellstr�m")
----------------------------------------------------------------------------
From: Thomas Boschloo <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.ada
Subject: Re: Arcfour in Ada
Date: Sun, 04 Mar 2001 13:49:44 +0100
=====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
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sun, 04 Mar 2001 05:04:46 -0800
Scott Fluhrer wrote:
>
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > The Foolish Dozen or so in This News Group
> >
> > Read below. It'll be just like being forced to look into a mirror.
> > You'll see who you all really are. Read it an weep.
> >
> > Here is why I think Ciphile Software's OverWrite program actually
> > <majorsnip>
>
> careful with your fopen() and your fclose() functions won't help you there
> either.
>
> --
> poncho
"...After all, it's in control of the file system... See,
logically..."
What people fail to perceive quickly enough is that we are talking
to several sick minds.
I guess what you say is true even if I am writing to the file in
append binary mode, I suppose? NOT!
"...known as Unix which as precisely this property..."
You are slandering UNIX. If a conditional statement is coded then
even UNIX has enough common sense to confirm the outcome of that
condition before proceeding.
(Now I know why some guys leave some chicks. They are able to get
in their pants with these sorts of flimsy smooth ridiculous lies.
What guy would ever consider sticking with such a bimbo?)
So, what you are saying is that everything goes on in cache and that
disk space is not under the operator's control. A file can be
written to one place on a hard drive then read into cache.
Processed then written to a completely different place on the hard
drive. And this process can continue I suppose until the entire
hard drive has been written over once and no bit locations have been
overwritten.
I would think this is not likely because of the optimization you
claim to be expounding. The drive heads are already over these bit
locations. To wander all over the hard drive writing to no
predetermined fixed hard drive bit locations would be inefficient
and un-optimizing.
With the reliability of computers these days most operations do take
place successfully. There is no reason for the write locations to
be moved around repeatedly. Give us a real world reason that happens
regularly. You have only given us a once in a blue moon possibility
that it might happen. What do you think, once in 100,000,000 writes?
Put it away.
Your hard drive was quiet because the heads did not move once they
were in position. Is that about 1GB with no head movement in 156
seconds? If you say so. This is not the point.
The specific point is whether or not a write operation is actually
taking place in Ciphile Software's OverWrite Security program. I am
saying that it is by all my reasoning. The fclose() function with a
conditional statement seems to force a write but you are saying that
the head is wandering all over the hard drive and writing the
resultant files repeatedly all over the hard drive in binary append
mode.
So what you are saying is that even if I just overwrite one character
in a file this entire file will be loaded into cache if it will fit
and this one character will be changed and then the entire file will
be written to some other location on the hard drive so that there
will be two files on the hard drive: the original file and this
newly written file. And your position is that this is your view of
optimization.
Interesting.
"...These things typically have no knowledge of the file system..."
You'll run to any length it is apparent to avoid the topic.
"...Another nasty problem arises if disk compression is in use...."
Run on. Run on.
Has anyone seen the topic of this thread laying around here anywhere?
"...disk drives often write bits to parts of the drive without you
asking it to...."
What does this mean: a bit here a bit there? Stopped running to
other topics to run off about who knows what this means: "...disk
drives often write bits to parts of the drive without you asking it
to...."
Can't you resolve a topic and not just merely kick up dirt and dust?
Geeze.
Like I said: What people fail to perceive quickly enough is that we
are talking to several sick minds.
LSD or DMT
anything instead of more of this rubbish.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sun, 04 Mar 2001 05:07:50 -0800
Sam Simpson wrote:
>
> ...
> > His initials are Bill Gates.
> ...
> > What do you think?
> ...
>
> Let's hope your crypto software is better than your grasp of the English
> language, eh? ;)
A man of few words is a man I can listen to.
Cheers.
------------------------------
From: "kroesjnov" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Sun, 4 Mar 2001 14:12:25 +0100
> > If you want my opinion on this:
>
> Not particularly. The young are almost universally on the side of what
they
> believe to be that of "truth and justice;" it is part of your beauty.
Those of
> us who have been around a few generations understand that it is easier to
be on
> the side of truth and justice than it is to know where that side is.
Well, Time will tell me, if you are right on this :)
> > This was wrong afcourse, and so history has
> > teached us (The hard way).
>
> If history teaches us anything, it is that her lessons are not persistent.
The
> newest generation often forgets them and is forced to recapitulate them.
This is indeed a flaw many humans seem to have: Repeating faults which has
been made in the past. Although they should know better by now i guess...
Funny thing though...
> > Yet I do not see the connection to the ability off a Secret Service
being
> > abble to crack an encrypted message (With effort afcourse), So that
> > Terrorist could be intercepted, who are going to bomb some building in
The
> > Netherlands, or any other Country in the World.
>
> The connection is subtle. What concerns us is that government is a big
and
> clumsy tool. It is difficult to control under the best of circumstances.
One
> man's terrorist is another's freedom fighter. It is necessary to order
but not
> necessarily orderly. It is difficult to tell, much less preserve, the
> difference between the legitimate authority of government and tyranny.
The
> governed cannot always recognize it from the outside and the governing
seem to
> have an even greater difficulty seeing it from the inside. They become
confused
> between their doing what is legitimate and that what they are doing is
> legitimate.
I see.
What also is a problem with goverments, is that is consists off many parts,
which work together. One problem with that is that those many parts, may
have different goals, and such may not be working together, but against each
other (This goes afcourse not for everything they do, but in the little
things, they may have different goals, and this can pose a problem).
> > Did I assume wrong, on what you are referring to? Or do I just missed
the
> > point you were trying to make?
>
> If you had been there, the point would have been obvious. Because you
were not,
> it was poorly made.
I understand.
Yet this discussion makes it more clear for me.
> > Please be patience with me, I may be slow off understanding...
>
> You may trust that we will be patient with you. It is usually the young
who
> lose patience first.
That is indeed true :)
> > "Wisdom lies not in obtaining knowledge, but in using it in the right
> > way".....
>
> ....and in the ability to recognize the right way in a novel situation.
mhh, I might even add that to my quote :)
> While the young tend to believe that the world has always been as they
found it,
> it is in the nature of being young that all situations are novel. The
study of
> history can help. History are the stories we tell ourselves about who we
are
> and we got to be this way.
I have always found history to be very interesting, and I am eager to learn
more.
I will keep this lesson close.
"Wisdom lies not in obtaining knowledge, but in using it in the right way"
kroesjnov
email: [EMAIL PROTECTED] (remove nov to reply)
UIN: 67346792
pgp fingerprint: 4251 4350 4242 7764 80DA DB1C E2B2 850A DF15 4D85
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.ada
Subject: Re: Arcfour in Ada
Date: Sun, 4 Mar 2001 13:18:06 -0000
Thomas Boschloo <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> 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/
------------------------------
Reply-To: "Dan Beale" <[EMAIL PROTECTED]>
From: "Dan Beale" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite freeware completely removes unwanted files fromharddrive
Date: Sun, 4 Mar 2001 13:29:34 -0000
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> If you even bothered to read the Help Files you would find that the
> random numbers that are at the basis of the Original Absolute
> Privacy - Level3 software are generated as a result of true random
> user input.
It is frightening that you cannot understand that this is a flaw. Users
cannot be relied upon to create sensible passwords, passphrases, or random
numbers. There is much research showing how bad humans are at random
numbers.
> The software will accept as long a key as the user has the patience
> and desire to imput.
! blimey.
> All you as a cracker needs to do is duplicate this true random number
> input string.
really ?
> It is left up to the user to decide how he or she generates this
> random input. I do make a few suggestions: numbering beans and
> placing them in a bottle and shaking the bottle then drawing the
> beans from the bottle one at a time to get a number sequence, or
> by shuffling a deck of cards and using the sequence of each suit in
> the deck, for instance.
enigma was broken partly through faults made by the users.
(all crypto software can be more or less secure depending on the user, but
your appears to be just plain insecure)
> How good are you at guessing the order of ten or fourteen numbered
> beans drawn from a bottle? How do you think you'd do guessing 10 or
> 20 or 100 14 number sequences of the numbers from 1 - 14 produced as
> a result of drawing numbered beans from a bottle?
with modern computing it shouldnt be too hard to do analysis. One of
those beans is going to be heaviest, and one of those beans is going to be
lightest. your 'random input' is weak. 'shuffling a deck of cards'?
sheesh.
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Good Security Products??
Date: Sun, 4 Mar 2001 13:38:51 -0800
Matthias Bauer <[EMAIL PROTECTED]> wrote in message
news:97o886$noi$[EMAIL PROTECTED]...
> Hi there,
>
> I want to secure a client (pure Java) / server network (C++) for a
document
> management system. I have already a complete implementation of the network
> API, but without any security components and I'm not very familiar with
any
> products on the market.
>
> Now I'd like to have a list of serveral providers
> (commercial/none-commercial) of products for security components in a
> client/server environment.
>
> Thanks,
>
> Matthias.
>
"Security is a process not a product" -- The guy who said this has sense.
Each system has it own quirks and possible security threats and therefore
it's difficult for a generic product to produce good security. The system is
only as secure as its weakest link, and almost every case this is the user..
Anyway: Are your documents going to be sent across the network or stored on
a local machine to be read by only one person? Is there going to be some
adminstrator figure that can read all the documents? -- Questions like this
have to be answered really before any suggestions can be made.
Simon.
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: ARCFOUR and Latin Squares
Date: Sun, 4 Mar 2001 15:02:05 +0100
"r.e.s." <[EMAIL PROTECTED]> skrev i meddelandet
news:97srij$1nh$[EMAIL PROTECTED]...
> "Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
> news:97savq$p61$[EMAIL PROTECTED]...
> | Don't just use any kind of binary operation. It is fairly easy to prove
> | that
> | you will significantly weaken the cipher unless you use the operation of
a
> | cyclic abelian group.
>
> Thanks for pointing this out. It does make intuitive sense
> that the group should be cyclic (and hence abelian).
> Are the 256 Latin Squares that are the value-tables of
> (x+y+constant) mod 256 (constant = 0..255)
> the only ones corresponding to cyclic groups over Z(256)?
A small correction. I wrote that message 4 am local time, so I seem to have
used some confusing terminology. The group does not have to be cyclic in the
common sense that each non-zero element is a generator - of course, since
(Z(256),+) isn't cyclic in that sense. The criterion is that (Z(256),op):
(i) is closed under op.
(ii). is associative, i.e.: a op (b op c) = (a op b) op c
(iii) is commutative, i.e.: a op b = b op a.
(iv) contains an identity z such that a op z = a.
(v) contains a generator g such that for each element a there is an integer
k such that kg = a.
(Note that these criteria implies that each element a has an inverse b such
that a op b = b op a = z. If a = kg, then b = (256-k)g.)
Each finite group with these properties is isomorphic to a group of integers
under modular addition. You could use any 256 element permutation to create
such a group, simply by letting phi be equal to that permutation and define
op such that phi(x op y) = phi(x) + phi(y). But as I wrote, these operations
will fall through all steps and simply substitute the key and the output. (I
think I wrote something like that the operations would "permute" the output.
"substitute" is probably a more common term.)
[snip]
> If I understand your notation, we can check for consistency
> in the special case of op=+, with x(0)=y(0)=e(0)=S(0)[0]=z=0,
> g=1, phi(x)=x, and sigma(0) = (0 1 2 3 .. 255).
>
> I may have badly misread your meaning in the following,
> so please help me understand your notation if I got it wrong.
> (*** marks revisions according to your followup posting.)
>
> | RC4Abelian:
> | 1. x := sigma(i)[y(i)].
>
> Is this supposed to correspond to "x = x + 1"?
> Maybe x := sigma(i)[x(i)] ?
> Whichever it is, I don't see how sigma(i), which evolves
> with i, can properly correspond to modulo addition of a
> *constant*.
This line corresponds to i := i + 1 in the original algorithm, and x
corresponds to S[i]. y(i), not x(i), is the argument on the right side
because x and y have been swapped by the algorithm.
> | 2. y := sigma(i)**phi(x)[x(i)]. [***]
>
> Is this supposed to correspond to "y = y + S[x]"?
No, rather j := j + x. x(i) carries the information of j. y corresponds to
S[j].
[snip]
> | 3. sigma(i+1) := (x y)*sigma(i).
>
> Ok, "swap S[x],S[y]"; but what does the following do?
> Where was x(i+1) assigned a value?
>
> | 4. if x(i+1) = e(i) then
> | e(i+1) := y
> | else if y(i+1) = e(i) then
> | e(i+1) := x
> | else
> | e(i+1) := e(i).
> | 5. output(i) := sigma(i+1)**phi(x)[sigma(i+1)**phi(y)[e(i+1)]].
Step 4 keeps track of the element S(i)[z], where z is the identity of the
group (Z(256,op). sigma doesn't do that by itself, because there are 256
rotations of S corresponding to sigma.
Step 5 corresponds to output = S[S[i] op S[j]] = S[x op y] = S[(x op y) op
z] = sigma**(phi(x) + phi(y))[S[z]].
> I don't understand step 4 at all, but is step 5
> supposed to correspond to "output = S[S[x]+S[y]]"?
> How?
I doesn't. It rather corresponds to S[x + y]. Another way of explaining the
relation is to note that, for some integer k, y = kg, so S[x + y] = S[x +
kg] = sigma**k[S[x]]. The last step follows more or less directly from the
definition of sigma and the group properties. Also note that k = phi(y) (mod
256).
[snip]
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
