Cryptography-Digest Digest #120, Volume #12 Wed, 28 Jun 00 01:13:00 EDT
Contents:
The random oracle model ("OTTO")
Re: Quantum computing (Bill Unruh)
Re: The random oracle model (David A Molnar)
Re: TEA-wmlscript question ("Douglas A. Gwyn")
Re: simple crypting ("Douglas A. Gwyn")
Re: Certificate authorities (CAs) - how do they become trusted authorities ??
("Joseph Ashwood")
Re: Idea or 3DES ("Trevor L. Jackson, III")
Re: Idea or 3DES ("Trevor L. Jackson, III")
Re: Idea or 3DES (JPeschel)
Re: Idea or 3DES (JPeschel)
Re: Certificate authorities (CAs) - how do they become trusted authorities ?? (Paul
Rubin)
Re: Remark on practical predictability of sequences ([EMAIL PROTECTED])
Yardley: Codebreaking or Torture (UBCHI2)
Re: Maximum number of secrets (jungle)
Re: IDEA (David Hopwood)
Re: Compression & Encryption in FISHYLAND (Kurt Shoens)
Re: Dixon's random square algorithm (Hideo Shimizu)
Re: Yardley: Codebreaking or Torture (David A Molnar)
Re: Remark on practical predictability of sequences ("John A. Malley")
----------------------------------------------------------------------------
From: "OTTO" <[EMAIL PROTECTED]>
Subject: The random oracle model
Date: Wed, 28 Jun 2000 09:07:00 +0800
Dear All,
Somebody can mails below article to me.....
R. Canetti, O. Goldreich, and S. Halevi. The random oracle model,
revisted. In 30th Annual ACM Symposium on Theory of Computing, 1998. To
appear.
Mail: [EMAIL PROTECTED]
Thanks............
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Quantum computing
Date: 28 Jun 2000 01:42:49 GMT
In <[EMAIL PROTECTED]> Roger Schlafly <[EMAIL PROTECTED]>
writes:
]Tim Tyler wrote:
]> Penrose cited gravity as a force that transmits influence from the QC to
]> the observer - and causes decoherence as a direct result. *If* this
]> force is large enough to cause problems, I believe there's no known
]> way of "defending" against this - short of having the observer (or the
]> computer) travelling near the speed of light ;-)
]That's right. If someone like that turns out to be true, it may be
]physically impossible to build a quantum computer. The whole subject
]is just extremely speculative based on current knowledge.
I do not think I would worry about gravity. The difference in
gravitational strength of the two states of the bit is too small to
decohere. Ie, this mechanism is far more speculative. It is true however
that decoherence IS the major problem to be solved. Error correction
goes some way, but it itself is very difficult.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: The random oracle model
Date: 28 Jun 2000 01:34:21 GMT
OTTO <[EMAIL PROTECTED]> wrote:
> Dear All,
> Somebody can mails below article to me.....
> R. Canetti, O. Goldreich, and S. Halevi. The random oracle model,
> revisted. In 30th Annual ACM Symposium on Theory of Computing, 1998. To
> appear.
This is in the Theory of Cryptography library. If you have www access,
try looking at
http://philby.ucsd.edu/cryptolib/
and if you don't, e-mail me and I'll be happy to send it along.
any particular reason why you're interested in that paper?
-dmolnar
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: TEA-wmlscript question
Date: Wed, 28 Jun 2000 02:02:44 GMT
dexMilano wrote:
> Do You mean that for crypto algoritms I don't need a particular
> number but i can choose the one I prefer (for example 1234567)?
That would depend on the algorithm and what the number is used for.
If an "arbitrary constant" (in a certain range) is required, using
a well-known constant reassures other people that you are not able
to exploit special properties of the particular constant in a back
door. (That's the standard explanation. I don't do things like
this myself.)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: simple crypting
Date: Wed, 28 Jun 2000 02:11:34 GMT
[EMAIL PROTECTED] wrote:
> if i post e crypted message here...
> is there anyone here who could decrypt it?
Please read the sci.crypt FAQ.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Certificate authorities (CAs) - how do they become trusted authorities ??
Date: Tue, 27 Jun 2000 19:18:41 -0700
The presence or lack of presence of a root CA in the trusted list maintained
by netscape/ie/etc generally depends on the presence of money given to the
browser maker, or the user installing the cert. So basically money decides
who's trusted, or they are trusted through popularity.
Joe
<[EMAIL PROTECTED]> wrote in message
news:8jb07c$r1k$[EMAIL PROTECTED]...
> Hi,
>
> In doing a bit of research on internet security I naturally came
> across "Certificate authorities (CAs)" (ie: Verisign, twaite, etc) ...
> can anyone tell me (or give me a URL) from where these companies get
> *their* certification - who says they are 'trusted' ?? ...I suppose I
> am asking as well what/who is the root of all authorities!
>
> thanks,
>
> Jay.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
Date: Tue, 27 Jun 2000 22:44:33 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Idea or 3DES
JPeschel wrote:
> "Trevor L. Jackson, III" [EMAIL PROTECTED] writes, in part:
>
> >Jim Gillogly wrote:
> >
> >> Joseph Ashwood wrote:
> >> > ... It is my
> >> > opinion that the likelihood of there being a significant known break in
> >> > either is exemplified by the US Governments willingness to prosecute the
> >> > author of PGP, indicating that neither is broken.
> >>
> >> Shouldn't you be arguing on the other side? The USG was in fact unwilling
> >> to prosecute the author of PGP, so according to your analysis shouldn't
> >that
> >> indicate that IDEA was broken?
> >
> >From what did you infer unwillingness?
>
> Jim probably infers, correctly, that the US government was unwilling to
> prosecute
> the author of PGP because it dropped its case.
Incorrectly. The case would not have been made, and PRZ indicted, if the USG was
unwilling. The appropriate explanation for a dropped case is inability.
------------------------------
Date: Tue, 27 Jun 2000 22:50:56 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Idea or 3DES
JPeschel wrote:
> "Trevor L. Jackson, III" [EMAIL PROTECTED] writes, in part:
>
> >Jim Gillogly wrote:
> >
> >> Joseph Ashwood wrote:
> >> > ... It is my
> >> > opinion that the likelihood of there being a significant known break in
> >> > either is exemplified by the US Governments willingness to prosecute the
> >> > author of PGP, indicating that neither is broken.
> >>
> >> Shouldn't you be arguing on the other side? The USG was in fact unwilling
> >> to prosecute the author of PGP, so according to your analysis shouldn't
> >that
> >> indicate that IDEA was broken?
> >
> >From what did you infer unwillingness?
>
> Jim probably infers, correctly, that the US government was unwilling to
> prosecute
> the author of PGP because it dropped its case.
Incorrectly. There is insufficient evidence to distinguish inability from
unwillingness. Given the harassment and threats against PRZ I find it ludicrous
to characterize lack of evidence as unwillingness. There may have been a US
Attorney who was unwilling to bring a worthless indictment, but the USG certainly
wanted to find a cause for legal action..
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Idea or 3DES
Date: 28 Jun 2000 02:45:07 GMT
"Trevor L. Jackson, III" [EMAIL PROTECTED] writes:
>JPeschel wrote:
>> Jim probably infers, correctly, that the US government was unwilling to
>> prosecute
>> the author of PGP because it dropped its case.
>
>Incorrectly. The case would not have been made, and PRZ indicted, if the USG
>was
>unwilling. The appropriate explanation for a dropped case is inability.
Nope, the government dropped its charges because it wasn't certain
it could win, and it didn't want to take a chance of ITAR being
ruled unconstitutional.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Idea or 3DES
Date: 28 Jun 2000 02:57:22 GMT
"Trevor L. Jackson, III" [EMAIL PROTECTED] writes:
>There is insufficient evidence to distinguish inability from
>unwillingness.
After writing:
"The case would not have been made, and PRZ indicted, if the USG was
unwilling. The appropriate explanation for a dropped case is inability."
Make up your mind!
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Certificate authorities (CAs) - how do they become trusted authorities ??
Date: 28 Jun 2000 03:04:42 GMT
In article <8jb07c$r1k$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>In doing a bit of research on internet security I naturally came
>across "Certificate authorities (CAs)" (ie: Verisign, twaite, etc) ...
>can anyone tell me (or give me a URL) from where these companies get
>*their* certification - who says they are 'trusted' ?? ...I suppose I
>am asking as well what/who is the root of all authorities!
There's no root of all authorities. The user decides what CA's to
trust. In mass market products like browsers, there's a collection of
pre-installed CA's that are trusted by default, but you can turn them
on and off, or add your own to the list. Which CA's are pre-installed
is determined by business deals made between the CA's and the browser
vendors. They vary by browser version.
For browsers, most everybody just uses the default set, so the browser
vendors could be thought of as a de facto "root of all authorities".
For higher security applications like extranets, setting up the
trusted root CA's is part of the configuration process and normally
takes some attention.
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Remark on practical predictability of sequences
Date: Tue, 27 Jun 2000 20:22:13 -0700
Well, hardware generators are like one time pads, unbreakable. If you take a
strong block cipher and feed it back than you have a random sequence such
that no known way to predict it exists - but no proof that that it cannot be
done either.
I guess the point is that you cannot prove that a pseudo-random generator is
unpredictable.
Mok-Kong Shen wrote:
> [EMAIL PROTECTED] wrote:
>
> > To me this seems clearly true. But what are you getting at?
>
> I mean one could eventually replace all hardware random sequence
> generators with software, which is in my opinion more convenient to
> use. (I heard much opinions that hardware generators are needed
> because only these are secure against prediction/inference in practice.)
>
> M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Yardley: Codebreaking or Torture
Date: 28 Jun 2000 03:39:41 GMT
I am reading Yardley's book called the Chinese Black Chamber. In it he admits
to using sodium pentothal and a second drug on captured prisoners in order to
get them to reveal Japanese encryption techniques.
Was he a master codebreaker or a torturer? Has history treated him too well?
Certainly, his codebreaking techniques would be considered human rights abuses
today.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: Maximum number of secrets
Date: Wed, 28 Jun 2000 00:42:18 -0400
can you recreate this error message at will, time after time ?
asddasf wrote:
>
> Microsoft is caught snooping in your files. Below is a copy of the
> record I had with Microsoft on this issue.
>
> When I try to copy a file using Windows Explore on Windows 2000 it
> will not copy the files and I get the following error:
>
> 1381L ERROR_TOO_MANY_SECRETS The maximum number of secrets that can be
> stored in a single system was exceeded. The length and number of
> secrets is limited to satisfy the United States State Department
> export restrictions.
------------------------------
Date: Wed, 28 Jun 2000 03:41:34 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: IDEA
=====BEGIN PGP SIGNED MESSAGE=====
Boris Kazak wrote:
> Mark Wooding wrote:
> >
> > Simon Johnson <[EMAIL PROTECTED]> wrote:
> > > Moreover, IDEA doesn't have any steps that might be troublesome in
> > > software.
> >
> > Actually, IDEA's multiplication mod 2^{16} + 1 is a real nuisance in
> > software, even though it's theoretically lovely.
>
> Practically even lovelier: loading numbers into registers tests them
> against =0 condition, 16-bit multiplication yields the 32-bit product,
> thereafter adding together LSW, MSW and eventual carry finishes the job.
Don't use a branch; use the technique described in the Ascom paper below,
which is more resistant to timing attacks:
J. Kelsey, B. Schneier, D. Wagner, C. Hall,
"Side Channel Cryptanalysis of Product Ciphers",
ESORICS '98 Proceedings pp. 97-110,
Springer-Verlag, September 1998.
http://www.counterpane.com/side_channel.html
E.G. Giessmann, G. Lassmann,
"A Side Channel Cryptanalysis of the IDEA Cipher",
Advances in Cryptology - CRYPTO '99.
Ascom Systec, Ltd.
"Side Channel Attack Hardening of the IDEA(TM) Cipher,"
Ascom Systec White Paper, corrected version, May 1999.
http://www.ascom.ch/infosec/downloads/sidechannel.pdf
Ascom Systec, Ltd.
IDEA C Source Code and Test Data (corrected version, May 1999),
http://www.ascom.ch/infosec/downloads.html
A Java implementation I did based on the technique from the white paper
turned out to be faster than a similar one using the ?: conditional
operator (although this may have been because the JIT compiler did a
bad job of optimising branches). In any case, this technique should not
be significantly slower on any architecture.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOVlkhDkCAxeYt5gVAQFQ5wgAtqeN6YV50Lje6b8VL3DIpZ7kx3IWVwKW
akyJFuGCOYDLHeZ3Cyn5Ejk5G94E2Ev6YhBMS+RAAVxrxWYj6/3sFSn/lZrDXlUJ
VRnHMrTbP0w8wTst9l8OJMLQzz8xjYc00iH8MvEEOCllKHxE4116LzpxO+Y7oscj
W/3uyM++dypC3po5pLJOETMKc6E4hCkRe1UCbcLdukm54R2pKP0vWVzf9YksV76o
AHXkwEOF9ZaIga/hwrExx3m3F9RxNwaf0uGfkba6kVrLcQf1rZY0dQN2Kb0irxib
fy0xzjGavYNjiY92HYGcxLtWhPICuAEy7Yz/0JQUKgzzBARJLjKfRA==
=vKAO
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Kurt Shoens)
Subject: Re: Compression & Encryption in FISHYLAND
Date: 27 Jun 2000 21:47:56 -0700
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
>This is indeed very true. Although I too have problems with Mr. Scott
>referring to a problem generally believed to be minor as totally
>fatal, without any real evidence, I do think he is correct that one
>might as well make the extra effort, when compressing for encryption,
>to eliminate any avoidable problem, minor or not.
Is the "minor problem" really worth any attention at all? Consider a
more radical straw man as a comparison: suppose that one of the current
AES finalists is chosen as the winner and that a common practice emerges
(for some reason) of always prefixing the plain text with one 128-bit
block of zeros. In other words, there's a known value encrypted at the
beginning of each message.
Does this help an attacker? Is there an attack on any of the finalist
algorithms for which knowing the encryption of all zeros yields anything?
Certainly brute force through 128-bits is unthinkable. (Or if it's not,
use 256-bits).
Since brute force is not affordable, compiling a dictionary of all
possible encryptions would take too long, too. Even if it didn't,
where would you put them all? Even if you had space, where would you
put them all for 256-bit keys?
Of course, no one's going to agree to encrypt a block of zeros at the
beginning of each message since it makes key reuse obvious. Outside of
that, what use is it to an attacker?
------------------------------
From: Hideo Shimizu <[EMAIL PROTECTED]>
Subject: Re: Dixon's random square algorithm
Date: Wed, 28 Jun 2000 13:47:38 +0900
You can find in Knuth's book The art of computer programing vol.2
(It is easy differential problem.)
Hideo Shimizu
TAO, Japan
"軼鍔田砺 輊帆斌" wrote:
>
> Hi!
> The Dixon's factoring randomized algorithm has running time L(n)^sqrt(2),
> where L(n) = e^(sqrt(logn*loglogn))
> Can anybody tell me, how this time is calculated (or, where can I find an
> article in which this calculation is made)
>
> Michael.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Yardley: Codebreaking or Torture
Date: 28 Jun 2000 04:36:28 GMT
UBCHI2 <[EMAIL PROTECTED]> wrote:
> I am reading Yardley's book called the Chinese Black Chamber. In it he admits
> to using sodium pentothal and a second drug on captured prisoners in order to
> get them to reveal Japanese encryption techniques.
> Was he a master codebreaker or a torturer? Has history treated him too well?
> Certainly, his codebreaking techniques would be considered human rights abuses
> today.
well, life hasn't changed much, see echelon.
You might get a better response from this thread on talk.politics.crypto,
by the way, which is where I've set followups to this message.
-dmolnar
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Remark on practical predictability of sequences
Date: Tue, 27 Jun 2000 22:05:29 -0700
Mok-Kong Shen wrote:
>
> Pseudo-random sequences, being deterministically generated,
> always involve the issue of predictability. On the other
> hand, a good cipher prevents the opponent to obtain the
> plaintext from the ciphertext. It seems logical to conclude
> that, if one feeds a pseudo-random sequence to a good cipher,
> the resulting output sequence is practically unpredictable,
This rang a bell.
There's a paper by M. Bellare, S.Goldwasser and D. Micciancio
demonstrating this assumption does not always hold. They show that if a
Linear Congruential Generator (LCG) or truncated LCG produces the random
choices (nonces) required for the Digital Signature Standard, then the
results are completely breakable when the attacker knows the
coefficients of the LCG but not its seed value. The masking of the
nonces by the DSS algorithm can be solved even though it seems nonce
recovery should require solving the discrete logarithm problem.
Paper's at http://www-cse.ucsd.edu/users/mihir/papers/dss-lcg.html
John A. Malley
[EMAIL PROTECTED]
> since he can't recover the original sequence which he needs
> to do the inference in the first place.
>
> I should appreciate comments on this view.
>
> M. K. Shen
> ---------------------------
> http://home.t-online.de/home/mok-kong.shen
------------------------------
** 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
******************************
