Cryptography-Digest Digest #870, Volume #12 Sun, 8 Oct 00 05:13:01 EDT
Contents:
Re: Why trust root CAs ? (Alan J Rosenthal)
Re: Why wasn't MARS chosen as AES? (Dido Sevilla)
Re: Idea for Twofish and Serpent Teams ("Douglas A. Gwyn")
Re: Comments on the AES winner ("Douglas A. Gwyn")
Re: Why trust root CAs ? (nospam)
Re: Why trust root CAs ? (David Hopwood)
Re: Democrats, Republicans, AES... ("Douglas A. Gwyn")
Apologies for a faulty memory (John Savard)
Re: NSA quote on AES ("Douglas A. Gwyn")
Re: NSA quote on AES ("Douglas A. Gwyn")
Re: NSA quote on AES ("Douglas A. Gwyn")
Re: RSA Key generation (Paul Schlyter)
Re: On block encrpytion processing with intermediate permutations (Bryan Olson)
----------------------------------------------------------------------------
Crossposted-To: comp.security.misc
From: [EMAIL PROTECTED] (Alan J Rosenthal)
Subject: Re: Why trust root CAs ?
Date: 8 Oct 2000 04:02:59 GMT
[EMAIL PROTECTED] writes:
>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 ?
...
>Is there a chain of trust from any institution that I might trust,
>such as my bank, back to the root CAs ?
Obviously, the trust chain goes the other way. And you've identified, in my
opinion, a very big problem with this whole hierarchical trust scheme.
Do I trust my bank? I don't know, but I do trust them with my PIN;
really, it's theirs to begin with. My banking data and operations are
not a secret from my bank.
Do I trust the certificate authority which issues the SSL certificate which
causes me to be able to contact my bank via SSL? No! I don't even know who
that is. And I don't care. I just want to use SSL so that the connection
is unsniffable.
What about authentication? I wish I had a public key from my bank, perhaps
given to me on floppy, or perhaps encoded on the magnetic strip on the card
they gave me. In the absence of this, I type their hostname into my web
browser and hope. I don't think the root CA contributes to this process.
Indeed, my web browser tells me that the built-in root CA certificate has
expired and I should check my computer to see if it is REALLY the year 2000
(who woulda thunk it, I mean the web browser was actually written a whole
2 years before that). It's not a trust-inspiring situation.
But I certainly don't trust my bank with, say, DGP's root passwords.
Nor, for that matter, would I store my banking-related passwords where
other DGP sysadmins (i.e. those who know DGP's root passwords) could get
at them. There's no one entity which I feel I should relax with and trust
with all data.
What little I know of DNSSEC suggests to me that it has the same sort
of problem, although much bigger. Trust is not transitive, in computer
security or in real life. If my friend says something strange, I might ask
who told him that, and if he says it's Fred, I might say "ah, I don't believe
anything Fred says". The trust is based on the source, not the last link.
My friend might say "hey, Fred's a good chap, I trust him" and I trust my
friend, but I still don't trust Fred.
(Of course, DNSSEC is replacing a completely insecure system, whereas
web banking is replacing an indubitably more secure system, so DNSSEC is
arguably to be held to a lower standard, maybe.)
>As a non-US citizen, I have a slight problem with most of the CAs and browser
>vendors being US corporations.
There are a number of implications I could attempt to weasel out of this
statement of yours, but to the extent that one of them is that average
Americans have some reason to trust American corporations which we don't,
I strongly disagree. They are not on Americans' sides any more than on
Canadian's (for example) sides. I don't see any particular reason to trust
Thawte with my confidential data.
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: Why wasn't MARS chosen as AES?
Date: Sun, 08 Oct 2000 13:10:05 +0800
UBCHI2 wrote:
>
> Why wasn't MARS chosen as AES?
Lots of reasons. MARS has some odd structure that hasn't been well
analyzed yet. Also, it proved to be difficult to implement in hardware
and on processors that don't support the required instructions, viz.
variable-count 32-bit rotates.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Idea for Twofish and Serpent Teams
Date: Sun, 08 Oct 2000 06:21:21 GMT
David Blackman wrote:
> ... that target looks somewhat breakeable ...
Is that like somewhat pregnant?
Actually, of course it is breakable in principle.
The question is, how to do it *effectively* with
enougb reliability to matter.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Comments on the AES winner
Date: Sun, 08 Oct 2000 06:32:11 GMT
John Savard wrote:
> True. However, if it was possible to actually write the equation on a
> blackboard ...
That's simply a matter of how suitable one's suite of notation is for
the job at hand. Feynman onced showed how one could roll all the laws
of physics into a single equation, which was more or less:
Sum over i (U sub i) = 0
Of course, to see the details one has to unravel the notation.
------------------------------
From: [EMAIL PROTECTED] (nospam)
Crossposted-To: comp.security.misc
Subject: Re: Why trust root CAs ?
Date: 8 Oct 2000 01:39:15 -0500
We (a Chicago-based co-op) have been considering running our own non-profit CA.
The biggest obstacle is, to verify the information submitted with a CSR is not
inexpensive.
If we just promiscuously sign every request submitted, our CA cannot be
trusted. If we go to the same extremes to validate submissions as Verisign,
our rates will be high.
For the moment the goal is to only sign keys for people we know personally,
which means the CA will only really be useful within our circle of friends,
a relatively small community.
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 ?
You have to trust somebody, the root CA's are trustworthy only in that they
are big businesses with a strong incentive to take care in verifying the
entity to which they issue the certificate is actually who it claims to be,
and in protecting their signing key.
>Is there a chain of trust from any institution that I might trust,
>such as my bank, back to the root CAs ?
No, and that brings up the real question- why should you trust these specific
issuers of certificates, and no others? Why should you NOT trust web servers
with self-signed keys?
To some extent, I might be MORE comfortable with a server using a key signed
by a bank based in Switzerland, operating under their secrecy laws.
>Is there any reason, apart from the fact that they've been operating for
>a number of years now and AFAIK nothing's gone wrong, for us all to trust
>the root CAs ? Apart from a general lack of trust leading the the end
>of e-civilization as we know it ?
There's no reason not to trust them, they do take pains to ensure that they
do not issue a certificate for 'www.nationalbank.com' to a web server that
is actually operated by a malicious third party.
>As a non-US citizen, I have a slight problem with most of the CAs and browser
>vendors being US corporations. If I were a member of some organization
>or country that the US regards as an enemy (Libya, Iraq ??) I might have
>a more serious problem with it.
So start your own root CA in your nation. There's nothing to stop you, though
you may have difficulty getting Netscape and IE to include a Libyian key
server in their standard browser distribution.
------------------------------
Date: Sun, 08 Oct 2000 05:10:53 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Why trust root CAs ?
=====BEGIN PGP SIGNED MESSAGE=====
Daniel James wrote:
> In article <[EMAIL PROTECTED]>, Bruce Stephens wrote:
> > ["Secrets and Lies", Bruce Schneier] 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,
To do that you would need a trustworthy interface to the card that allowed
you to preview and confirm what is to be signed; a PC is inadequate for
that because it's not secure. However, let's assume that problem were solved
somehow. (I suspect that it won't actually be solved, just brushed under the
carpet :-( )
> 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.
In that case the certificate and the use of a CA are superfluous; the bank
could just as easily store your public key in their database record for
your account. That would be simpler, more efficient, and it would eliminate
a number of potential failure modes (attacks against the certification
standard, compromise of the bank's CA key, any problems in matching
certificate attributes to database records, etc.) Remember that the bank
already has to store a PIN for each card, so storing a public key instead
(or as well) is a straightforward change. There is no advantage to the bank
in using certificates.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOd+BhzkCAxeYt5gVAQEqEAf/RCjAXabrazj+oceIj+d8/WC/I+91mHwc
P5URHoux22bLAN8XOWBe0TK04UVwtR1d0Pt/mA1S1svTbrJ+JAFH3hR1hrr/88eU
Z1MwH+lbK96oYZbN6sSI3gmvyg/zPS4zXkgW6L9WJfP4Na6wrcjvAH1E9kpGlWcD
UtzO+ida9CsKo63FW9KZ+nCBvztt1iqZSZI7v/XSfXL35VuzvJq30JPKeyiSA7Lr
2TqH6v4mma6Scph641KnLWH1BNBavyq2jTvbix5aWkiFnTFvrsAQvpAeGPlsYB0W
+fOuDdEbmOIowjR/oMR0A+kZ7lDDhhgkwYvQ4mLvEKsCXr2Obq2DEw==
=+OuX
=====END PGP SIGNATURE=====
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Democrats, Republicans, AES...
Date: Sun, 08 Oct 2000 06:46:47 GMT
Albert Yang wrote:
> What I would have done is this, kept only the ones with "high level
> of security margain" and thrown out the rest.
This whole notion of a "security margin" is hogwash.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Apologies for a faulty memory
Date: Sun, 08 Oct 2000 06:43:14 GMT
Like that asteroid that was going to hit the Earth for one day,
shortly after Rijndael was selected as the AES, I was concerned that
the usual number of rounds might be a serious weakness.
But I have recalled that I thought this once before - at a fairly
early date, perhaps when I was first working on my page about Rijndael
- and even sent an E-mail to one of the developers of Rijndael about
my concern.
But that had completely slipped my mind, and after Rijndael was
selected as the AES, and I reviewed my web page on it to upgrade it, I
started the whole reasoning process from the beginning again!
Anyways, in addition to congratulating the developers of Rijndael on
their success, I must also thank Brian Gladman for suggesting keys and
block sizes that are odd multiples of 32 bits - since that happens to
create a solution to the apparent problem, if there is any remaining
grounds for concern.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA quote on AES
Date: Sun, 08 Oct 2000 07:00:50 GMT
"SCOTT19U.ZIP_GUY" wrote:
> >..., NSA intends to use the AES where appropriate in meeting the
> >national security information protection needs of the United States
> >government."
> These are weseal words if nothing else. To say they will use it
> where its appropraite does not mean anything at all. They may
> only use it in the sense of decoding messages.
No, did you miss the words "information protection needs"?
> And they don't say where its appropriate for them to use.
That has already been stated up front by NIST. AES is intended
for use to secure sensitive-but-unclassified (SBU) information.
An example would be competitive-procurement records.
> But I guess it is to much to expect an honest anwser from them.
It is too much to expect any answer when no question was asked.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA quote on AES
Date: Sun, 08 Oct 2000 07:04:44 GMT
Brian Gladman wrote:
> ... I am hence fairly
> certain that the techniques that NSA use to implement Rijndael for
> classified information protection will themselves remain classified.
Assuming they actually take that approach.
More likely, systems with more extensively developed theory
would be preferred, since certain properties could be proved
instead of guessed.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA quote on AES
Date: Sun, 08 Oct 2000 07:08:05 GMT
UBCHI2 wrote:
> Let's see a definitive statement that they can't break the AES.
That would not be consistent with national security requirements.
As I think Jim Gillogly noted elsewhere, if true and believed, it
would steer our enemies toward more private communication. If
not (true and believed) then you wouldn't be satisfied anyway.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: RSA Key generation
Date: 8 Oct 2000 09:02:41 +0200
In article <8ro0f2$h2p$[EMAIL PROTECTED]>,
Martin Wolters <[EMAIL PROTECTED]> wrote:
> In my Implementation of RSA, I use
> the following algorithm to generate
> d from e and phi:
>
> 1. k=0
> 2. increase k
> 3. d = (k*phi+1)/e
> 4. repeat steps 1+3 until d is an Integer.
>
> Is there any faster way, to generate d?
d = inv( e, phi )
where the inv() function can be implemented as (using C-like
syntax and assuming there's a data type "bigint" which can
handle large integers):
bigint inv( bigint a, bigint n )
{ /* Return x such that (a*x)%n = 1 where 0 < a < n */
bigint g0=n, g1=a, g2;
bigint u0=1, u1=0, u2;
bigint v0=0, v1=1, v2;
bigint y;
while( g1 != 0 )
{ /* gi = ui*n + vi*a */
y = g0 / g1;
g2 = g0 - y*g1;
u2 = u0 - y*u1;
v2 = v0 - y*v1;
g0=g1, g1=g2;
u0=u1, u1=u2;
v0=v1, v1=v2;
}
if ( v0 >= 0 )
return v0;
else
return v0 + n;
/* or with unsigned arithmetic, simply:
return v0;
*/
}
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Sun, 08 Oct 2000 08:09:52 GMT
Mok-Kong Shen wrote:
>
> Bryan Olson wrote:
> > Seem to claim? Give some useful information? I posted
> > it. It's been right there in front of you.
>
> Why can't you say clearly with one short sentence here
> whether my scheme is difficult to handle or easier to
> handle than the normal case where the block cipher is
> used without permutations? If may be that I am, for
> whatever reason (good or bad), not aware of what you
> have already said. But what I am requesting is only one
> short sentence, and should cause you less effort than
> the two lines above, I firmly believe. Why didn't you
> do that? But I think I can tell the reason why you have
> constantly avoided to give the answer through diverse
> maneuvres: Because on the one side (understandbly) you
> dislike to admit that it takes more work to crack my
> scheme than the normal scheme.
But I did crack your scheme, in as much as this kind of
general idea can be cracked. That's what's been right in
front of you.
> But on the other side
> you also can't claim the opposite, because that's
> impossible, as can be simply explained from 'first
> principle', i.e. from a very general point of view. For
> the block cipher, when used in the normal way, has a
> certain measure of strength against any given attack,
> including the one that you invent. Now you need, as you
> wrote previously, to have a certain large number of
> blocks to be processed together in order to realize your
> method. This is a 'constraint', while in the original
> case, i.e. without permutation, you are free and don't
> have that constraint (you can deal with one single block
> or any number of blocks you like). It is well-known from
> solution of optimization problems that one gets a less
> favourable optimum when there are constraints. Thus the
> work of the analyst with my scheme must be higher (and
> can never be lower) than in the case with the original
> block cipher (without permutation).
Wrong. First, the number of blocks is not a constraint
imposed by the scheme; it's the value the attacker
chooses (there may be better attacks). Second and more
important, the optimization theory result is irrelevant.
It says that if one set of constraints is a superset of
another, the superset will never have a better solution.
Here we're talking about two different systems, neither
is strictly more restrictive than the other.
> One can look into
> the matter in another way: Suppose the total effort to
> crack my scheme is less than cracking the original
> scheme. That would mean that my scheme combined with
> your method constitute a new and better method of
> attacking the orginal cipher!
False. As I already explained, your scheme does not
use the original block cipher as a unit. It lets out
intermediate state.
> (For, if I use in my
> scheme always the identity permutation, then the scheme
> degenerates to the case of using the block cipher in
> the common way.) Do you think that that could ever be
> true?
Always using the identity permutation would contradict the
specification of your scheme. The pseudo-random permutation
you specify is the defect that enables the attack.
> > > Having said the above,
> > > why do you think it is not well-formed? Could you
> > > elaborate that? I want to know whether there is
> > > reduction or enhancement of strength. Is this issue
> > > not well-formed? Where?
> >
> > See my rhetorical question on breaking an unspecified
> > cipher.
>
> Well-formedness is a syntactic issue, not semantic or
> otherwise. So which part of my question is not
> well-formed?
Well-formed has a special meaning in formal languages;
here it simply means how you formed the question. See
below.
> You claimed that nothing in my writing is science. Now
> you have previously attempted to work out something to
> deal with my scheme. Since my scheme is, according to
> your opinion, not science, isn't it clear that your work
> was consequently also not science?
No, of course not. The attack is a real result. Am I
absolutely certain that I didn't overlook something
important that would invalidate it? Of course not, but
results are reproducible so check it out.
[...]
> As I argued above, the attack in any case causes more work
> than in the case without permutation. 'Exposing the key'
> means a crack or a part of it, of course. But see below.
The argument was nonsense. What was that - proof by vague
analogy to another field?
> > I've learned not to make your questions the center of my
> > efforts. I posted proofs in
> > http://x56.deja.com/[ST_rn=ps]/getdoc.xp?AN=636649064
> > that you yourself requested in
> > http://x56.deja.com/[ST_rn=ps]/getdoc.xp?AN=636497466
> > You then incorrectly brushed it off as having some bug. Had
> > you worked to understand the material, you would not have been
> > mislead by what you thought was a counter-example. I can tell
> > you that getting the proof to the point that it did not have
> > that "bug" took me a while.
>
> I never claimed bugs. If you spend 'enough' resource to
> attack with your method, then I suppose that it should
> function. However, it is the AMOUNT of the work of doing
> your attack that matters.
The attack is efficient - check it out. I already estimated
it should run within five minutes. Of course the end-game
depends on the block cipher which is unspecified, but the
attack isolates the last round or two, so most should then
fall quickly.
> I was thus posing the question
> of whether permutation diminishes or enhances the security.
> This was in a formulation that I believed to sound better.
Your formulation is nonsense. We do not know for certain
what the best attacks on the popular Feistel ciphers are,
and your scheme does not specify a particular cipher. Your
scheme is a general idea and therefore under-specified for
specific attack. We do not know what are the best attacks
on various specific formulations of your scheme.
What I can say is that the general idea of your scheme is
terrible. The attack that efficiently breaks it is based on
entirely reasonable parameters where your scheme does not
name a particular choice. I can identify a lesson from the
attack: do not expose intermediate state from the encryption
or decryption process.
[...]
> What do you mean by two simultaneous streams? There is
> one sender and one receiver. Normally there is only one
> channel. Messages are send sequentially in it. If there
> are more than one channel, why can't we deal with these
> independently? There will then be one PRNG for each channel
> and the PRNGs may even be different. Of course, the seeds
> will also be different. There can be no interference
> between the channels at all. (The transmission protocol
> separates these.)
You seemed to propose this as alternative to a block
cipher and conventional chaining mode. A secret key has a
value, but is otherwise stateless. We can back keys up,
encrypt multiple streams, and decrypt stored text without
knowing a state particular to the time of encryption. Users
do all of those things and are not likely to re-engineer
their systems around the shortcomings of a scheme that
cannot.
--Bryan
--
email: bolson at certicom dot com
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
******************************
