Cryptography-Digest Digest #726, Volume #10 Sun, 12 Dec 99 12:13:01 EST
Contents:
Re: Encryption of I-Mail? Someone Invent this Please! (Troed)
Re: Attacks on a PKI (David A Molnar)
Re: Linear Congruential Generators ("Gary")
Re: Linear Congruential Generators ("Gary")
Re: Insecure PRNG? (Mok-Kong Shen)
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
Re: Scott's Screaming Security Method (Nogami)
Re: Encryption of I-Mail? Someone Invent this Please! ([EMAIL PROTECTED])
Re: Encryption of I-Mail? Someone Invent this Please! (Troed)
Re: Attacks on a PKI ("Douglas A. Gwyn")
Re: Insecure PRNG? ("Douglas A. Gwyn")
Re: Linear Congruential Generators (Herman Rubin)
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: Attacks on a PKI (Anne & Lynn Wheeler)
Re: Attacks on a PKI ("Trevor Jackson, III")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Troed)
Subject: Re: Encryption of I-Mail? Someone Invent this Please!
Reply-To: [EMAIL PROTECTED]
Date: Sun, 12 Dec 1999 09:32:39 GMT
[EMAIL PROTECTED] (UBCHI2) wrote:
>To clarify, I am referring to Instant Messenger on AOL when I write I-Mail, not
>to e-mail.
Have you americans still not learned that the rest of the world is
using ICQ?
How ignorant.
Encrypted ICQ messages, with a public key stored on the ICQ server,
would be nice though. Or maybe it exists? (I'm not using the latest
version ... )
___/
_/
Nazister, rasister och andra d�rar - ger bara sig sj�lva kalla k�rar
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Attacks on a PKI
Date: 12 Dec 1999 09:43:17 GMT
lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
[snip explanation of PKI, pointing out that even personal key file
is in sense a PKI]
> authority can specialize in this task. The disadvantage is that you
> now must trust this other entity to securely and accurately manage his
> certifications. Of course, you entrust your very life every day to the
> expectation that third parties have professionally applied their skills
> and energies, so there is nothing particularly revolutionary in extending
> such trust to a key infrastructure.
Eventually I will agree with you. :-\
What seems "revolutionary" to me _now_ is that the key infrastructure
does not seem to be as well understood, as accountable, or as well
regulated as many of the other third parties I depend on. It's not
completely clear what I should expect from a PKI, while in many real
life cases the expectations are so amazingly clear that stating them
seems pedantic.
For example, I trust that the food I eat is free of disease; in doing so
I'm implicitly trusting half a dozen third parties. The farmer must
have grown the crop correctly, without allowing it to become rotten. The
food processor must avoid introducing toxic chemicals. The distributor
must prevent spoilage. Since I'm in the United States, somewhere along
the line the State gets involved, too. Eventually the food comes to
market, where I trust it wasn't injected with poison. From there it
comes to me, and I have to trust the ppl who cooked it...
None of these is the real expectation. The real expectation is that
"this food won't make me sick." The rest is professionalism.
The difference seems to me that with a PKI, I take a look at a key
and it's not clear immediately what kind of keys "won't make me sick."
Do I expect this key to map to a name? what kind of name?
Do I expect this key to meet a certain standard of "quality" ?
Do I expect this key to be still in use?
Do I expect that all my correspondents expect what I expect?
Do I expect all my correspondents to be part of the PKI ?
Do I expect signatures with this key to be legally binding?
checked by anyone?
I trust the Verisigns, Thawtes, CertCos and like to do the
best honest job they can. There's ample precedent for that.
I just do not think that we can compare extending trust to a PKI
to extending trust to another third party, unless we have a
comparable expectation of what we'll "get" for that trust. This
doesn't affect your point once we know that a PKI "is", but
it's not clear to me that we're at that point yet.
Until we are, it seems fine to be skeptical of extending too much
trust to a PKI. We might not even know enough to know when
something has gone wrong...until someone _else_ notices and it's too
late.
Thanks,
-David Molnar
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Linear Congruential Generators
Date: Sun, 12 Dec 1999 10:26:50 -0000
David A Molnar wrote
>
>I don't know off the top of my head, but it seems to me that you
>might be able to get an equation relating the output to the top 5 bits
>of your first generator. Maybe this can be leveraged?
Since the top 5 bits are never explicitly output, recovery of these is
incredibly hard.
Please note in the second function I made a mistake Y=(X*C)+D it should read
Y=(Y*C)+D
IE
long NextBit(void)
{
static long X=X0,Y=Y0;
X=(X*A)+B;
Y=(Y*C)+D;
return ((X>>((Y>>27)&31))&1);
}
>There is a paper which explains how to go about recovering the
>parameters of an LCG, even when only one bit of the output is known :
>[FH+] A.M. Frieze, J. Hastad, R. Kannan, J.C. Lagarias,
>A. Shamir. Reconstructing truncated integer variables satisfying linear
>congruences. SIAM J. Comput. 17(2):262-280, Apr. 1988
Thanks for the reference.
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Linear Congruential Generators
Date: Sun, 12 Dec 1999 10:31:40 -0000
Mok-Kong Shen
>I surmise that it might be better to use the parity bits of the output
>of PRNGs. From experiments I found that parity bits from LCPRNGs
>have fairly good statistical properties. I am not aware of methods
>of inference on parity bits. But perhaps experts would like to furnish
>such informations.
I think parity is a good idea but the efficiency of the related function
which requires a loop to result in 1 bit isn't nice.
The adding (maybe XOR for non linear mix would be better) of 2 LCPRNGs is a
nice idea and very efficient.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Insecure PRNG?
Date: Sun, 12 Dec 1999 11:49:21 +0100
Gary wrote:
>
> So is this a quick and relatively secure cipher algorithm?
> Most of todays DSP's and CPU's can efficiently perform this algorithm.
In my humble opinion what is secure depends very much on one's
'definition' and inevitably involves a certain amount of subjectivity.
As discussed in the past in this group, there can be no scientifically
rigorous yet practically useful quantitative measure of strength
of crypto algorithms. So I don't think that one can give clear-cut
answer to questions of your sort, which I believe have always to
be answered in the end based on one's own judgement. If you are
interested in some algorithms based on what I wrote in the previous
follow-up, you may like to have a look at my web page.
Another remark is that efficiency is a two-sided sword, because it
reduces the time for brute force. In fact, for algorithms that
have to be attacked through brute force, higher security can be
obtained through purposedly imposing inefficiency. I made use of this
in my algorithms where the user can vary the efficiency of execution
through choice of certain parameters.
M. K. Shen
=========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Crossposted-To: talk.politics.crypto
Subject: --- sci.crypt charter: read before you post (weekly notice)
Date: 12 Dec 1999 06:00:05 GMT
sci.crypt Different methods of data en/decryption.
sci.crypt.research Cryptography, cryptanalysis, and related issues.
talk.politics.crypto The relation between cryptography and government.
The Cryptography FAQ is posted to sci.crypt and talk.politics.crypto
every three weeks. You should read it before posting to either group.
A common myth is that sci.crypt is USENET's catch-all crypto newsgroup.
It is not. It is reserved for discussion of the _science_ of cryptology,
including cryptography, cryptanalysis, and related topics such as
one-way hash functions.
Use talk.politics.crypto for the _politics_ of cryptography, including
Clipper, Digital Telephony, NSA, RSADSI, the distribution of RC4, and
export controls.
What if you want to post an article which is neither pure science nor
pure politics? Go for talk.politics.crypto. Political discussions are
naturally free-ranging, and can easily include scientific articles. But
sci.crypt is much more limited: it has no room for politics.
It's appropriate to post (or at least cross-post) Clipper discussions to
alt.privacy.clipper, which should become talk.politics.crypto.clipper at
some point.
There are now several PGP newsgroups. Try comp.security.pgp.resources if
you want to find PGP, c.s.pgp.tech if you want to set it up and use it,
and c.s.pgp.discuss for other PGP-related questions.
Questions about microfilm and smuggling and other non-cryptographic
``spy stuff'' don't belong in sci.crypt. Try alt.security.
Other relevant newsgroups: misc.legal.computing, comp.org.eff.talk,
comp.org.cpsr.talk, alt.politics.org.nsa, comp.patents, sci.math,
comp.compression, comp.security.misc.
Here's the sci.crypt.research charter: ``The discussion of cryptography,
cryptanalysis, and related issues, in a more civilised environment than
is currently provided by sci.crypt.'' If you want to submit something to
the moderators, try [EMAIL PROTECTED]
---Dan
------------------------------
From: Nogami <[EMAIL PROTECTED]>
Crossposted-To: comp.compression,alt.security
Subject: Re: Scott's Screaming Security Method
Date: Sun, 12 Dec 1999 04:11:36 -0800
On Sat, 11 Dec 1999 19:20:21 GMT, [EMAIL PROTECTED] (Loney
Ramik) wrote:
>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>
>>Any thoughts on this by my nonadmirers.
>
>I'm a little puzzled by the name you chose. How will screaming help, Scott?
Perhaps the screaming will alleviate the stress and idleness caused
while waiting for this routine to chug enough CPU time to finish the
job?
N.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encryption of I-Mail? Someone Invent this Please!
Date: Sun, 12 Dec 1999 15:08:28 GMT
Troed <[EMAIL PROTECTED]> wrote:
>>To clarify, I am referring to Instant Messenger on AOL when I write
>>I-Mail, not to e-mail.
> Have you americans still not learned that the rest of the world is
> using ICQ?
> How ignorant.
Actually, I don't use either, for many reasons.
> Encrypted ICQ messages, with a public key stored on the ICQ server,
> would be nice though. Or maybe it exists? (I'm not using the latest
> version ... )
If memory serves, there's only one common AIM client in use which is
open source, and no ICQ clients. To me, the people running either
server are a larger threat than evesdroppers. With that assumption,
closed source encryption is silly.
On top of that, there is a significant amount of client-server
activity which would seem to provide ample opportunity for traffic
analysis.
Storing public keys on the server would make it an even more tempting
target than it is now. No offense to the ICQ team, but I wouldn't
trust anyone to protect an internet server well enough to have faith
in that scheme. If there's no way to exhange keys through another
channel, I think you're sunk before you start.
--
Matthew Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Troed)
Subject: Re: Encryption of I-Mail? Someone Invent this Please!
Reply-To: [EMAIL PROTECTED]
Date: Sun, 12 Dec 1999 15:34:52 GMT
[EMAIL PROTECTED] wrote:
>If memory serves, there's only one common AIM client in use which is
>open source, and no ICQ clients. To me, the people running either
>server are a larger threat than evesdroppers. With that assumption,
>closed source encryption is silly.
True, but messages are sent directly between the users - not via the
server (if both users are online and not behind firewalls)
>Storing public keys on the server would make it an even more tempting
>target than it is now. No offense to the ICQ team, but I wouldn't
>trust anyone to protect an internet server well enough to have faith
>in that scheme. If there's no way to exhange keys through another
>channel, I think you're sunk before you start.
True, they would have to be trusted.
___/
_/
Nazister, rasister och andra d�rar - ger bara sig sj�lva kalla k�rar
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Attacks on a PKI
Date: Sun, 12 Dec 1999 16:14:47 GMT
David A Molnar wrote:
> None of these is the real expectation. The real expectation is that
> "this food won't make me sick." The rest is professionalism.
> The difference seems to me that with a PKI, I take a look at a key
> and it's not clear immediately what kind of keys "won't make me sick."
Come on, at that level it is obvious: You should be able to get
the authentic public key for any communicant.
The details are at the same level as for food transport and
storage..
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Insecure PRNG?
Date: Sun, 12 Dec 1999 16:18:37 GMT
Mok-Kong Shen wrote:
> As discussed in the past in this group, there can be no
> scientifically rigorous yet practically useful quantitative
> measure of strength of crypto algorithms.
That should not be taken as gospel. In fact there are papers
on provable minimum work factors for certain schemes. I've
also explained (ages ago) what form proper statistical
(information-theoretic) criteria could take.
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: Linear Congruential Generators
Date: 12 Dec 1999 11:31:00 -0500
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Gary schrieb:
>> Insecure PRNG?
>> Linear congruential Pseudo-Random Number Generators (PRNG) of the form
>> Xn+1=AXn+B are always stated to be insecure as the basis of a cipher
>> bit-stream.
>> If only the top bit is used on a PRNG of this form how do I find the
>> constants X0,A and B.
>I surmise that it might be better to use the parity bits of the output
>of PRNGs. From experiments I found that parity bits from LCPRNGs
>have fairly good statistical properties. I am not aware of methods
>of inference on parity bits. But perhaps experts would like to furnish
>such informations.
But this would mean that one would only get one bit from an
iteration, greatly adding to the cost.
I presume you mean the parity of the number of 1's. The least
significant bit here is not likely to be good.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
Date: Sun, 12 Dec 1999 11:47:16 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Guy Macon wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Trevor Jackson, III)
>wrote:
>
> >The geometry of your model has misled you. A simple analysis will
> >illustrate the fact. Consider that in half-life T, N/2 particles
> >will decay. In the subsequent interval T+1, N/4 particles will decay.
> >Thus the intensity numerator (decays) has decreased, but the intensity
> >denominator (seconds) is constant. The intensity goes down.
> >Exponentially with time.
>
> I think that you are wrong. You are assuming that number of hits
> per second is proportional to number of decays per second. It
> clearly is not, because only the rate of decays that actually
> make it to the detector is proportional to the area facing the
> detector, while the number of decays in proportional to the
> volume of the radium.
>
> This is why I chose radium. The element that it decays to (Radon)
> diffuses out of the sample and can be removed with a ventilation
> system. Thus the sample shrinks instead of becoming a mixture
> of two elements like some other elements do. (I was also looking
> for alpha particle only emmission and a half-life of at least
> 1000 years).
Actually I was concentrating on the fundamental decay process rather than the detection
procedure. If your detector counts radon atoms (and/or helium) as they exit the
chamber it
will measure the decay rate more accurately, although with variable delay on each
event,
than a radiation detection system. From this one could create a locally unbiased
source by
attributing ones to radon atoms and zeros to helium atoms.
Of course globally the source would have perfect 0/1 balance which is a form of bias.
Perhaps the inaccuracy of the atom counters would offset this.
------------------------------
Subject: Re: Attacks on a PKI
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Sun, 12 Dec 1999 16:46:08 GMT
lcs Mixmaster Remailer <[EMAIL PROTECTED]> writes:
> PKI is Public Key Infrastructure. Fundamentally this is any system for
> determining the validity of a public key for some intended purpose.
more specifically, PKIs have tended to have an offline email design
point from the early to mid 80s, i.e. you connected to a store&forward
node, exchanged email, disconnected and processed your email. The
email was somewhat assumed to be from various & random entities,
including entities that you had no prior knowledge of. The
authentication solution was to have an appended credential (analogous
to letters of credit from financial institutions in the sailing ship
days, before fax machines and telephones) from recongized institution
which asserted authentication & possibly identification
characteristics bound to a public key. The message could be
authenticated with the public key carried in the appended credential,
and the characterisitcs asserted in the credential could be assocated
with the message (based on the implied trust in the credential issuing
institution and the applicability of the attributes in the credential
to the requirements of the relying party).
much of many PKIs are pretty much orthogonal to existing online
authentication infrastructures, many of which are currently shared
secret based and could be incrementally upgraded from shared-secret
authentication to public key authentication w/o introducing PKI and/or
changing existing business policies and practices.
--
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
Date: Sun, 12 Dec 1999 11:56:28 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Attacks on a PKI
David A Molnar wrote:
> lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
>
> [snip explanation of PKI, pointing out that even personal key file
> is in sense a PKI]
> > authority can specialize in this task. The disadvantage is that you
> > now must trust this other entity to securely and accurately manage his
> > certifications. Of course, you entrust your very life every day to the
> > expectation that third parties have professionally applied their skills
> > and energies, so there is nothing particularly revolutionary in extending
> > such trust to a key infrastructure.
>
> Eventually I will agree with you. :-\
>
> What seems "revolutionary" to me _now_ is that the key infrastructure
> does not seem to be as well understood, as accountable, or as well
> regulated as many of the other third parties I depend on. It's not
> completely clear what I should expect from a PKI, while in many real
> life cases the expectations are so amazingly clear that stating them
> seems pedantic.
>
> For example, I trust that the food I eat is free of disease; in doing so
> I'm implicitly trusting half a dozen third parties. The farmer must
> have grown the crop correctly, without allowing it to become rotten. The
> food processor must avoid introducing toxic chemicals. The distributor
> must prevent spoilage. Since I'm in the United States, somewhere along
> the line the State gets involved, too. Eventually the food comes to
> market, where I trust it wasn't injected with poison. From there it
> comes to me, and I have to trust the ppl who cooked it...
>
> None of these is the real expectation. The real expectation is that
> "this food won't make me sick." The rest is professionalism.
>
> The difference seems to me that with a PKI, I take a look at a key
> and it's not clear immediately what kind of keys "won't make me sick."
I believe this difference is more of a distraction than a fundamental. I
suggest the true difference between the professionals who operate the various
food industries and those who operate the InfoSec industries is that food
rarely fails silently. Failures are easily detected by the victims. This
criteria is not met by the security inducstries. Further, the victims may have
an incentive to collaborate with both the failed professionals and the
perpetrators to keep the failure quiet.
>
>
> Do I expect this key to map to a name? what kind of name?
> Do I expect this key to meet a certain standard of "quality" ?
> Do I expect this key to be still in use?
>
> Do I expect that all my correspondents expect what I expect?
>
> Do I expect all my correspondents to be part of the PKI ?
> Do I expect signatures with this key to be legally binding?
> checked by anyone?
>
> I trust the Verisigns, Thawtes, CertCos and like to do the
> best honest job they can. There's ample precedent for that.
>
> I just do not think that we can compare extending trust to a PKI
> to extending trust to another third party, unless we have a
> comparable expectation of what we'll "get" for that trust. This
> doesn't affect your point once we know that a PKI "is", but
> it's not clear to me that we're at that point yet.
>
> Until we are, it seems fine to be skeptical of extending too much
> trust to a PKI. We might not even know enough to know when
> something has gone wrong...until someone _else_ notices and it's too
> late.
This last is the strongest distinguishing characteristic.
------------------------------
** 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
******************************
