Cryptography-Digest Digest #864, Volume #12 Sat, 7 Oct 00 14:13:00 EDT
Contents:
Re: Why trust root CAs ? (Daniel James)
Re: i should have finished high school ("Paul Lutus")
Re: It's Rijndael ([EMAIL PROTECTED])
Re: NSA quote on AES (Mok-Kong Shen)
Re: NSA quote on AES (Mok-Kong Shen)
Re: NSA quote on AES (Jim Gillogly)
Re: Why trust root CAs ? (zapzing)
Re: How to use PGP2.6.2?? (Rich Wales)
Re: NSA quote on AES ("Brian Gladman")
Re: is NIST just nuts? ([EMAIL PROTECTED])
Re: Choice of public exponent in RSA signatures (David A Molnar)
Re: Choice of public exponent in RSA signatures (David A Molnar)
----------------------------------------------------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Sat, 07 Oct 2000 15:13:57 +0100
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Bruce Stephens wrote:
> > Bruce Schneier's new book, "Secrets and Lies", has an interesting section
> > on certificates and such where, if I understand him correctly, he concludes
> > that the real security in B2C web transactions comes from the credit card
> > company and it's limits on personal liability and not the CA.
> >
> > If had the book I'd give the page,
>
> pp.238-239.
>
> "Digital certificates provide no actual security for electronic
> commerce; it's a complete sham."
Yes, Bruce likes saying that - he comes across as very sceptical of any benefits
claimed for PKIs and certificates.
As things stand today he's right - certificates are used as a guarantee of a
party's identity, and not a very good guarantee at that. It doesn't have to be
this way.
Imagine, if your bank gave you a smartcard as a credit card, and that card
contained a private key you could use to sign messages, a certificate for that
key signed by the bank, and the bank's CA certificate. The bank could then say
that they wouldn't accept any payment made by you unless it was signed with your
key, and that any correctly signed payment *must* have come from you so your
card account would be debited even if you denied making the payment. The only
way that could be done is if someone obtained your card and your PIN (or broke
the digital signature algorithm used by the card). This would provide good
security for the bank, because they would be able to say with a high degree of
justification that any correctly signed payment must have come from you or from
someone else acting on your behalf (with your card AND your PIN) - but it
doesn't provide any protection for the customers that they're not getting at the
moment from the banks' and credit card companies' policy of refunding payments
that are made fraudulently.
The point here is that the banks aren't under any obligation to provide that
protection. They do so because they make money on every transaction, and so it's
financially to their advantage to keep the transaction count high, and so they
encourage their customers to use their cards online by offering to indemnify
them against fraud (and by insuring against part of the cost of doing so). It
wouldn't take much of an increase in the level of fraud, or of the cost of
insuring against it, to change this.
A bank could also offer a service whereby it would issue identity certificates
to online traders signed with its own CA key (whose certificate is on your smart
credit card). You still don't know with absolute certainty what the identity of
that trader is, but you do know with a high degree of certainty who your bank
thinks that trader is. This - from the point of view of someone trying to make
an online purchse from that trader using funds from that bank is all that really
matters.
Digital certificates and PKIs provide a means whereby trust, once established,
can be shared and can be communicated between parties who trust on another. None
of this plays much part in eCommerce security today because the banks see it as
in their interest to indemnify their customers against loss, so their customers
don't actually have to care too much about trust. This state of affairs should
not be expected to last.
Cheers,
Daniel.
------------------------------
From: "Paul Lutus" <[EMAIL PROTECTED]>
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: i should have finished high school
Date: Sat, 7 Oct 2000 07:42:56 -0700
ca314159 <[EMAIL PROTECTED]> wrote in message
news:8rn255$1bj$[EMAIL PROTECTED]...
> It might be interesting though to consider how
> this effect may be used for FTL computation.
To earn its name, FTL computation would rely on FTL communication. Let's see
if there is any --
> For instance, if a hologram is made of a slide rule
> with a displacement between the slides, then
> the apparent FTL motion due to the lighthouse effect,
The lighthouse effect is not an FTL effect. Not apparent, not real. Imagine
the water coming out of a swinging hose. None of the water travels at
greater than the basic stream velocity. It's the same with light.
--
Paul Lutus
www.arachnoid.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: It's Rijndael
Date: Sat, 07 Oct 2000 15:55:40 GMT
In article <8rm094$a4k$[EMAIL PROTECTED]>,
Bryan Olson <[EMAIL PROTECTED]> wrote:
> Jim Gillogly
>
> [snip of some disadvantages of a variable round count]
>
> > In short, I think picking a specific number makes good sense,
> > even though I'm not sure what that number should be.
>
> And if Jim Gillogly isn't sure, think where corporate America
> stands. Just the three AES key lengths doom the nation, and
> later the world, to waste vast quantities of time and money.
>
> Enterprises all over the globe will task teams of programmers,
> MBA's and accountants with choosing a key size. They'll hold
> meetings. They'll write reports. Some will argue for the
> efficiency of 128-bit keys, and then be condemned as
> irresponsible by those who insist on 256. Others will argue
> the need for "balance" as clearly offered by the 192-bit size.
> And then the inevitable expert opinion: "while all sizes have
> advantages and disadvantages, no one key size is suited for
> all our applications". Corporate policy manuals will bloat
> with "rules", "guidelines" and "authorities" for determining
> the appropriate key size for every possible bit of data.
Two bits of wisdom:
1. Why not define a meta-standard to be respected by all future
protocols and which defines which cipher is used, at how many rounds,
at which key size, and so on. Why not play it safe? The cost is only a
few more bits transmitted or saved per message. It is impossible to
estimate the probability of somebody discovering a catastrophic attack
against the AES in the future, but the possibility does exist. If such
an attack is found and no such meta-standard is in place, then the cost
of changing the information processing infrastructure will be huge,
possibly even larger than the Y2K debacle.
I understand that hardware is used in lots of places, but at least the
rest of the system that is software based could be made much more
resilient. Even if hardware, special chips can be developed where the
crypto algorithms are microcoded and can be changed whithout changing
the chip.
2. If naked AES is used, why not always use 256 bit keys? I don't
really buy the efficiency argument. Show me exactly where the slightly
greater work factor for handling larger keys is really significant?
Possibly there are some cases, so let them worry about what to do or
how to inter-operate with the rest of the world that sticks to 256
bits. As a relative outsider, I always find it strange how
cryptologists worry about bits as if they were worth their weight in
gold. Maybe this is a meme remnant of a time decades ago where crypto
was always done in hardware and where CPUs were rare and expensive
thing.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NSA quote on AES
Date: Sat, 07 Oct 2000 19:18:04 +0200
Brian Gladman wrote:
>
> The real art now is to build an actual implementation that is as strong as
> algorithm itself and this is a very difficult undertaking where the 'closed
> world' is still quite a way ahead of the 'open world'. I am hence fairly
> certain that the techniques that NSA use to implement Rijndael for
> classified information protection will themselves remain classified.
What do you mean by 'an implementation as strong as algorithm
itself'? If programmed correctly, the implementations can
differ, as far as the users are concerned, only in efficiency
and that could be compensated, if necessary, by more hardware
in most cases, I suppose.
On the other hand, it is conceivable that some modifications
or some supplementary features could be added to enhance
strength and these are then classified and not rendered
availble to the general public. Or Rijndael could be used
as a component of a multiple encryption together with
some classified algorithms.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NSA quote on AES
Date: Sat, 07 Oct 2000 19:18:10 +0200
Brian Gladman wrote:
>
> I am absolutely certain that NSA attempts to manipulate the perceptions of
> outsiders by issuing statements designed to be misinterpreted. This does
> mean that considerable care is needed in reading them. I hence don't blame
> people for being sceptical about their content but they won't always be
> right in taking this line.
Given that trust is such a difficult issue in every aspects
of life, not only in crypto, I suppose that it is better
not to waste too much time on disputing about correct
interpretations of some official statements but to use that
time instead to do useful work, i.e. in the present case to
study and attempt to crack Rijndael. For every minute
thus spent would contribute to the desirable goal of really
ascertaining the strength of that algorithm.
M. K. Shen
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: NSA quote on AES
Date: Sat, 07 Oct 2000 17:07:57 +0000
Tim Tyler wrote:
> You can draw practically no conclusions about what use the NSA will put
> AES to - besides the fact that they'll use it for something.
Not even that. They said "where appropriate", and if it so happens that
they have no applications for which it's appropriate, then they won't use
it.
I interpret the PR release as a pleasant letter of support for the
standards prccess with no actual commitment to use it. I expect
them to use it for sensitive unclassified material, but I don't
think they've committed to do so with this note.
> This is, of course, as it should be. NSA press releases should not convey
> any information about the inner workings of the agency - except when it is
> deemed necessary for PR purposes. If we had found out much about what
> the NSA were going to be doing the AES, we would have gained information
> we did not need to know, as would any opponents of the US government.
Agreed. I'm pleased that they were able to share the results of their
hardare expertise with us for evaluating performance of the candidates --
I can't imagine this having been done 30 years ago.
--
Jim Gillogly
16 Winterfilth S.R. 2000, 17:03
12.19.7.11.0, 3 Ahau 3 Yax, Fourth Lord of Night
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Sat, 07 Oct 2000 17:22:41 GMT
In article <iEpD5.10380$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Alun Jones) wrote:
> In article <eMoD5.416654$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > So, I can discover snakeoil CA's procedures for verifying bogus.com,
> > and assure myself that they have checked out bogus.com.
> > But how can I trust snakeoil CA itself ?
> > I had a conversation with a CA on this subject and the answer was
> > "because it's in the browser". But my browser was downloaded off
> > the Internet in clear, and besides, do I really trust the browser
> > vendor ? Do you trust Microsoft not to lie ? Do you trust Microsoft
> > or Netscape to produce secure independantly verified code ?
>
> The answer, I'm afraid, is another question - do you trust the posters
in
> this newsgroup to answer your question?
>
> Trust has to begin with an explicit trust of someone. That link
carries a
> weight of risk. Each implicit link of trust thereafter carries a
weight of
> risk, and the longer the chain of trust goes, the more risk you carry
that
> one or more elements of the chain are untrustworthy.
>
> But the alternative is not to trust. And with that, you'd be unable
to do
> business with anyone except by one-to-one barter. Trust is implicit
in the
> cash system, in the banking system, and in the prospect of buying
through
> any means beyond direct barter.
Actually direct barter has it's problems, too.
Sorry :(
--
Void where prohibited by law.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Rich Wales)
Crossposted-To: alt.security.pgp
Subject: Re: How to use PGP2.6.2??
Date: 7 Oct 2000 17:32:35 -0000
Imad R. Faiad wrote (in alt.security.pgp):
> I would not recommend generating an RSA key with any PGP
> 2.6.x . . . because most if not all PGP 2.6.x are compiled
> with the Blum flag set. What this does is let the program
> look for primes congruent to 3 modulo 4. This shaves about
> 2 bits from the domain of the key.
I can indeed confirm that the 2.6.3ia source code does use Blum primes.
I'm not sure I see this as a big issue with a 2K-bit RSA key, however.
And if 4K-bit RSA keys manage to come into wider use, I don't see it as
an issue at all.
As for whether or not it makes any sense to use Blum primes for RSA (as
opposed to random primes), I'm crossposting to sci.crypt as well as to
alt.security.pgp.
> Also, the quality of the primes generated in later versions
> of PGP is much better in my view.
Could you provide us some more details regarding why you believe this?
FWIW, the 2.6.3ia source code explicitly doesn't try to select "strong"
primes. A comment in the code claims that there is no valid reason to
worry about using strong primes. Is this advice outdated?
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: NSA quote on AES
Date: Sat, 7 Oct 2000 18:59:33 +0100
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Brian Gladman wrote:
> >
>
> > The real art now is to build an actual implementation that is as strong
as
> > algorithm itself and this is a very difficult undertaking where the
'closed
> > world' is still quite a way ahead of the 'open world'. I am hence
fairly
> > certain that the techniques that NSA use to implement Rijndael for
> > classified information protection will themselves remain classified.
>
> What do you mean by 'an implementation as strong as algorithm
> itself'? If programmed correctly, the implementations can
> differ, as far as the users are concerned, only in efficiency
> and that could be compensated, if necessary, by more hardware
> in most cases, I suppose.
No, the strength of an implementation to resist attack will vary widely.
For example, take the shortest AES key of 128 bits with the algorithm
implemented in software and run in a typical operational situation.
The probability that the key will leak out or be stolen (for example, by a
covert virus) will always be much higher than 2^-128 (the probability of
picking the key at random).
Implementations nearly always have weaknesses that can be exploited and
these undermine the strength ot the algorithm being used.
Brian Gladman
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: is NIST just nuts?
Date: Sat, 07 Oct 2000 17:53:30 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> : [EMAIL PROTECTED] wrote:
>
> :>I believe there's some argument that the effective strength was
only at
> :>about the 56-bit level anyway. According to the story, reducing the
> :>size of the keyspace reflected the properties of the underlying
> :>algorithm, and didn't really make the system weaker than it already
> :>was.
>
> : I don't think this is a meaningful statement. The key size does put
an
> : upper bound on a cipher's strength, but apart from that, strength is
> : not a one-dimensional entity [...]
>
> : Ultimately instead of talking of bits of strength, we should put a
> : dollar value to any attack we devise [...]
> : Using such a formula, it becomes now possible to define an objective
> : methodology to compare the strength of ciphers [...]
>
>I agree $s to break is one of the best measures of strength - despite
>it being "a one-dimensional entity".
Sorry, I have been sloppy here. I think we agree that cipher strength
is not a one-dimensional entity because one cipher can be stronger in
one context and another in a different context. For example one cipher
can be stronger on low end smart cards, another can be stronger on
desktop software applications where speed is of little concern, another
where known plaintexts are very expensive, and so on. Now, in each
context the best way to compare the strength of ciphers is to define
the dollar cost of potential attacks, rather than analyze numbers that
bear little relation to real world costs. For example, the cost of
known plaintexts is clearly not linear.
> : Finally compare the ciphers taking into account not so much the
> : percentage of rounds that can be broken at a specific cost, but
rather
> : the rate at which the cost is growing at each successive round. That
> : rate will best reflect the structural strength of the cipher.
>
>Cost isn't everything. The best attack that may be publicly known
>about may be brute force, a fact that would lead to a high "cost-to-
>break" value - while our opponents may be able to reduce our
>algorithm to mincemeat at a very low cost.
No, no, you misunderstood me. All ciphers can be broken with less than
brute force at very low rounds. I suggest we analyze how fast the cost
grows for breaking successive rounds. For example, suppose we want to
compare ciphers A and B both of which use 16 rounds. Let us define MV
as the maximum value of the messages that will be encrypted. If the
best known attacks at cost equal to MV, break 8 rounds of A and 10
rounds of B, many would suggest that A is stronger than B. But if 7
rounds of A can be broken at a cost of 0.7*MV and 9 rounds of B at a
cost of 0.2*MV, then I suggest that B is stronger than A.
> The "objective methodology" appears to have a subjective element.
> --
Yes, well, maybe I should have written "more objective methodology than
what is currently the norm".
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: 7 Oct 2000 17:57:05 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Doesn't the security of using OAEP depend on the security of the hash
> function, H, and the generator, G? The paper on OAEP which I read
> simply used a random oracle model for H and G... practical
> implementations need to use real functions, like SHA1 for the hash, and
> RC4 or SEAL or <pick-your-favorite-cipher>-OFB for the generator. How
> much does this affect security?
fine question. as far as I know, no one has actually figured out the
specific relation which must not hold over G and H for OAEP to be
secure. this makes it hard to tell if SHA1, for instance, is a good
instantiation of the random oracle for this scheme.
-david
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: 7 Oct 2000 17:58:51 GMT
Francois Grieu <[EMAIL PROTECTED]> wrote:
> But AFAIK the FDH concept, or much less PSS, is not part of any
> ISO standard; is there one in P1363 or PKCS ?
PSS is in the P1363 standard, if I recall correctly.
Now the 1363 standard, I guess.
-David
------------------------------
** 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
******************************
