Cryptography-Digest Digest #448, Volume #13 Wed, 10 Jan 01 01:13:00 EST
Contents:
Re: Password security for file transfer w/o speed loss? (Eric Murray)
Re: Bluetooth security? ("Scott Fluhrer")
Re: Comets, Meteors, and Mitotic Spindles /Mars Life angle ("Scot Mc Pherson")
Re: Comparison of ECDLP vs. DLP (Nicol So)
Re: RSA recoverable signature trick (David Hopwood)
Random oracle proofs (was Re: Comparison of ECDLP vs. DLP) (David Hopwood)
Re: RSA recoverable signature trick (Paul Rubin)
Re: Crypto book with mathematical explanations? ("John A. Malley")
Re: RSA recoverable signature trick (David Hopwood)
Re: Random oracle proofs (was Re: Comparison of ECDLP vs. DLP) (David Wagner)
Re: Comparison of ECDLP vs. DLP (Roger Schlafly)
Re: Random oracle proofs (was Re: Comparison of ECDLP vs. DLP) (Roger Schlafly)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Eric Murray)
Subject: Re: Password security for file transfer w/o speed loss?
Date: 9 Jan 2001 18:03:51 -0800
In article <[EMAIL PROTECTED]>,
Paul Rubin <[EMAIL PROTECTED]> wrote:
>Bob Babcock <[EMAIL PROTECTED]> writes:
>> At my office, we're getting ready to disable telnet and ftp, forcing the use
>> of ssh, sftp, etc. The problem is, sftp and scp seem to be at least 20x
>> slower than ftp, and for some users, this is a big problem. We're only
>> interested in protecting username/password; the files being transferred are
>> not sensitive. What I think we need is a transfer protocol that only
>> encrypts the login info. (I assume it's the encryption overhead that slows
>> things down. The sort of slowdown we're seeing is 5 MB/sec for ftp, 150
>> KB/sec for sftp.)
>
>I wonder what is causing that slowdown. Something is clearly wrong with
>the implementation. Nothing about those protocols should inherently
>slow things down that much.
Yea, unless it's on a _really_ slow/overloaded machine.
I beleive that the default symmetric cipher for ssh is 3DES. Try
switching to RC4.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Bluetooth security?
Date: Tue, 9 Jan 2001 19:31:42 -0800
Panu Hämäläinen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Ingmar Grahn wrote:
>
> > Are there any scientific papers that have been written about Bluetooth
> > security? What I'm looking for is a security/crypto analysis like the
ones
> > that have been done for SSL/TSL or WTLS(WAP security layer)? Any hints
of
> > where I can find this kind of info, preferably on the Internet...?
>
> At least the encryption is based on SAFER+, which was one of the AES
candidates.
> There should be some analysis about the cipher on the AES web site...
No. It encrypts using its own stream cipher, which the documents call E_0.
While it does use SAFER, that is used only for authentication.
--
poncho
------------------------------
From: "Scot Mc Pherson" <[EMAIL PROTECTED]>
Crossposted-To: alt.sci.astro.eclipses,sci.geo.earthquakes
Subject: Re: Comets, Meteors, and Mitotic Spindles /Mars Life angle
Date: Wed, 10 Jan 2001 03:40:15 GMT
> After all, do you see a mars-sized crater on earth from the moon's
> creation?
Actually yes you do...Find a map or globe that displays underwater
terrain...Then look at Australia again....Then come back here and say the
above again....I know you won't =)) I believe the phrase you will come up
with will be something like holy s***
Scot Mc Pherson
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Comparison of ECDLP vs. DLP
Date: Tue, 09 Jan 2001 22:59:51 -0500
Reply-To: see.signature
DJohn37050 wrote:
>
> Some assumptions of the OTP are:
> 1) You can generate true randomness.
> 2) More importantly, you can distribute it ahead of time in sufficient
> quantities.
> 3) You can ensure against reuse and solve sync problems.
The example assumptions you gave are of an entirely different nature
than the intractability assumptions relied on in many published proofs.
The assumptions that you mentioned are essentially about the
correspondence between a mathematical model and the system/situation
being modeled. It is well known, and widely appreciated among people
trained in sciences, that such correspondence cannot be established from
within the mathematical model. As Greg Rose pointed out, these
assumptions affect the realism (and hence relevance) of the mathematical
model, but not the truth of the (mathematical) conclusion.
It is a trivial observation that a mathematical model by its nature
embodies assumptions *about the object being modeled*.
Intractability assumptions, on the other hand, are about *mathematical
statements* with *definite* truth-values. (Whether the statements are
provable or not within the usual axiomatizations of mathematics is a
different question). If an intractability assumption turns out to the
false, the conclusion of the proof becomes vacuous. And because of this,
even if something is shown to be "provably secure" under an assumption
of this sort, the question of its security is still not settled. (I
would argue that it's misleading to call results relying on unproven
assumptions "security proofs". These results are really about entailment
relations among statements, one of which happens to be a security
claim.)
I stand by my assertion that there's no reason why a security proof must
always involve unproven assumptions (of the latter sort).
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
Date: Wed, 10 Jan 2001 03:17:26 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: RSA recoverable signature trick
=====BEGIN PGP SIGNED MESSAGE=====
Mark Currie wrote:
> Years ago someone told be about a trick that you can pull when you want
> to sign a public key of the same bit order.
You cannot securely use the identity function as the encoding method for
RSA signatures anyway, so don't try to do this. There is no getting round
the fact that a secure recoverable signature of a piece of incompressible
data will be longer than the original data (typically by *at least* 2t
bits for a security level of 2^t). PSS-R achieves close to the minimum
expansion for a provably secure method:
Mihir Bellare, Phillip Rogaway,
"The Exact Security of Digital Signatures: How to Sign with RSA and
Rabin,"
http://www-cse.ucsd.edu/users/mihir/papers/exactsigs.html
IEEE P1363a draft version 6 (D6).
http://grouper.ieee.org/groups/1363/P1363a/index.html
PSS-R is unfortunately patented (and unlike the non-recoverable variant
PSS, licensing is not free). Don't use the other standardised method for
RSA signatures with message recovery, ISO/IEC 9796-1, because it is not
secure against chosen-message attacks.
- --
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
iQEUAwUBOlvUDDkCAxeYt5gVAQEFggf4lgLgf8JPOeXBPW85KKXnyKe8m/vZQfoU
wEaTO85FnCv7iH9DVOhdgBylv7Bh/nwJRnQZhTeecMwl9i41lXBvmZ55Pb8CuU4m
WODP/qhL8w3FYtQmxxibDgcTjLolrIngW6L1w/QWkZ3vvD6NBFCk/NNOIpuBNDv6
bneNt9xpGfRNKmRjeN2WA8TRp2WxHBqnoRYw0TnHt7OrqS+nBmvRkmMmk+uto2WI
xDwwxqqwfJsrUcy+IOTdcyjLTpIZyJ6sR81zaoIXoQI3eqFEYHf7qJvPXlzWSJLf
RQQLz9IlyvQsQ6h9ySpVnTCwjK1XWSWIfdtu5mWFYTrOaFH/Ev3M
=g0Qf
=====END PGP SIGNATURE=====
------------------------------
Date: Wed, 10 Jan 2001 04:29:00 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Random oracle proofs (was Re: Comparison of ECDLP vs. DLP)
=====BEGIN PGP SIGNED MESSAGE=====
Jakob Jonsson wrote:
> Proofs in the random oracle model ARE proofs of security, but you may
> have objections against the strength of the proof. The proof tells us
> that if you can break the scheme (forge signatures), then you can
> either invert the underlying verification primitive or find a flaw in
> the hash function.
Actually it does not say that. It says that the scheme is secure in a
restricted attack model where the adversary is not allowed to treat the
hash as anything other than a random oracle.
As an example to show the difference, consider the following Message
Authentication Code:
MAC_K(M) =3D H(K || M)
This is provably secure when H is assumed to be a random oracle.
However, it is well-known to be insecure when H is instantiated as
any Merkle-Damg=E5rd hash function (see Applied Crypto 2nd ed.
Section 18.14, page 458). The attack is that the output of H(K || M)
can be used as the initial chaining variable to find the MAC of a
message that starts with pad(M), where 'pad' is the padding function
for H.
There are several possible ways of interpreting this:
1. SHA-1, SHA-256/384/512, RIPEMD-160, Tiger, and all other
Merkle-Damg=E5rd hash functions are flawed.
2. The random oracle model is flawed.
3. Merkle-Damg=E5rd hashes should not be used to instantiate random
oracles with variable length inputs that are not prefix-free.
4. The random oracle model is inappropriate for modelling symmetric
schemes, because the RO assumption trivially implies most
results about symmetric schemes that we would want to prove (i.e.
we are basically assuming the result).
I would say 3 and 4, but YMMV.
In any case, this shows that there are practical, plausible-looking
schemes (as opposed to artificially constructed ones), that can be
proven secure in the RO model, for which instantiating the random
oracle with any of the commonly used dedicated hash functions
(effectively all of which use the Merkle-Damg=E5rd construction) is not
secure.
> Thus, the security of the whole scheme can be expressed in terms of
> the security of two of its components. Of course, the random oracle
> assumption is a much stronger assumption than the one-wayness assumptio=
n
> on the verification primitive -- as soon as you find even the slightest=
> bias in the outputs from the hash function, the proof will fall apart.
The hash is a *fixed* unkeyed function, so it obviously has non-zero bias=
=2E
The random oracle assumption is not an assumption that it is possible
for a specific hash to satisfy [*]; it is an assumption about what types
of attack need to be considered. I.e. it does not prove anything about
attacks that step outside the model. This is much the same as saying that=
a proof that a cipher is resistant to chosen plaintext attack (under some=
assumptions), does not prove anything about its resistance to chosen
ciphertext attacks.
[*] Actually, collision-resistance and pre-image resistance are not
well-defined standard model assumptions either. For example collision=
s
clearly exist for any given hash, so there exists an adversary
with those collisions written into its program. The definition of
"one-wayness" for a OWF is different from pre-image resistance
precisely to get around this problem (roughly speaking, it may be
possible to find pre-images for a secure OWF, as long as it is not
possible to find "too many" of them).
> In particular, a proof that
> relates the security of the scheme directly to the security of the core=
> primitive would be much better. Yet, a random oracle proof assures us a=
t
> the very least that we don't have to fear attacks like the ones on
> ISO 9796-1 and PKCS #1 v1.5, so such a proof is strictly better than no=
> proof at all of security (i.e., we achieve something). At least IMHO...=
I agree: we do achieve something - security against a subset of possible
attacks. I.e. Roger Shlafly's statement
"Roger Schlafly" <[EMAIL PROTECTED]> wrote:
> DJohn37050 wrote:
> > Any security proof relies on assumptions. I think the proof is rando=
m
> > oracle, which some do not accept.
>
> IOW, no proof at all of security.
is too strong IMHO, but it could certainly be argued that the subset
of attacks that the RO model addresses is not complete enough.
Note that security proofs are always open to this type of criticism,
even in the standard model, so I do not agree with the view that results
in the RO model have to be called arguments rather than proofs.
- -- =
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 0=
1
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 b=
een
seized under the Regulation of Investigatory Powers Act; see www.fipr.org=
/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOlvkgzkCAxeYt5gVAQFrLAgAhggdIi502NC3PYDSCYUra/9CEbeEbado
sIedv8gw0FouviFFqAkmpS2966Gkd08acwM4x3rvQDWC7A5XzahPZSQ4udT7xV2R
VMC4Y2iARDsEzFQaI514FsgItcRirrfPFoEUSXVb/ezHcT/KZUvLWyYSyrjDlWS+
ZU/LIwB9wrNNfIjvZfY1V1AC8Pm1r+qvLRmpnyEYtPpMGKkCs9Qzi25Q0rQSqVZH
SnDTn9I5iFRa2sV2OhA775JMJ/nndf0EBX3aCT+//reJ1BmuY+6rLGYdc1IuUYJ+
VRtYhSG+jzf9GAsMidmx5jV4MaRRiFfigozop6UxEI8c3UA7e2Cc/A=3D=3D
=3DSsxB
=====END PGP SIGNATURE=====
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: RSA recoverable signature trick
Date: 09 Jan 2001 20:47:36 -0800
David Hopwood <[EMAIL PROTECTED]> writes:
> You cannot securely use the identity function as the encoding method for
> RSA signatures anyway, so don't try to do this. There is no getting round
> the fact that a secure recoverable signature of a piece of incompressible
> data will be longer than the original data (typically by *at least* 2t
> bits for a security level of 2^t). PSS-R achieves close to the minimum
> expansion for a provably secure method:
What if you just take the thing you want to sign and encrypt it
(reversibly) with your favorite block cipher, using a known fixed key?
That should scramble the bits up pretty well, i.e. getting any
exploitable properties out of the ciphertext amounts to a break for
the block cipher. Am I missing something?
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Crypto book with mathematical explanations?
Date: Tue, 09 Jan 2001 21:03:39 -0800
M.S. Bob gave three good suggestions for texts covering cryptography
from a strongly mathematical view-point.
Please also consider "Decrypted Secrets, Methods and Maxims of
Cryptology" by F.L. Bauer, ISBN 3-540-6041809.
The first half of Mr. Bauer's book addresses cryptography. He presents
the best (IMHO) explanation in print of the mathematical foundation of
cryptosystems. The second half of his book addresses cryptanalysis.
Again, you'll find the best condensed, encapsulated explanation in print
(IMHO) of the basic methods of cryptanalysis.
Every cryptosystem fits somewhere in the mathematical framework Mr.
Bauer describes in "Decrypted Secrets."
Prof. Stinson's and Prof. Koblitz's books delve deeper into the
mathematics specific to the implementations of post-WWII asymmetric and
symmetric key cryptosystems and secure hashes and signature schemes -
and both are must-haves for your library.
"Decrypted Secrets" gives us a sweeping view of the cryptography <->
cryptanalysis "dialectic."
John A. Malley
[EMAIL PROTECTED]
------------------------------
Date: Wed, 10 Jan 2001 05:15:05 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: RSA recoverable signature trick
=====BEGIN PGP SIGNED MESSAGE=====
Paul Rubin wrote:
> David Hopwood <[EMAIL PROTECTED]> writes:
> > You cannot securely use the identity function as the encoding method for
> > RSA signatures anyway, so don't try to do this. There is no getting round
> > the fact that a secure recoverable signature of a piece of incompressible
> > data will be longer than the original data (typically by *at least* 2t
> > bits for a security level of 2^t). PSS-R achieves close to the minimum
> > expansion for a provably secure method:
>
> What if you just take the thing you want to sign and encrypt it
> (reversibly) with your favorite block cipher, using a known fixed key?
That may allow existential forgeries (i.e. the attacker can find
a value that satisfies the verification equation, then reverse it using
the block cipher). Existential forgeries can be quite serious if the data
might be interpreted by a program (which will not be able to see that
the data is gibberish and reject it on that basis), rather than as
text by a human user.
- --
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
iQEVAwUBOlvvpDkCAxeYt5gVAQFj5ggAsE6ZmGJtdtGcoBBXoDMEcBTyvMwu7x5h
SIRD0wAOH0QfaanuvmHC8H6zdE7PWTrhirvj6uMgsPDLcD1lwwBEOGAkezQfQE1N
QzbhkAEpjeNxUkxUIE6I0gUYKSf376YM7hY4QZPl1k+Lb2GprL4TfBkwPNPzVWQ7
SxJd4kRTReElQYpzBqcynclRhAnjUDWCz5PIUgYMcaZtnfMJDlK0tHraP8G5C5IJ
YSmguGB9NSjIejS+M93OO/ZXk5f+rH5T1+6JgamdMWEgp5n9yJDUfjnybN/WMjGe
f4AipSrRLfZbw0gtb+phy2qWUGbzcCqC+NKIy9BZKIW+6a3TS73o6Q==
=FWkh
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Random oracle proofs (was Re: Comparison of ECDLP vs. DLP)
Date: 10 Jan 2001 05:51:59 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
David Hopwood wrote:
>Jakob Jonsson wrote:
>> Proofs in the random oracle model ARE proofs of security, but you may
>> have objections against the strength of the proof. The proof tells us
>> that if you can break the scheme (forge signatures), then you can
>> either invert the underlying verification primitive or find a flaw in
>> the hash function.
>
>Actually it does not say that. It says that the scheme is secure in a
>restricted attack model where the adversary is not allowed to treat the
>hash as anything other than a random oracle.
>
>As an example to show the difference, consider the following Message
>Authentication Code:
>
> MAC_K(M) = H(K || M)
>
>This is provably secure when H is assumed to be a random oracle.
>However, it is well-known to be insecure when H is instantiated as
>any Merkle-Damgård hash function
Yes. And, this is a flaw in all Merkle-Damgard hash functions!
(I think you chose a bad example.)
It is a small enough flaw that it does not bite us in the butt very
frequently in practice. On top of that, most of our candidates have this
flaw. Maybe this is why we put up with it. Or maybe there is no excuse;
maybe we should know better. Yet, in any case, it is still a flaw.
I believe there are ways to build a hash function that does not have
this flaw. (I'm inclined to suggest H(x) = SHA1(SHA1(x)), but suggesting
things off the top of my head is asking for trouble, so you should take
this with a mountain of salt.)
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Comparison of ECDLP vs. DLP
Date: Tue, 09 Jan 2001 21:56:04 -0800
Nicol So wrote:
> Intractability assumptions, on the other hand, are about *mathematical
> statements* with *definite* truth-values. (Whether the statements are
> provable or not within the usual axiomatizations of mathematics is a
> different question). If an intractability assumption turns out to the
> false, the conclusion of the proof becomes vacuous. And because of this,
> even if something is shown to be "provably secure" under an assumption
> of this sort, the question of its security is still not settled. (I
> would argue that it's misleading to call results relying on unproven
> assumptions "security proofs". These results are really about entailment
> relations among statements, one of which happens to be a security
> claim.)
>
> I stand by my assertion that there's no reason why a security proof must
> always involve unproven assumptions (of the latter sort).
You're right. Claiming a security proof (when you don't have one)
is like padding a resume. The main argument that it is ok is that
everyone does it.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Random oracle proofs (was Re: Comparison of ECDLP vs. DLP)
Date: Tue, 09 Jan 2001 21:59:46 -0800
David Hopwood wrote:
> In any case, this shows that there are practical, plausible-looking
> schemes (as opposed to artificially constructed ones), that can be
> proven secure in the RO model, for which instantiating the random
> oracle with any of the commonly used dedicated hash functions
> (effectively all of which use the Merkle-Damgård construction) is not
> secure.
Yes. Nice explanation (of which I snipped most).
> I agree: we do achieve something - security against a subset of possible
> attacks. I.e. Roger Shlafly's statement
> "Roger Schlafly" <[EMAIL PROTECTED]> wrote:
> > DJohn37050 wrote:
> > > Any security proof relies on assumptions. I think the proof is random
> > > oracle, which some do not accept.
> >
> > IOW, no proof at all of security.
>
> is too strong IMHO, but it could certainly be argued that the subset
> of attacks that the RO model addresses is not complete enough.
These RO arguments can be interpreted as strong argument that
certain kinds of attacks will fail. I grant that. The RO arguments
are not worthless. Just overstated.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
