Cryptography-Digest Digest #557, Volume #12 Mon, 28 Aug 00 15:13:00 EDT
Contents:
Re: Secure key exchange over an unsecure network (Mike Rosing)
Re: PRNG Test Theory ("Douglas A. Gwyn")
NEWBIE!!! Zodiac killer's encryption... (Rob B)
Re: Who can tell me where to go? (Frank Wagner)
Re: e-cash protocol concept, comments wanted (Julian Morrison)
Re: UNIX Passwords ([EMAIL PROTECTED])
Re: PGP 6.5.8 test: That's NOT enough !!! ([EMAIL PROTECTED])
Re: On pseudo-random permutation (Mok-Kong Shen)
Re: Test on pseudorandom number generator. (Mok-Kong Shen)
Re: PRNG Test Theory (Mok-Kong Shen)
Re: ZixIt Mail (JPeschel)
Re: avalanche characteristic (Terry Ritter)
----------------------------------------------------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Secure key exchange over an unsecure network
Date: Mon, 28 Aug 2000 12:11:47 -0500
Slava K. wrote:
>
> Since I began studying cryptography (Not that long ago actually), I
> attempted creating a protocol which will allow for secure public-key
> exchange over an unsecure network. I have come close with a modificatin of
> the Mental Poker protocol, but after further analysis I found that this
> protocol merely complicated the man-in-the-middle attack, but did not
> disallow it.
> I'm looking to gather variouse pieces of information about protocols which
> attempt to disallow this attack, such as timestamping protocols (Send these
> too). I prefer non-arbitrated protocols, as these are as susceptible to the
> man-in-the-middle attack as any, but have also that added requirment of a
> trusted third party.
>
> Any help is welcome!
There is no protocol which can overcome MITM. You must have an out of
band exchange of some kind to eliminate it. The PGP fingerprint is an
example, by using a phone call you can check the in band exchange, or
it can be published in a newspaper. The more channels used, the higher
the probability MITM can not be performed.
For an interesting solution, check out the MQV protocol in IEEE 1363.
Assuming you know a public key, you can exchange a secret securely.
Every successful protocol has the same restriction. Only an out of
band communication can solve the problem (with good level of probability,
you still don't know who the spooks are!)
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: PRNG Test Theory
Date: Mon, 28 Aug 2000 16:11:34 GMT
Mok-Kong Shen wrote:
> "Douglas A. Gwyn" wrote:
> > Mok-Kong Shen wrote:
> > > Bryan Olson wrote:
> > > > There is no universal test of randomness. There is no
> > > > algorithm that can distinguish bits produced by an algorithm
> > > > from truly random bits.
> > > Right, though lots of theories apparently assume there
> > > IS something that is perfectly random. Whether this
> > > could mean a problem of certain philosophical nature I
> > > am not very certain.
> > It's not a problem. The characteristics of random processes
> > are solidly defined, and deductions can be made on that basis.
> I suppose that could be an arguable point. If something is
> 'solidly' defined, it should be verifiable in my view.
> One could namely say that, if something is not (ultimately)
> discernable, then it doesn't exist in the world, I suppose.
?? In mathematics, we often set forth definitions and
assumptions, then derive conclusions from them. There
is no requirement that the defined terms correspond to
things we can point at in the physical world, although
quite often if we look for physical things that match
up well to the assumed properties we can find them. In
the case of uniform random distribution, it serves as a
component of a model for certain physical systems, for
which we can make predictions (necessarily statistical)
derived mathematically from the model (including the
mathematical properties of the assumed randomness).
In any specific realization of the physical system, the
predictions might be close to what happens or they
might be far from what happens. Statistical tests
allow us to say how likely it is that the observations
could have occurred if the system had accurately
implemented the model. If the observations show
consistently (relatively) unlikely outcomes, and we
have no other relevant evidence in the other direction,
we eventually have a fair degree of confidence (which
can be computed) that the system is not a faithful
implementation of the model.
------------------------------
From: Rob B <[EMAIL PROTECTED]>
Subject: NEWBIE!!! Zodiac killer's encryption...
Date: Mon, 28 Aug 2000 12:19:41 -0500
Hi all!
I saw a show this weekend on the Zodiac killer on TLC and was fascinated
by it...
Anyways, I was wondering if anyone knows of any good web sites, books,
info, that discuss the encryption that he used in his letters, if the
messages were decoded, and, if so, how.
Examples of the messages can be seen at
www.crimelibrary.com
under the Serial Killers/Zodiac section. I'd post the full URL but our
darned firewall denies me access to non-work related sites... *hmmphh*
:)
Thanks in advance for any information one can provide...
Rob
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: Frank Wagner <[EMAIL PROTECTED]>
Subject: Re: Who can tell me where to go?
Date: Mon, 28 Aug 2000 18:43:55 +0200
I would suggest a very good book:
Applied Cryptography: Protocols, Algorithms, and Source Code in
C, 2nd Edition by Bruce Schneier.
Regards
Frank
[EMAIL PROTECTED] wrote:
>
> Greetings! I have a question for you.
>
> Where would I learn the most about Cryptology?
------------------------------
From: Julian Morrison <[EMAIL PROTECTED]>
Crossposted-To: alt.cypherpunks,alt.cypherpunks.technical
Subject: Re: e-cash protocol concept, comments wanted
Date: Mon, 28 Aug 2000 19:01:18 +0100
Ragni Ryvold Arnesen wrote:
> Julian Morrison wrote:
>
> > If you are knowledgeable about ecash, please check out my idea for a
> > signature-based ecash protocol at
> > http://fling.sourceforge.net/concepts.html
> >
> > Are there any major design bugs?
> > Are there major improvements you could suggest?
> > How does this compare to other ecash proposals you know of?
> >
> > Thanks in advance for any comments.
>
> Two major considerations for a bank deciding whether or not to support
> an e-cash system are security and transaction costs (not necessarily in
> that order). At first glance I cannot see any security problems with
> your system, but the transaction costs will probably be huge if there
> are many small coins floating around.
Coins would likely often be big - since the overhead for a higher face
value is negligible compared to the overhead of crypto per coin, storing
big ones is more efficient. Also, transaction costs would be offset by the
opportunity to invest the money until the coins are redeemed into some
other bank account.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: UNIX Passwords
Date: Mon, 28 Aug 2000 18:09:25 GMT
JCA <[EMAIL PROTECTED]> wrote:
>> Is there a description available,
>> how UNIX encrypts (or hashes) its
>> Passwords?
> Why don't you have a look into the Linux
> code?
Because the "Linux" code actually changes algorithms depending on the
salt. The crypt(3) implementation is also derived from UFC, which has
enough optomizations to make it nearly unreadable for someone who
doesn't know what they're looking at ahead of time.
However, most Linux distributions use either the traditional
algorithm, or an MD5 hash with an 8 character salt.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP 6.5.8 test: That's NOT enough !!!
Date: Mon, 28 Aug 2000 18:03:13 GMT
Aye, for once we agree. PGP have handled this problem extremely poorly
from both a technical and PR perspective.
I can't see a "pretty" way forward...As I stated in a recent mail to
PGP-Users mailing list, possibly the best thing to do is draw a line
under this mess and release a new revised RFC that solves this
problem. NAI could then offer free upgrades etc.
This problem doesn't make S/MIME any more palatable - personally I'll
use GnuPG!
Regards,
Sam
In article <HY1q5.1460$[EMAIL PROTECTED]>,
"David Sternlight" <[EMAIL PROTECTED]> wrote:
> The dancing, fast footwork, and apologetics of PGP die-hards here is
truly
> sad. PGP has, after all the hubris of the past, acquired a fatal
error. If
> you can't detect a forged key, it's all over.
>
> The only reliable solution is a "new" PGP which is deliberately
incompatible
> with all previous versions but classical PGP. This is the ONLY way to
> restore trust on the part of the general (non-specialist) user.
>
> Does NA have the guts to do this? Will they absorb the cost of a
complete
> product (recall and) replacement. Will "pay" PGP users be willing to
replace
> much of their PGP infrastructure? If not, I say game over.
>
> And if something like this had happened to Netscape/Microsoft S/MIME
X.509,
> honest PGP die-hards here will concede they would be among the first
to say
> what I am saying (about PGP) about S/MIME. When the ordinary user
loses
> control over his cryptosystem and cannot detect forged keys, no
amount of
> apologetics will sweep that under the rug.
>
> David
>
> P.S. For the ad hominem types here who think this is some anti-PGP
crusade
> on my part, I too have now had to suspend use of a good part of my
crypto
> infrastructure (PGP 6.x) and any number of PGP certificates from
Thawte.
>
> David
>
> "Michel Bouissou" <[EMAIL PROTECTED]> wrote in message
> news:8o87bf$p7m$[EMAIL PROTECTED]...
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > I've just tested the "ADK-bug-fixed" PGP 6.5.8 against Ralf's B1
> > forged key that holds a faked ADK.
> >
> > Where previous versions would show this key as having an ADK, and
use
> > the forged ADK, the "fixed" PGP 6.5.8 shows the forged key as being
a
> > normal, valid key, without any ADK.
> >
> > PGP 6.5.8 will not use the forged ADK for encryption, and will just
> > behave as for a normal key.
> >
> > Well, okay, it "fixes" the bug.
> >
> > BUT IT DOESN'T WARN YOU IN ANY WAY THAT THE KEY YOU'RE USING HAS
BEEN
> > FORGED. You just see a valid key and the forged ADK is ignored.
> >
> > So:
> >
> > - - You don't know the recipient's key has been victim of an attack;
> > - - You don't know that this key remains a potential danger for
users
> > that still have previous versions of PGP.
> >
> > Actually with PGP 6.5.8, you have LESS CHANCES to ever detect that a
> > key was forged, than you had with previous vulnerable versions.
> >
> > That's no good folks.
> >
> > Waiting for 6.5.9 that will display a BIG WARNING that an ADK sits
> > where it shouldn't on a given key.
> >
> > - --
> > [EMAIL PROTECTED]
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: PGPfreeware 6.5.8 for non-commercial use
<http://www.pgp.com>
> > Comment: Corrigez le bug PG ADK. Installez PGP 6.5.8 ou plus recent.
> >
> > iQA/AwUBOaeSnY7YarFcK+6PEQJUCACdFPt9KmCr+ImmCdpYt8i6XUlcmYUAnRRj
> > +OXfvsBkFugPmzNIlCaVO2N5
> > =iGL6
> > -----END PGP SIGNATURE-----
> >
> >
> >
> >
>
>
--
--
Sam Simpson
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.programming
Subject: Re: On pseudo-random permutation
Date: Mon, 28 Aug 2000 20:46:51 +0200
Tim Tyler wrote:
>
> In sci.crypt Bryan Olson <[EMAIL PROTECTED]> wrote:
>
> : Given a generator of perfect random bits as the one and only
> : source of randomness, can you find any procedure for generating
> : perfectly uniform random permutations (of more than two
> : elements) that strictly terminates? Can you show that no
> : such procedure exists?
>
> This appears to be essentially much the same question as:
>
> It it possible to pick an integer from {1,2,3} with each element
> occurring with exactly equal frequency - and with termination
> guaranteed - if one is only given a random bitstream.
>
> AFAIK, the answer to this question is "no" - on the grounds that no
> power of two is divisible by three, and any truncation to produce a
> range that /is/ divisible by three introduces potential termination
> problems.
Maybe I gravely misunderstood. But one can take groups of
2 bits and discard the value 3, thus obtaining a random
number in the range [0,2]. Would that solve the above
problem?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Test on pseudorandom number generator.
Date: Mon, 28 Aug 2000 20:47:23 +0200
Cristiano wrote:
>
> > The normal way to use a LCG is to convert the entire internal state
> > into a float, or even to use the state itself as an integer. Since
> > using the entire state is "normal," that is the way statistical tests
> > must be applied to get the "normal" results.
>
> OK this is the best way, but if I need only 8 bits? I think the best is take
> the 8 msb.
If you need only 8 bits from a LCG having a modulus much
larger than 8 bits, there is practically no problem at
all. Divide each output by the modulus to get a real
number in [0,1) and multiply that with 256. As I alluded
elsewhere with the 64 bit vs 32 bit problem, consider now
the more realistic case of 32 bit integer word and a
modulus a tiny little bit large than 31 bit. Then it is
clear that the most significant bit (leftmost bit) will
not be uniformly distributed, the chance of its being 0
being greater than its being 1. Thus it can be seen that
it is no good to take the 8 msb in your case.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: PRNG Test Theory
Date: Mon, 28 Aug 2000 20:47:08 +0200
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > "Douglas A. Gwyn" wrote:
> > > Mok-Kong Shen wrote:
> > > > Bryan Olson wrote:
> > > > > There is no universal test of randomness. There is no
> > > > > algorithm that can distinguish bits produced by an algorithm
> > > > > from truly random bits.
> > > > Right, though lots of theories apparently assume there
> > > > IS something that is perfectly random. Whether this
> > > > could mean a problem of certain philosophical nature I
> > > > am not very certain.
> > > It's not a problem. The characteristics of random processes
> > > are solidly defined, and deductions can be made on that basis.
> > I suppose that could be an arguable point. If something is
> > 'solidly' defined, it should be verifiable in my view.
> > One could namely say that, if something is not (ultimately)
> > discernable, then it doesn't exist in the world, I suppose.
>
> ?? In mathematics, we often set forth definitions and
> assumptions, then derive conclusions from them. There
> is no requirement that the defined terms correspond to
> things we can point at in the physical world, although
> quite often if we look for physical things that match
> up well to the assumed properties we can find them. In
> the case of uniform random distribution, it serves as a
> component of a model for certain physical systems, for
> which we can make predictions (necessarily statistical)
> derived mathematically from the model (including the
> mathematical properties of the assumed randomness).
> In any specific realization of the physical system, the
> predictions might be close to what happens or they
> might be far from what happens. Statistical tests
> allow us to say how likely it is that the observations
> could have occurred if the system had accurately
> implemented the model. If the observations show
> consistently (relatively) unlikely outcomes, and we
> have no other relevant evidence in the other direction,
> we eventually have a fair degree of confidence (which
> can be computed) that the system is not a faithful
> implementation of the model.
You are certainly right. A model that serves well some
practical purposes need not (and usually don't) have an
EXACT real-world existence. It is reasonable to consider
that a system which well approximates the model will have
properties that are very close to those of the model.
In the case of perfect randomness we have, however, in
my view a little problem: We have a large number of
statistical tests for detecting non-randomness, but
we don't know whether the set of tests we currently have
is nearly complete (let alone complete). On the other
side, we could ignore this problem in so far as we
assume (believe) that our opponent is not better equipped
with test suites than we are and consequently the use
of sequences that successfully passes all tests available
to and feasible for us can be practically justified.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: ZixIt Mail
Date: 28 Aug 2000 18:38:41 GMT
[EMAIL PROTECTED] writes:
>Is it just me or ZixIt mails seems like a "been-there, done-that"
>company?
I dunno. Does Wind River Systems seem like one?
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: avalanche characteristic
Date: Mon, 28 Aug 2000 19:05:05 GMT
On Mon, 28 Aug 2000 11:07:17 +0200, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>>
>
>> Avalanche Effect
>> The result of avalanche. As described by Webster and Tavares:
>>
>> "For a given transformation to exhibit the avalanche effect, an
>> average of one half of the output bits should change whenever a single
>> input bit is complemented." [p.523]
>>
>> Webster, A. and S. Tavares. 1985. On the Design of S-Boxes.
>> Advances in Cryptology -- CRYPTO '85. 523-534.
>
>They also proposed the strict avalanche criterion. See Menezes
>et al. p.277.
>From my original posting:
>> Also see mixing, diffusion, overall diffusion, strict avalanche
>> criterion, complete, S-box, and the bit changes section of the
>> Ciphers By Ritter / JavaScript computation pages.
So, wee, for example:
http://www.io.com/~ritter/GLOSSARY.HTM#StrictAvalancheCriterion
Strict Avalanche Criterion (SAC)
A term used in S-box analysis to describe the contents of an
invertible substitution or, equivalently, a block cipher. If we have
some input value, and then change one bit in that value, we expect
about half the output bits to change; this is the avalanche effect,
and is caused by an avalanche process. The Strict Avalanche Criterion
requires that each output bit change with probability one-half (over
all possible input starting values). This is stricter than avalanche,
since if a particular half of the output bits changed all the time, a
strict interpretationist might call that "avalanche." Also see
complete.
As introduced in Webster and Tavares:
"If a cryptographic function is to satisfy the strict avalanche
criterion, then each output bit should change with a probability of
one half whenever a single input bit is complemented." [p.524]
Webster, A. and S. Tavares. 1985. On the Design of S-Boxes.
Advances in Cryptology -- CRYPTO '85. 523-534.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
** 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
******************************
