Cryptography-Digest Digest #878, Volume #12 Mon, 9 Oct 00 09:13:00 EDT
Contents:
Re: Why trust root CAs ? (Vernon Schryver)
Re: Why trust root CAs ? (Daniel James)
Re: Why trust root CAs ? (Daniel James)
Re: It's Rijndael (Marc)
Re: Any products using Rijndael? (Runu Knips)
Re: Choice of public exponent in RSA signatures (Francois Grieu)
xor algorithm ("Antonio Merlo")
Re: SDMI challenge (Dido Sevilla)
Re: Internet Security Question ("Tony")
Re: xor algorithm (Eric Hambuch)
Re: securely returning password info to a server from a client ("Arnold Shore")
Re: Microsoft CAPI's PRNG seeding mechanism ("ink")
Re: The talk of R. Moris (Ross Anderson)
Rijndael has a very good S-Box (John Savard)
SSL/TLS Certificate Request message ("Johnny")
Re: Why trust root CAs ? (Anne & Lynn Wheeler)
Re: Advanced Encryption Standard - winner is Rijndael (Tim Tyler)
Re: Why trust root CAs ? (Anne & Lynn Wheeler)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: Why trust root CAs ?
Date: 8 Oct 2000 08:52:32 -0600
In article <[EMAIL PROTECTED]>,
Anne & Lynn Wheeler <[EMAIL PROTECTED]> wrote:
> ...
>However, if public keys are registered (along with the domain name),
>the existing domain name infrastructure could return the public key in
>addition to other information.
>
>This creates something of a catch-22 for ca infrastructure ... fixing
>the domain name integrity (with public keys) so that CAs can rely on
>domain name integrity as the authoritative source for domain names
>... also creates the avenue making the domain name certificates
>redudant and superfulous.
Like the new secure DNS machinery, where every DNS server signs its
answers, establishing a chain of authenticating public key signatures back
to the root?
There's promise there, but also problems. I've not been keeping up, but
I understand that one problem is that they've not figured out how to sign
all of the RR's in .com before it's time to sign them all again. It takes
time to sign 30,000,000 records with a public key. Another problem is
that adding signatures make packets on the wire a lot bigger.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Mon, 09 Oct 2000 10:20:49 +0100
Reply-To: [EMAIL PROTECTED]
In article <EM6E5.23226$[EMAIL PROTECTED]>, Lyalc wrote:
> An electronic signature related to a specific purchase order has no inherent
> relationship to an electronic signature on the transaction paying for that
> order. That's how business is today, and neither CAs nor certs are going to
> change that anytime soon.
No, I'm afraid you're probably right. That doesn't alter the fact that the
technology exists to improve the security of the whole business model.
> A certificate issued by your bank has no meaning when it comes to your
> ability to send an email or be bound by the email's contents, apart from
> saying "person X is known to us and has an account". What's in it for the
> bank? The bank has the same liability, added infrstructure to operate and
> no cost savings. Why would a bank be a CA?
A bank would be a CA to issue certificates for its own customers' online
banking and eCommerce activities because that eliminates the need for anyone
to trust a 3rd-party CA. A bank might well not want to accept any liability
for any other use of the certificates it issues - but could do so as a service
to its customers if those customers demanded it (e.g. to stop them moving
their business to another bank that did offer that service).
> Trusting Root CAs:
> Well, you can only trust them as much as you trust your software - no more.
> If a false "CA Root" cert is inserted into the CA Cert store ..., then
> any certificate signed by that false CA will be trusted by your machine.
You have to trust the software, certainly, and that is a problem that can be
at least partly solved by code-signing and other such techniques.
If the certificate store for the root CA cert is a read-only file on your
(smart) credit card you can have rather more confidence in it than if it just
resides on a disk.
> Will you check the CA trust chain and CRL for every cert you receive?
> If not, then you rely on the trust you place in your machine, not the CA.
One should make that check, yes, whenever the certificate is used for any
value-bearing transaction. I wouldn't expect a bank or credit card company to
have to uphold any payment made using a revoked or expired certificate.
Cheers,
Daniel
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Mon, 09 Oct 2000 10:20:50 +0100
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Anne & Lynn Wheeler wrote:
> in retail business wtih consumer ... having consumer "identity"
> certificates ... creates privacy issues.
In face-to-face retail business, perhaps. For any (e)mail-order business
the trader needs a delivery address and once that is disclosed there is
very little privacy left.
> Various financial operations have done relying party only certificates,
> which address both privacy concerns and liability concerns. Effectively,
> certificate contains the account number.
Agreed. Privacy concerns are not a reason to eschew PKI schemes.
> Given that the financial institution needs to read the account record
> to obtain meaningful information (including the certificate original),
..
> Since every field in the copy of the certificate is also in the
> original of the certificate, it is possible to compress the
> certificate appended to the transaction to zero bytes. This can be
> significant when an uncompressed certificate is 10-50 times larger
> than the financial transaction it is appended to.
Then, of course, only the bank can verify the signature. I think it's
important that other parties involved in the transaction can verify the
customer's signature, and so the full certificate will have to be sent
with each transaction, and the full certification chain (and revocation
lists) must be available to all parties. I agree that that adds somewhat
to the volume of comms trafic for each transaction, but it does buy useful
security.
Cheers,
Daniel.
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: It's Rijndael
Date: 9 Oct 2000 09:33:04 GMT
>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.
This idea is good, but.. Since the owner of the message has to locate
the correct decryption key anyway, this type of information is better
stored with the KEY, not the message.
Why? Because it does not change the message size (important for
in-place operations such as HD encryption). And because it does not
unnecessarily reveal information to an attacker.
------------------------------
Date: Mon, 09 Oct 2000 11:45:20 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Any products using Rijndael?
Marc wrote:
> Why do you trust Twofish/Blowfish more than IDEA?
Well, I trust the principles behind Blowfish because
no matter which breaks one will find in future, it
is very, very likely that the random sboxes of
Blowfish will resist them.
Therefore Blowfish lacks the most important weakness
of most ciphers: they have only been optimized
against known attacks.
And Twofish, well it is more a mathematical concept
just like IDEA, but at least it has 128 bit blocks
and no known weak keys.
> Hasn't IDEA received more analysis already?
AFAIK yes - at least more than Blowfish.
> Do you have logical reasons towards your prefered
> ciphers or is it just a feeling?
Besides the fact that I believe Blowfish is very
hard to break (as described above), the two
*fish ciphers are also free, while using IDEA
legally is only possible in (a) freeware or
(b) for a IMHO really expensive license.
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Mon, 09 Oct 2000 11:59:02 +0200
David A Molnar <[EMAIL PROTECTED]> wrote:
> Francois Grieu <[EMAIL PROTECTED]> wrote:
>> I whish the difference [in security between FDH and PSS] could be
>> quantified ! I'd buy a 40% extra verify time (20% extra modulus size)
>> for a deterministic signature.
>
> It can be. What you do is you look at the security guarantee for FDH
> and the one for PSS and calculate. If memory serves, in order to get
> the same security level as 1024-bit modulus for PSS, you need something
> like a 3000 bit modulus for FDH.
>
> There was a recent paper "On the Exact Security of FDH" in this year's
> CRYPTO. I haven't read it. It may modify the calculations somewhat.
Thanks. I located the paper [6] and here are the abstract:
The Full Domain Hash (FDH) scheme is a RSA-based signature scheme in
which the message is hashed onto the full domain of the RSA function.
The FDH scheme is provably secure in the random oracle model, assuming
that inverting RSA is hard. In this paper we exhibit a slightly different
proof which provides a tighter security reduction. This in turn improves
the efficiency of the scheme since smaller RSA moduli can be used for
the same level of security. The same method can be used to obtain a
tighter security reduction for Rabin signature scheme, Paillier
signature scheme, and the Gennaro-Halevi-Rabin signature scheme.
And part of the text:
The reduction in [5] bounds the probability eps of breaking FDH in
time t by eps'*(qhash+qsig) where eps' is the probability of inverting
RSA in time t' comparable to t and qhash and qsig are the number of
hash queries and signature queries requested by the forger.
The new reduction bounds the probability eps of breaking FDH by roughly
eps'*qsig with the same running time t and t'. This is significantly
better in practice since qsig is usually much less than qhash. (..)
However, the reduction is still not tight and there remains a sizable
gap between the exact security of FDH and the exact security of PSS.
If no devil is hidden in the "roughly", proof, and other factors,
it looks like the extra cost of a deterministic signature compared to
a randomized scheme like PSS may be quite low.
I have many questions:
- has someone an updated quantitative security comparison of FDH versus
PSS for pratical applications ?
- can FDH with message recovery be done, maybe by XORing the message part
with some hash of the rest, possibly iteratively in sort of a Feistel
Cipher ? and how does this affect proved security bounds ?
- is there an accepted standard (ISO/IEC, P1363, PKCS) with a signature
scheme that can be viewed as an instance of FDH, or even better
of FDH with some form of message recovery ?
Francois Grieu
[5] M. Bellare and P. Rogaway: The exact security of digital
signatures: How to sign with RSA and Rabin
Advances in Cryptology - Eurocrypt 96 Proceedings, Lecture Notes
in Computer Science Vol. 1070, U. Maurer ed, Springer-Verlag, 1996.
Full paper online at:
<http://www-cse.ucsd.edu/users/mihir/papers/exactsigs.html>
[6] Jean-Sebastien Coron: On the exact security of Full Domain Hash,
Proceedings of Crypto '00, Vol 1880 in LNCS, Springer-Verlag, 2000
online in Postscript at:
<http://www.eleves.ens.fr:8080/home/coron/science.html#5>
For sale in PDF at:
<http://www.springer.de/cgi-bin/search_book.pl?isbn=3-540-67907-3>
------------------------------
From: "Antonio Merlo" <[EMAIL PROTECTED]>
Subject: xor algorithm
Date: Mon, 9 Oct 2000 11:57:58 +0200
How strong will be an encryption method based on a xor operation with a pass
phrase (or password) an a buffer to encrypt? (suppossed a very strong
password of, let's say 16 letters, combining uppercase, lowercases and
digits)
How will you cryptoanalise that algoritm?
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: SDMI challenge
Date: Mon, 09 Oct 2000 18:27:47 +0800
Scott Craver wrote:
>
> Dido Sevilla <[EMAIL PROTECTED]> wrote:
> >Scott Craver wrote:
> >>
> >> Hurry up, you have 3 1/2 hours to submit an attack.
> >
> >Let him wait. I hope he publishes his attack two days *after* the RIAA
> >has committed to using a particular technology.
>
> I have no reason to wish upon the poor fellow the same thing
> what happened to the author of DeCSS. Anyone who believes SDMI
> analysis should be postponed until SDMI is set in stone should
> be willing to pay any legal bills or fines cryptanalysts' might
> accumulate.
>
Well, this whole hoopla with DMCA kinda reminds me of a little quote
from the Illuminatus Trilogy:
Hexagram 23. Breaking Apart
...
The first correlation is with the unbalance between technological
acceleration and political retrogression, which has proceeded earthwide
at everwidening danger levels since 1914 and especially since 1964. The
breaking apart is fundamentally the schizoid and schismatic mental fugue
of lawyer-politicians attempting to administrate a worldwide technology
whose mechanisms they lack the education to comprehend and whose
gestalttrend they frustrate by breaking apart into obsolete Renaissance
nation-states.
-- Robert Shea and Robert Anton Wilson, "The Eye In The Pyramid"
It's happening, here and now. Besides, the DMCA and the SDMI's efforts
are nothing but a lost cause. They're trying to do what is
technologically impossible. There is no such thing as a trusted
client. Everyone on this list (Bruce most especially) has been shouting
this for years, but no one seems to be listening.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
Reply-To: "Tony" <[EMAIL PROTECTED]>
From: "Tony" <[EMAIL PROTECTED]>
Subject: Re: Internet Security Question
Date: Mon, 9 Oct 2000 11:49:37 +0100
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Tony" <[EMAIL PROTECTED]> writes:
> > Thanks for your help regarding this issue. I actually phoned their help
> > line 4 times. On each occasion they give a different reason for the
problem
> > but one of the explainations what almost exactly what you said.
> >
> > The path is:
> >
> > VeriSIgn Class 3 Public Primary CA
> > \_ www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 Verisign
> > \_The domain of the sercure server address
>
> Yes, that is an SGC cert (Verisign Global ID). This is starting to
> come back to me. It's actually a Verisign bug. Verisign's
> International CA (the middle CA in the picture) is marked as having
> more capability than the Primary CA which signed it. Old browsers
> didn't care but newer versions of IE show that annoying message.
>
> You can make the message stop appearing in your browser by selecting
> the Public Primary certificate in the Certification Path screen, then
> click "View Certificate", select the "Details" tab, click "Edit
> properties", and select "Enable all purposes for this certificate".
Thanks a lot for this advice. It seems my worries about the security of the
site were unfounded. Your procedure to stop the message appearing worked
perfectly. I can see I need to learn more about certificates. Now I've lost
the original settings for the capability of the Public Primary Certificate.
I'm not going to set them back to how they were the originally but I would
really like them just for the record. I would be really grateful if you or
someone could post them here. For example: Server Authentication ticked.
Code signing not ticked. etc... or however they were originally.
Thanks again,
Tony.
------------------------------
From: Eric Hambuch <[EMAIL PROTECTED]>
Subject: Re: xor algorithm
Date: Mon, 09 Oct 2000 13:01:26 +0200
Antonio Merlo wrote:
>
> How strong will be an encryption method based on a xor operation with a pass
> phrase (or password) an a buffer to encrypt? (suppossed a very strong
> password of, let's say 16 letters, combining uppercase, lowercases and
> digits)
> How will you cryptoanalise that algoritm?
It's called a vigenere cipher and (using a computer in a few secons, by
hand maybe some hours) very easy to break.
A description and a nice Java applet is available at
http://www.trincoll.edu/depts/cpsc/cryptography/vigenere.html
or
http://www.ics.uci.edu/~eppstein/cryptogram/
Eric
------------------------------
From: "Arnold Shore" <[EMAIL PROTECTED]>
Subject: Re: securely returning password info to a server from a client
Date: Mon, 9 Oct 2000 07:34:23 -0400
Won't the encryption provided by an SSL session do what's needed? A
server-side certificate is all that it takes - price somewhere between cheap
and free.
Arnold Shore
Annapolis, MD USA
------------------------------
From: "ink" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Microsoft CAPI's PRNG seeding mechanism
Date: Mon, 9 Oct 2000 13:53:27 +0200
Jack Love dropped into the real world with a crash and proclaimed...
>On Fri, 06 Oct 2000 07:30:18 -0700, JCA <[EMAIL PROTECTED]>
>wrote:
>
>>Pascal JUNOD wrote:
>>
>>> Does someone have any information about it, or do I have to trust
>>> Microsoft about their crypto
>>> capabilities ?
>>>
>>
>> If anything, you would have to adopt the opposite attitude: trust that
>>
>>their crypto capabilities are flawed.
>>
>> MS is well-known for not taking security seriously.
>>
>>
>>
>Windows 2k was recently given a C2 rating.
Only if you don't connect it to a network...
ink
--
There is nothing wrong with Southern California that a rise in
the ocean level wouldn't cure. - Ross MacDonald
------------------------------
From: [EMAIL PROTECTED] (Ross Anderson)
Subject: Re: The talk of R. Moris
Date: 9 Oct 2000 12:26:29 GMT
In article <[EMAIL PROTECTED]>,
Mykhailo Lyubich <[EMAIL PROTECTED]> writes:
>Hi,
>
>does somebody know, where I can obtain a stenography of
>R. Morris talk on Cambridge Protocol Workshop in 1994.
>
>I found the reference to this talk in Ross Anderson, Markus Kuhn
>"Tamper Resistance - a Cautionary Note"
>http://www.cl.cam.ac.uk/users/rja14/tamper.html
>and in Bruce Schneier "Applied Cryptography", second edition on page
>214.
>
>Thank you in advance
>
>--
>Mykhailo Lyubich
>
>
I'm afraid the proceedings didn't get published. The talk was taped
and the tape sent off for transcription, but the workshop chair left
the laboratory to work for a bank and the book just never appeared
Ross
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Rijndael has a very good S-Box
Date: Mon, 09 Oct 2000 12:28:27 GMT
Using a small BASIC program, I searched for differential
characteristics, and linear (well, affine? over GF(2^8), anyhow)
approximations to the S-box.
The differential behavior of the Rijndael S-box is simply astounding.
If you consider S(i) xor S(i xor diff), for all 256 values of i, this
expression will often take on a value zero or two times instead of
once, as is ideal...and may take on one value _four_ times.
That's as strong as any differential characteristic of the S-box gets.
As for linear approximations, things are a bit better for the
cryptanalyst, but not by much.
S(i) is equal to a*i xor b (where the multiplication is done in
GF(2^8)) as many as 13 times out of 256, where a=23 and b=163.
The second best linear approximation *also* occurs for a=23, this time
with b=56; this one is true 11 times.
For a=1 and a=23, there are multiple "approximations" that show up,
and most commonly they are true around 8 times.
The approximation a=147 and b=99 is true 9 times, and the only other
value of b that gives an approximation true more than 4 times is 229,
with a=147 b=229 true 5 times, so this approximation may have less of
a "noise level" to contend with.
On the other hand, if the multiple approximations at either a=1 or
a=23 can be made to work together, to provide a strong linear
approximation - but with _partial information_, something might be
done.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Johnny" <[EMAIL PROTECTED]>
Crossposted-To: alt.security
Subject: SSL/TLS Certificate Request message
Date: Mon, 9 Oct 2000 14:37:46 +0200
Hello!
I am implementing SSL protocol and have problems with server's Certificate
Request.
Does anybody know what should be the format of Distinguished Name within the
above
message? Is it ASN.1/BER encoded DN like within X.509 certificate or simple
plaintext
cn=..., o=..., c=.. Maybe it is something else. Or does MSIE not understand
this
message, because it disconnect upon receiving this message?
Thanks in advance.
Marcin
------------------------------
Subject: Re: Why trust root CAs ?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Mon, 09 Oct 2000 12:42:04 GMT
[EMAIL PROTECTED] (Vernon Schryver) writes:
> There's promise there, but also problems. I've not been keeping up, but
> I understand that one problem is that they've not figured out how to sign
> all of the RR's in .com before it's time to sign them all again. It takes
> time to sign 30,000,000 records with a public key. Another problem is
> that adding signatures make packets on the wire a lot bigger.
DNS does allow for different types of requests with different types of
information returned. for part of the issue, clients can selectively
request keys & signatures (like they do today in SSL). increase of
bits on the wire has got to be significantly less than the current SSL
setup.
--
Anne & Lynn Wheeler | [EMAIL PROTECTED]
http://www.garlic.com/~lynn/
------------------------------
Crossposted-To: alt.security.scramdisk
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Reply-To: [EMAIL PROTECTED]
Date: Mon, 9 Oct 2000 11:35:00 GMT
Anonymous <[EMAIL PROTECTED]> wrote:
: Is there truly ANYONE stupid enough to believe ANY government would
: adopt an encryption standard that DIDN'T have a back door for unlimited
: government access?!?!?!
I believe this. It's quite possible that this has occurred with the US
government and AES.
It will almost certainly happen in the future. It appears that so far in
cryptographic arms races, the cryptographer has a significant advantage
over the cryptanalyst. Government eavsdropping on encrypted traffic is
likely to depend on something other than direct attacks on the cyphertext.
At the moment, computer security is generally so pathetic that the
government can waltz into your computer and wander off with all your
files. Encrypting traffic that travels over the wires won't help
much with this.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Surf against sewage.
------------------------------
Subject: Re: Why trust root CAs ?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Mon, 09 Oct 2000 13:02:34 GMT
Daniel James <[EMAIL PROTECTED]> writes:
> Then, of course, only the bank can verify the signature. I think it's
> important that other parties involved in the transaction can verify the
> customer's signature, and so the full certificate will have to be sent
> with each transaction, and the full certification chain (and revocation
> lists) must be available to all parties. I agree that that adds somewhat
> to the volume of comms trafic for each transaction, but it does buy useful
> security.
the other parties in a retail transaction want to know that the bank
has to say about the financial transaction between the account owner
and the bank. The fact that the other parties even have to see the
transaction is an artifact of the current POS online environment (the
online terminal happens to be at the merchant site). That transaction
flow is likely to remain for some time ... but with all parties having
online capability ... there is nothing to prevent the transaction flow
to reflect the actuality of the parties involved (i.e. the retail
transaction is an instruction from the consumer to their bank, that
other parties even see the transaction is an left-over artifact of the
current world).
Because of an artifact of existing POS online technology ... the other
parties are evesdropping on something between the consumer and the
consumer's financial institution. Institutionalizing that evesdropping
would make it worse. In at least some of the bank card world there are
even association quidelines about the merchant not doing anything more
than certain minimums with the transaction (in part to address privacy
issues).
Furthermore, in the current world, financial institutions tend to want
to see all transactions against their accounts (& not having things
like fraud attempts being truncated).
As stated previously, the merchant wants to know that the consumer's
bank will pay ... the merchant getting a transaction from the
consumer's bank indicating that they will get their money satisfies
that requirement. Institutionalizing all the other parties
evesdropping on consumers' instructions to their financial institution
is also aggrevating privacy issues (i.e. just because an
implementation artifact has other people's messages flowing thru
something that I have access to ... doesn't mean that i should be
monitoring it).
Now, there can be a case that the return transaction from the
financial institution to the merchant be signed and carry a
certificate ... but the current bank->merchant infrastructure ... to
some extent, operates within the bounds of a trusted network
... alliviating much of the authentication requirement that occurs in
an untrusted network environment.
There can also be other transactions that might need authentication,
(and could benefit from public key authentication) but the specific
discussion was about retail transactions where the consumer is sending
directions to their financial institution.
--
Anne & Lynn Wheeler | [EMAIL PROTECTED]
http://www.garlic.com/~lynn/
------------------------------
** 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
******************************
