Cryptography-Digest Digest #96, Volume #12 Fri, 23 Jun 00 19:13:01 EDT
Contents:
Re: how to compare the securtity between ECC and RSA (Roger Schlafly)
Re: tomstdenis.com [WARNING: POTENTIALLY OFFENSIVE] (tomstd)
Re: Variability of chaining modes of block ciphers (John Myre)
Re: security problem with Win 2000 Encryption File System ("james")
Re: Questions about RSA............. ("Joseph Ashwood")
Re: AES key lengths (David Crick)
Compression & Encryption in FISHYLAND (SCOTT19U.ZIP_GUY)
Re: Compression & Encryption in FISHYLAND (tomstd)
Re: Compression & Encryption in FISHYLAND ("David S. Hansen")
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Re: Try it. (Andrew Bortz)
----------------------------------------------------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: how to compare the securtity between ECC and RSA
Date: Fri, 23 Jun 2000 13:18:06 -0700
DJohn37050 wrote:
> One can look that the space needs (beyond the time needs) for GNFS as a bonus
> or as critical.
Or you can just treat both as obstacles for an adversary.
If you have a 2-dimensional object, sometimes just knowing the
length is useful. Sometimes just knowing the width is useful.
But it is nearly always better to know the length and the width,
than to just know the length.
Likewise, it is useful to know the TIME and SPACE needs of
an attack.
------------------------------
Subject: Re: tomstdenis.com [WARNING: POTENTIALLY OFFENSIVE]
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 23 Jun 2000 13:16:27 -0700
Yeah, well it turns out it is because of my server... so I moved
to
http://www.geocities.com/tomstdenis/
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Fri, 23 Jun 2000 14:13:14 -0600
Guy Macon wrote:
<snip>
> Ah. Yes, if Code A can corrupt B as well as being flawed itself, then
> security will be decreased. My question is this: how is this different
> from running an unrelated program on the same computer? If A can corrupt
> B, then so can Microsoft Word.
Indeed...
(Perhaps I shouldn't bring up specific operating systems, or
applications; I can feel certain flame wars quivering nearby...)
> Perhaps we are making different assumptions. It sounds like you are
> assuming one big program with algorithm A and B in it. I assumed two
> entirely different programs running at different times and interfacing
> only through a text file that contains the ciphertext from A which is
> also the plaintext for B. It didn't occur to me to do it any other way.
I wasn't assuming one big program, but was assuming different things
than you, I think. See below. (Certainly I imagined some system where
the user interface hid choices like this - if there are N steps,
there is also some software which invokes those steps automatically.)
> >In the case of variable chaining modes, I think the consensus of the
> >professional paranoids would be that the theoretical strength added
> >(not a lot - and debatable) could not compensate for the possible
> >practical weakness (could even be fatal). Even adding a second
> >"strong" cipher is debatable, as a general principle; there would
> >have to be some reason (such as, we're protecting this data for
> >a hundred years, no trouble is too much, we'll spend as much as we
> >must to get it right).
>
> ...Which accurately describes many of us hobbyists' use of crypto.
> We don't need the extra strength any more than someone with a hot
> rod needs those new injectors or your average golfer needs those
> expensive new clubs.
I really didn't think of "hobbyist" applications at all. I was
envisioning work that was worth being paid for - as an employee, or
entrepreneur, or something. That is, I imagined a case where we
need to justify our allocation of effort (to ourselves, at least).
I don't see this kind of thing as "what to buy", where we can
rely on someone else having figured out how to get the assembly to
work, but that we were doing the figuring. And also I was thinking
of situations in which we really care what the security level is.
To extend the golfing analogy, we would be designing clubs for the
professional (whether to sell to that professional, or because we
are that professional).
(If anyone can fix the singular/plural mess I just made, feel free.)
I think that, if I were writing crypto programs for my own use (where
my worst enemy is probably an 8-year old), I would indeed try stuff
like double encrypting, or varying algorithms, etc. This for fun, or
speed, or general educational value. But for money, I would be a
fuddy-duddy, and make recommendations like "just use triple-DES for
now", or something. So, yes, I'd agree that our assumptions were
quite different.
John M
------------------------------
From: "james" <[EMAIL PROTECTED]>
Subject: Re: security problem with Win 2000 Encryption File System
Date: Fri, 23 Jun 2000 22:30:37 +0200
EFS ( encryption file system ) in Windows 2000 is a big shit.
It doesn't encrypt a volume but each file individualy if you activate
'crypted' in the properties of the file.
Even if you activate 'crypted' in the properties of a directory , each file
will be encrypt individualy ( with an other IV ) but the original file that
wasn't encrypted, remains on the disk ( deleted ).
No one can trust EFS !
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Questions about RSA.............
Date: Fri, 23 Jun 2000 13:38:23 -0700
I know Tom already answered but I'll give it a go anyway.
> 1) What are key bits??? In particular, a RSA public key @ 1024 bit is
> composed by a unique modulus???
Yes it is, if someone else has the same modulus they have the information
necessary to break your public key, something the is very bad for your
security.
> 2) How does the RSA crittography based on "block cipher" work?? In
> particular, how can I convert the plain text in number??
What you do is this:
choose a random number, the right size to key your block cipher, call this
number K
Then perform the following operations:
RSA(K, public key of the person it's going to)
BlockCipher(K, data to be sent)
This is done because block ciphers tend to be very fast relative to public
key ciphers, and offer at least equal security.
> 3) How rappresent the public and private key??
A fairly easy way to do it programmatically is to in memory store them in a
byte array, with a padding of 0's at the front, with a seperate integer
telling you the length. On disk, write the integer to he file first, then
write the byte array.
> P.S. Sorry for my english, that is far to be perfect............:(
Don't worry, I only speak English and mine still isn't perfect
Joe
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: AES key lengths
Date: Fri, 23 Jun 2000 22:09:32 +0100
David Hopwood wrote:
>
> The Rijndael spec only gives numbers of rounds for the 'official' AES
> key lengths.
See section 12.1 of the Rijn docs:
The key schedule supports any key length that is a multiple of 4 bytes.
.. We define an extension of Rijndael that also supports block and key
lengths between 128 and 256 bits with increments of 32 bits.
--
+-------------------------------------------------------------------+
| David Crick [EMAIL PROTECTED] RSA 22D5C7A9 DH BE63D7C7 87C46DE1 |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+-------------------------------------------------------------------+
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Compression & Encryption in FISHYLAND
Date: 23 Jun 2000 21:14:18 GMT
Any similarity in the following example is
pure randomness and not to be meant to be
related to real people or places or etc. It is
soully to communicate what could happen with
compression and encryption and people who use
it.
There was a fishy country that used upper case
ascii for every message. A self acclaimed genius
of this country develops an encryption program
for the masses called "SmellyBass" or SB for
short.
This super encryption method is to be used on
all the countrys email messages between pompuss
government officals. These messages are all DOS
Ascii and about a thousand DOS upper case ascii
characters "A to Z" all messages are the same
except for the last 20 Characters in the messages.
The people who send and recieve email messaages
change the keys very often as the block size is
very samll and the "uniticity" distance is short.
The country of Freedomland intercepts these messages
and trys to break them so they know what the governemnt
is up 2. But the people of fishy land are very
well schooled in narrow mindness and they cleverly
send a one message every 1 minute. Never mind that
99.99% of the time they use the same message over
and over again. Every so often they send a important
message and want all the equipment to be operative
and they change the key frequently enough that the
people of freedomland would never be able to solve
the complex cipher that was used spesially with
the frequently changing key.
But the people of freedomland never give up they
know even if the messages are long that the first
part when decrypted was always the same. The pople
of fishy land knew this 2 but did not care because
they send so much info and change the key so often
that the people of freedomland would never in a timely
manner with there meger sources be able to crack
enough messages to matter.
Things went this way for quite some time till a
Devious Wonder boy noticed that all messages sent
are archived and that lost of storage was being used
in Fishyland to store all the previous data. So he
decided to compress the data and to sent the data
after it was compressed through the encryptors
knowig that compression if it saved space would
actually increse the unicity distance and make
freedomlands task of breaking the encryption
that much harder. DW boy decided on the devlish
clever method of replacing the long message that
is used 99.99% of the time with the lower case letter
"z" since it was not being used and he left the
rest of messages alone he was sure this was
a safe lossless compression method. And then 99.99% of the
time that encrypted message would be sent. But Fisyland
had its spys and soon freedomland new of the devilish clever
compression program which saved vast amounts of space in
fishyland message storage facilites.
So here is what the people of freedland did. IF the
intercepted message was short they ignored using precious
resources since it was obvious what the message meant.
Since there was only one possible valid decompression for
the message. And there scientists decided that it was
not important what the key was since only one valid
decompression existed for the message.
So they were able to concentrate there meger resources
only on the rare longer encrypted messages so they could
break them in a timely maner. While in Fishyland they
foolishly thought they made the the job harder since they
have a fabulous compression method that in the therory
they whorshiped it had too increase the unitcity distance
and made freedomlands job of decrypting the new set of compressed
encrypted messages harder.
I leave it to the reader to see if they feel that fishyland
was better or worse off after implimenting there super compression
method before the encryption.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS **no JavaScript allowed**
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed ** JavaScript OK**
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction
of the truth."
------------------------------
Subject: Re: Compression & Encryption in FISHYLAND
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 23 Jun 2000 14:29:05 -0700
<snip>
Despite being an arrogant foolish ignorant mean person your
story was kinda funny.
Stop arguing about this junk, nobody in the world cares what you
have to say, since you never care what anyone else has to say.
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: "David S. Hansen" <[EMAIL PROTECTED]>
Subject: Re: Compression & Encryption in FISHYLAND
Date: Fri, 23 Jun 2000 22:28:10 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
WTF??
Where on earth did you get the impression that this Scott guy
is an "arrogant foolish mean person"? Is June 23rd National
Presumptuous Bastards Day or something?
*** David S. Hansen
*** [EMAIL PROTECTED]
*** http://www.haploid.com
"tomstd" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> <snip>
> Despite being an arrogant foolish ignorant mean person your
> story was kinda funny.
>
> Stop arguing about this junk, nobody in the world cares what
> you have to say, since you never care what anyone else has to
> say.
>
> Tom
>
> Got questions? Get answers over the phone at Keen.com.
> Up to 100 minutes free!
> http://www.keen.com
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.5.3
iQA/AwUBOVPksrUtlIUTAKGREQIWlQCg/rLV63lsIJGMygEiHSJ0bTWoCBEAoMHJ
1IRq4eXFb7cVKmhZs+ZHKGT5
=bTDc
=====END PGP SIGNATURE=====
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Sat, 24 Jun 2000 00:40:52 +0200
Guy Macon wrote:
> Here is the rub; for those of us with the described philosophy, the
> possibility that one of our attempts to enhance security may actually
> decrease it is poison to the whole concept. The chances of our tweaks
> actually increasing security are really, really, small and are easily
> wiped out by even a slight chance that what we do is counterproductive.
> Thus the argument of picking a strong cipher and doing nothing else
> has considerable merit.
I never said or implied that one should not choose the BEST cipher
that one CAN choose. Certiainly one should choose the best one
that one can afford to get. But after one has done that, i.e. now
that there is no more issue of the cipher one is going to use, there is
room to reflect on what chaining mode or chaining modes one should
use in order to achieve the optimum of security that one can achieve.
Chaining is in fact not entirely trivial and consequently to be neglected.
Otherwise, there wouldn't have been literatures that discuss that topic.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Sat, 24 Jun 2000 00:40:42 +0200
Mark Wooding wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > Let me reiterate my points:
>
> If you like. I'd like to see an answer to mine at some point, though.
>
> I've snipped and reformatted your text here.
>
> > 1. I showed that there are more than one chanining modes [...]
>
> True and accepted.
>
> > But if someone claims that CBC is the only best mode, then I do
> > like to hear his supporting arguments.
>
> Just to point out, my suggestion has been to keep life simple by just
> choosing a single chaining mode in your protocol (or choosing it at the
> same time as your cipher, if your protocol does that), rather than
> fiddling about with loads of different modes.
Your choosing a mode implies there exist a number of candidates
for you to choose. Am I right or not? The main purpose of my
original post is simply to point out there EXIST such candidates.
I did this, since I have the impression that whenever one talks
about block chaining one mostly means CBC, and I hoped to
change a little bit that state of affairs with my post. There is not
even the implication there that some of other candidate modes
may be superior to CBC, only that the other modes appear to
have been sofar neglected in my opinion. I intentionally left any
comparative merits to discussions. In particular, I did not attempt
to impose on the mind of the readers ANY way of actually selecting
the mode or the modes in accordance with what I personally think
is the best. So from which sentence of mine did you conclude that
I was suggesting to other people to 'fiddle about loads of different
modes'? That there ARE a number of modes is indeed what I called
attention to, but where is the suggestion of 'fiddling'? If a reader
learns from my post that there are different chaining modes and
studies these and makes (without any specific suggestion/guidance
from me) an intelligent choice of one or a couple of them and
implements these in ways that he thinks is right and for which he
takes (naturally) his own resposibility, what empowers you to
consider that he is 'fiddling'?? He is a free person just like you,
isn't he? (If he is foolish enough to do in some entirely poor ways,
that has nothing to do with my telling everybody that there EXIST
a lot of candidate modes -- unless you are of the opinion that some
parts of scientific knowledge should be kept secret from the public,
like what was practiced in the Middle Ages.)
> I've mentioned my preference for CBC with stealing, which is based
> primarily on the observation that it's `good enough' to avoid block
> substitution attacks, and that the security should rest in the cipher
> rather than the chaining mode. I'm much more interested that
> implementators should just choose one mode they're happy with than
> fiddle with all sorts of extra modes.
Your favorite mode is CBC. There can no objection from others
against your having that opinion at all. But you are clearly opposing
my making publicity for the 'exsistence' of the other candidate
modes, aren't you? It is your good right to point out with solid
arguments that CBC is indeed the best mode and others are for the
waste bin. But such arguments must be presented and presented
clearly and in convincing ways. Just saying that's your preference
is not enough. The last sentence of the above paragraph of yours
has been covered above.
> > 3. I argued that, even though exploitation of the variability in
> > question amounts only to a couple of bits of increase of key
> > space, it does have a good sense to do that in many situations,
> > because
>
> > switching to an algorithm that has greater key size, [...] may not
> > be a viable option in certain environments, due to e.g.
> > unavailability of the larger algorithms
>
> Why would other algorithms be unavailable? It's not difficult to find
> implementations of ciphers with `sufficiently large' key spaces. If the
> environment is already that constrained, why are you likely to have
> freedom to implement funny modes? And why can't you do something like
> triple-encryption with the cipher you've already got?
There could be many reasons why a particular algorithm has to be
used and there is no other choice. For instance, it could be that
my boss is strongly of the opinion that 3DES should be used, because
it is a current standard, or it could be that my firm has already
invested much money in certain hardware and is unwilling to throw
these away and buy new ones. That leaves me not much room to
manoeuvre than trying to see whether I could improve the matter
a bit through using some chaining modes which in my personal
judgement are better than ECB.
> > an improvement of a time factor of 2 or 3 may not be trivial in
> > respect of the chance of opponent's success, either because his
> > resource is already at the limit or because the usefulness of the
> > information is time-limited.
>
> I'd be extremely worried about making such fine estimates of my
> adversary's capabilities.
But something better IS anyway better than without that something,
isn't it? Why should one close one's eyes and forego a chance simply
because that chance is not very attractively big? To make an analogy,
certain cancers have currently very small chance of getting healed.
But patients are invariably taking all sorts of treatments in the hope
that, through sort of wonder, they'll get cured. Perhaps another:
at times of flu infection it is difficult to avoid getting sick, because
there
are lots of ways of spread of the virus that practically can't be
stopped. But often washing your hands after having contacted other
persons is known to reduce a bit the chance of an infection through
that particular path. Why should one neglect that prevention method,
even though one knows that there are plenty of other ways that one
might get infected and taking care to wash hands only reduces the
chance a tiny little bit on the average? If indeed in a concrete case I
would otherwise be sick (of course I would never really know that),
I should be happy to have taken the advice to wash hands, or not?
One can never correctly estimate what the opponent can do. That's
EXACTLY why one should keep ones eyes open to ALL opportunities
of improving one's security that one can afford to exploit.
> > BTW, I don't understand why one belittles chances of getting small
> > benefits.
>
> For crypto, it's because (a) they're not very useful, and (b) we can
> often get large benefits at pretty much the same cost.
Covered above.
>
> > In other contexts, I know, for example, plenty of people who care
> > much about the price differences among the supermarkets.
>
> Indeed. That's because they don't have possibility (b) above: they
> can't buy things lots cheaper, so they settle for buying things a little
> cheaper. And possiblity (a) doesn't apply as much: the benefit is
> measurable -- you save 5p per widget, say. In cryptography, the success
> metric is binary: your message is secure, or someone read it, and for
> increasing the difficulty for my adversary by a small amount to make a
> difference to my expectation of success means that I've decided
> extremely precisely what resources my adversary has to bring to bear on
> the problem. And this doesn't happen very often.
Also covered above. I repeated said that, if you have an encryption
system that you 'believe' is entirely secure, then you don't need my stuff
at all. But if you are not so sure (even AFTER you have done all your
best to get what is the best algorithm available to you), then
appropriately selecting a chaining mode or some chaining modes
improves your situation a bit and it is in my opinion unwise to simply
neglect that. If you think that tiny things are not worthy for you, it's
perfectly o.k. But other people may have other yardsticks to measure
what is worthy for them and they may be living in environments quite
different from yours.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Sat, 24 Jun 2000 00:40:58 +0200
Guy Macon wrote:
> I should add that, although the security will not be decreased, the cost
> (in bits of key, time needed to encrypt/decrypt, etc.) will be increased
> and thus the cost/benefit ratio might very well become worse.
That the cost/benefit ratio becomes worse is well possible, the opposite
is also well possible. It depends on the concrete cases. Note also that
the cost/benefit ratio cannot be entirely objectively determined.
M. K. Shen
------------------------------
From: Andrew Bortz <[EMAIL PROTECTED]>
Subject: Re: Try it.
Date: Fri, 23 Jun 2000 18:31:28 -0400
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> John <[EMAIL PROTECTED]> writes:
> > Yeah, OK. The only thing I've seen here is, "Give us the source,
> > and we'll let you know if it's secure." Without the source, all
> > you can do is brute force it.
>
> No, without the source anyone who wanted to break would have to
> reverse engineer it, and thats a lot of work. Any scheme relying on
> secrecy of the method used is insecure.
>
No, its not by definition insecure, but it should not be relied on
wholly for the security of the method. One great example would be a
modified RC6 cipher with different P and Q (P and Q are used in the key
schedule). If you didn't disclose the method, first an attacker would
need to reverse engineer the program to determine it was RC6, then find
the different P and Q. At that point, after hours and days of work, he
would be faced with a cipher that, at this point, there is no attack on
all 20 rounds. So obscurity can be useful, but most often it is more
useful to disclose the algorithm to assure your customer's of the
system's innate security.
Andrew
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
