Cryptography-Digest Digest #605, Volume #10 Sun, 21 Nov 99 20:13:03 EST
Contents:
Re: Where's a good online discription of SHA1 or MD5? TIA (CoyoteRed)
Re: AES cyphers leak information like sieves (Jerry Coffin)
Re: SCOTT16U SOLUTION ON THE WEB (Xcott Craver)
Re: RC4 in Kremlin US version 2.21 to tom st denis (Xcott Craver)
Re: AES cyphers leak information like sieves (wtshaw)
Deja.Com Daily Digest: sci.crypt 1/1 ([EMAIL PROTECTED])
Re: AES cyphers leak information like sieves (wtshaw)
Re: Filters, Superpositions and Entanglements ("karl malbrain")
Re: math (Tom St Denis)
Re: RC4 in Kremlin US version 2.21 to tom st denis (Tom St Denis)
Re: What part of 'You need the key to know' don't you people get? (Tom St Denis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: Where's a good online discription of SHA1 or MD5? TIA
Date: Sun, 21 Nov 1999 19:17:47 GMT
Reply-To: this news group unless otherwise instructed!
John Savard said...
> My site has a description of SHA-1 on it; hopefully it is clear.
>
> John Savard (don't snooze, don't snore)
> http://www.ecn.ab.ca/~jsavard/crypto.htm
Thanks. I got an overall view of it. I'll have to go back and study
it in more detail.
If I follow hashes correctly, one takes a file and produces a hash of
that file. This hash is fairly unique in that, if you change just a
single bit, the hash changes dramatically. But, one can still have
collisions, two (or more) messages can have the same hash.
So now my question is, can someone produce a message that has a
desirable hash value?
The reason I ask is there was someone who was claiming that the
fingerprint in PGP can be determined before the key is made and thus
get a 'vanity' fingerprint. Supposedly this is "common in PGP
circles." I no longer have that message on this machine (and no web
browser to do a deja search), but there was even a name for this
predetermined fingerprint scheme.
Now my main question is, if you can get many files from a single hash
value (PGP's fingerprint) what's to stop a man-in-the-middle attacker
from creating any key pair that has the same fingerprint as our key?
This would mean that we could be subject to a man-in-the-middle attack
even if we call to verify the fingerprint. If this is so, then the
circle of trust scheme is also defeated. Couldn't then the attacker
make his own keys for each signer (with the appropriate hash, etc.)
and sign his bogus key and make it look even more authentic?
Or is making a key pair with any one particular 512 bit hash just too
difficult to be practical?
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: AES cyphers leak information like sieves
Date: Sun, 21 Nov 1999 12:47:17 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> : First of all, consider David's reasoning here: he says that since
> : _most_ people lack the software to recover from such a situation
> : that the fundamental capability "can only be of use to a dedicated
> : attacker." This is nearly a textbook example of fallacious reasoning.
> : To say it can only be of use to a dedicated hacker he has to prove
> : that _nobody_ but a hacker can make use of the information. He hasn't,
> : he won't and he can't, for the simple reason that it's dead wrong.
>
> This hardly has much of an impact on the spirit of what he was saying,
> now does it? This is a case of objecting to his turn of phrase, not
> anything he was seriously trying to say.
Well, yes, I think when he says something can't possibly be of use
when in fact it can be of use, that has some impact on what he's
saying...
> : Second consider that even though the discussion was of CBC, he used
> : PGP as his example, and it (at least normally) seems to use CFB
> : instead. Since he apparently doesn't even know the difference between
> : CFB and CBC, how are we supposed to believe that he has a clue about
> : what and/or how either one contributes anything to security?
>
> I am under the impression that he regards most of the existing chaining
> modes as flawed in the manner he describes. Why should he not pick
> his examples from the full set?
>
> : In one paragraph he managed to display a _complete_ failure to grasp
> : the simplest requirement of logic AND a profound ignorance of chaining
> : modes. How could that be called anything short of a display of
> : complete and unmitigated cluelessness?
>
> You turn:
>
> "So what fuckin good does this error recovery do anyone who depends on PGP.
> It does them no fucking good it can only be of use to a dedicated attacker."
>
> ...into "a complete failure to grasp the simplest requirement of logic"?
How can I term it any other way? He starts by saying that _some_
people can't use something. He then draws a conclusion from this that
_nobody_ can use it. That is simply a _completely_ illogical
conclusion to draw from that premise. There's no other way to put it.
> The mind boggles. /Perhaps/ I should avoid getting into discussions with
> you to avoid getting burned over a turn of phrase like this myself ;-))
It's not a matter of a turn of phrase. It's a matter of the thought
(or lack of it) that went into deciding to make any statement vaguely
similar to the one he did. The problem was not and is not with how he
phrased his conclusion. He could have phrased the same or similar
conclusion in virtually ANY way, and the same problem would have
remained.
In reality, I suspect he realizes the error in the logic here as well
as I do. I believe, however, that he was trying to give the illusion
of winning an argument. The situation's pretty simple: he knows the
error recovery inherent in CBC is useful and important, but doesn't
want to admit it. To try to get me (or anybody else who would reply)
to admit to the contrary, he picked PGP out and tried to get somebody
to show how it would do this. PGP uses CFB, which lacks exactly that
capability. If somebody tried to show how the capability would be
used with PGP, they would face one of two possibilities: they could
either admit that it's not there, or else incorrectly try to show how
to do it. Since the capability really IS lacking in CFB, he could
pounce on either of these as "proof" of all his usual nonsense about
the "three-letter" chaining modes being worthless, all the AES
candidates being weak, etc. In reality, he would have proven nothing,
but from the looks of things that wouldn't have stopped him from
claiming whatever he wanted and probably even convincing some people
that he was right.
OTOH, let's look at (more or less) the original question: how would a
user make use of error-recovery in a system that used CBC? First of
all, a typical dynamic, stream-oriented compression wouldn't be used.
You'd either use no compression, a static compression, or else have
the compressor work in blocks, typically the same size blocks as the
cipher is going to use.
In this case, the user probably doesn't have to do anything special at
all when an error takes place. If the system includes signing the
message in some way, it's likely that it will tell the user that the
message wasn't received entirely correctly. The user will (in a
typical case) notice that there's a block that looks a lot like
garbage, and ignore that block. The only place things might get
sticky is if the system includes some message authentication code. If
the MAC is based on the complete message, then the grunged message
won't authenticate properly -- the receiver will have to make a
judgement call to determine whether he believes the message is
authentic anyway.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: SCOTT16U SOLUTION ON THE WEB
Date: 20 Nov 1999 23:57:23 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
> Next year assuming we are still alive and no chinese rockets or
>previously planted nukes and bioterrism weapons destroy this nation
>I will if not assinated have another contest along the lines of the
^^^^^^^^^
Trust me, you were assinated a long time ago.
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: RC4 in Kremlin US version 2.21 to tom st denis
Date: 20 Nov 1999 23:50:45 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
>
>RC4 does not have an CBC mode, it's an RNG damnit.
First of all, you're really misreading the guy's post.
He says he found a bug in Kremlin which makes the
ciphertext as bad as if it were Vignere encrypted.
He isn't claiming that RC4 is like Vignere.
Nor did he say that RC4 has a CBC mode. Rather, Kremlin
has a CBC mode option that he didn't turn on, _because_ _he_
_knew_ _that_ RC4 didn't have a CBC mode.
Finally, RC4 is a cryptosystem. It is not a RNG, because
no algorithm is an RNG unless it has access to a source of
real entropy; it is not merely a PRNG either, but can be used
as one.
>Tom
-X
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES cyphers leak information like sieves
Date: Sun, 21 Nov 1999 15:00:32 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> On Tue, 16 Nov 1999 20:53:14 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
>
> >It might, but whenever you tie too much of a message into an interlocking
> >structure, its survivability as information becomes more fragile. The
>
> But I feel that fragility isn't so much a problem for most civilian
> applications.
>
> For military applications I do see why error recovery in crypto is a good
> and often necessary thing, coz the attacker can try to jam signals.
There are many reasons for error recovery, lots of reasons you want to
recover all of the signal. Simple redundancy, repeating the
message/block/information is simple enough. Inferior crytosystems are
compromised with repeats, especially when in the same key. You don't want
your opponents to know that you are even doing that.
Speaking of civilian tolerance for bad or no recovered plaintext, it
entirely depends on what civilian you are talking to, or when are random
errors appealing to you?
--
What we do not need is a secret police born out of fear that the
government cannot be superior to the wishes of the people.
------------------------------
From: [EMAIL PROTECTED]
Subject: Deja.Com Daily Digest: sci.crypt 1/1
Date: Sun, 21 Nov 1999 21:50:03 +0100
Status Distribution November 20, 1999 21:40:04
Sent by: EHAUO01
The message regarding "Deja.Com Daily Digest: sci.crypt 1/1" sent on November 20, 1999
21:40:04 was sent by
Status Recipient
Type To
Native Name [EMAIL PROTECTED]
Foreign Native Name [EMAIL PROTECTED]/n/n/nSMTP
Recipients
Status Reporters
Type From
Initials CV
Name Domain LOTUS
Native Name CN=Chris Van Bael/OU=LEU/OU=TASS/O=PHILIPS@EMEA1
Foreign Native Name CN=Chris Van Bael/OU=LEU/OU=TASS/O=PHILIPS/nEMEA1/n/n
Organization PHILIPS
Org Unit 1 TASS
Org Unit 2 LEU
Last Name Bael
First Name Chris
Status 769
Explanation Invalid recipient
X.400 Status 769
Explanation Router: Unable to open mailbox file BRU001M/M/SERVER/PHILIPS mail.box:
Unable to find path to server
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES cyphers leak information like sieves
Date: Sun, 21 Nov 1999 15:31:11 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> wtshaw <[EMAIL PROTECTED]> wrote:
> : In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> :> I am not in a good position to comment on the weaknesses or otherwise
> :> of your GVA system. I know that Thomas Jefferson's cypher was pretty
> :> secure for its time - and that your system certainly appears to offer
> :> better security than it did.
> :>
> :> The system relies on large "random" tables of permutations of the
> :> alphabet. You do not appear to specify how these tables should be
> :> generated.
>
> : The method of choice defines the security of the system since the security
> : is totally in the keys. *where it ideally should be*.
>
> To my mind, the algorithm itself should be variable. There's little point
> in having a fixed cyphermachine that needs to be distributed in this
> modern era of programmable computers.
>
The algoritim design can be in generic terms as well, but getting down to
oa useful implementation, you need to know size of maximum cylinder and
maxium permitted pathkey, as well as the character set involved. I have
worked with sever variations of the genetic algorithm, each with useful
attributes for a purpose.
>
> : I have demonstrated many methods, but those discriptions have been
> : bypassed recently your convenience;
>
> I'm not sure I caught this comment correctly. Was it "toilet humor"? ;-)
No, we could spend lots of time of key generation if you wish. Some time
ago, I did that here.
>
> : I see the algorithm and the keys as more or less separate issues,
> : which bothers many who can't imagine athat cipher ideals are anything
> : but unobtainable goals.
>
> I think I take the reverse perspective, that the cypher-machine should
> really be just as easy to vary as the key. I don't like the idea of
> broken cyphers remaining in use in the field a moment longer than
> is necessary. Making them reprogrammable seems one way of avoiding this
> situation.
Well, if two teams want to actually play a game of baseball, it is good
that some rules have been adopted in advance. Making all things variable
is sometimes bad, even when it comes to computers; making them totally
transparent to code is so often their downfall.
About the GVA, the key structure alone can be as variable as needed, no
reason to write something in one program that would not really change the
basic essence of the algorithm.
>
> Perhaps our differing prespectives may be reconciled...? ;-)
Suposedly, you have a good idea in advance of what needs to be encrypted?
Building a good application for a specific purpose means making it
friendly in certain ways; it's called product. I have little use for
anything but text, so I write for that.
>
> Unfortunately, I have the *feeling* that appling diffusion and then
> encrypting is not as valuable an idea (from a security POV) as
> inextricably these two stages together.
I put diffusion into the key rather than the ciphertext, as most any part
of the key is sure to be used in neighborhood characters is slghtly
different way.
>
...
>
> Perhaps diffuse-encrypt-diffuse-encrypt would make me feel good ;-)
I see it as overkill, but anything like that can be done.
>
....
>
> : It can, and for some seems to be their only hope, their product becoming a
> : super-flea as compared with the GVA elephant. The comparison is not out
> : of line; run the numbers.
>
> I am not yet convinced that your GVA is genuinely an elephant.
>
> However, that particular subject is one where my own opinion is
> probably not worth very much - as I have made no detailed study
> of the system you have described.
The details are simple enough, some more, but the transparency of the
algorithm scares some because otherwise, complication tends to impress,
figuring that if something cannot easily understood because of elaborate
stucture, it must be good. The difficulity in understanding the strength
of the GVA is because the vital concepts are so closely linked together, a
power pill. Some get it and some never do; fortunately for the long run,
many do.
>
> Thanks for bringing your interesting views to this discussion.
--
What we do not need is a secret police born out of fear that the
government cannot be superior to the wishes of the people.
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Crossposted-To: comp.ai.fuzzy,sci.physics,sci.math
Subject: Re: Filters, Superpositions and Entanglements
Date: Sun, 21 Nov 1999 14:52:05 -0800
<[EMAIL PROTECTED]> wrote in message news:81950k$ak5$[EMAIL PROTECTED]...
> Superpositions are not necessarily entanglements.
>
> A superposition is what happens at a beam splitter.
> An entanglement is what happens in a non-linear crystal.
GROUNDS are not active equalizers. THEORETICALLY, you don't need them in
communications nor do you need them in energy distribution. However,
PRACTICALLY, without a ZERO in a communications circuit, eventually you
can't distinguish noise from signal, and in the energy distribution grid you
need an ABSOLUTE as a safety or security hook-up POINT. When the two
inter-twine, you get a BRISBANE/SAN MATEO type of result. Karl M
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: math
Date: Sun, 21 Nov 1999 22:53:53 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hello
>
> I'm looking for a crypt system with something interesting for my maths
> studies.
> Could you help me (I'm already aware of RSA) ?
Discrete Logs? Any paper on cryptanalysis? Decorrelation?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RC4 in Kremlin US version 2.21 to tom st denis
Date: Sun, 21 Nov 1999 22:52:46 GMT
In article <817c4l$i1$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Xcott Craver) wrote:
> Finally, RC4 is a cryptosystem. It is not a RNG, because
> no algorithm is an RNG unless it has access to a source of
> real entropy; it is not merely a PRNG either, but can be used
> as one.
I will argue this to the end of the earth. All stream ciphers are
simply secure PRNG or RNGs. SEAL, RC4, WAKE are all PRNGs where the
output is xored with plaintext/ciphertext. I think an RC4 cryptosystem
[or cipher] just uses the RC4 PRNG as a source of [pseudo-]random bytes.
I could for example plug the PRNG part of RC4 into a game for random
numbers..
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Sun, 21 Nov 1999 22:57:29 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Um, maybe Tim wasn't talking about single blocks?!
>
> If you have a suitable quantity of known-partial plaintext - and a
> known-plaintext attack on the cypher - you can break the cypher using
> that, recover the key, and then decrypt the rest of the message that
> was previously unknown to you.
>
> This can happen for a string of blocks of any length.
>
> You *might* hold the position that there's no theoretical known-
plaintext
> attack on modern block cyphers that works any better than brute
force -
> but this notion is a theoretical ideal, not known to be attained
in /any/
> practical system.
>
> If you want to depend on this vagueness, then that's up to you.
> Personally I'd rather defend against such attacks.
3 x 2^51, 2^53, 2^47, what do those numbers represent? If you can't
even guess I am wasting my time.
> If you don't believe this, try David's often-explained experiment:
> Chop off both ends of the encrypted file, decrypt with the /right/
> key, but the /wrong/ IV and watch (most of) the plaintext flood out.
In CBC if you have the IV wrong you can't decrypt it right... think
about it...
P = Dk(C) xor IV
if the IV is wrong, so is the P value. Your argument is flawed.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
