Cryptography-Digest Digest #78, Volume #13 Thu, 2 Nov 00 18:13:01 EST
Contents:
Re: CHAP security hole question (Vernon Schryver)
Re: Is RSA provably secure under some conditions? (David Wagner)
Re: sqrt correlations ("Douglas A. Gwyn")
Re: RSA MGF (David Hopwood)
srp-1.7.0 released w/TLS Telnet security, X11 forwarding support (Thomas Wu)
Detectable pattern in encoded stegaanographic images ([EMAIL PROTECTED])
Re: Crypto Export Restrictions ("8aked 1c3")
Re: Crypto Export Restrictions ("8aked 1c3")
Re: Is RSA provably secure under some conditions? (Philip MacKenzie)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: CHAP security hole question
Date: 2 Nov 2000 08:45:28 -0700
In article <[EMAIL PROTECTED]>,
Thomas Wu <[EMAIL PROTECTED]> wrote:
> ...
>> That problem is that description applies when a human needs to memorize
>> a single password. Set asside the fact that much authenticating involves
>> two computers, no humans, and so much less need for ideas like EKE and
>> SRP. (Computer can memorize secrets that are immune to dictionary attacks,
>> and nothing can be done to completely protect computers from having their
>> memories opened and their secrets read.)
>
>But as long as humans must authenticate themselves over networks using
>secrets stored in their heads, strong password protocols are useful.
Humans cannot store the many passwords needed to authenticate themselves
over networks, because in the real world they necessily many passwords.
Strong password protocols are largely irrelevant.
>And aren't humans really the ultimate endpoints for all these fancy
>cryptographic technologies?
When was the last time you participated in the CHAP PPP authentication
process? The answer is almost certainly "never." You might have acted
as a very slow network to pass a secret from elsewhere to your computer,
but during the authenticating, you had nothing to do with a process that
happened in milliseconds. If you used a reasonable system, it's quite
possible that you were not even present the last time your computer brought
up its PPP link and authenticated itself. It couldn't have been
authenticating you if you weren't there.
Practically everyone writes down passwords, types them into Windows
configuration dialogues as they're dictated over the phone, or cuts-and-
pastes them from (cleartext!) email. The remainder use text editors to
do the equivalent. Essentially no one knows what password their computers
are using with PPP, BGP, the new DNS authentication, their routers, and
so on.
And then there is HTTPS, where no human knows the secrets that
authenticate the servers and many clients.
Except for the reliability of PC's and the inevitable need to apply
Microsoft Repair Technique #1 (re-install software), there would be
nothing wrong with an installation scheme in which a user
- downloads a program in the usual InstallShield format
- the program chats with the user to collect credit card and
geographic info (to pick a telephone number)
- the program negotiates with the Internet service provider
to pick a long, random password and then jams it into the
Microsoft PPP configuration stash.
In such a scheme, the human user need never know the CHAP secret.
Thus, it is wrong to talk about PPP CHAP authenticating a *human* user.
> ... but once again the aim of
>strong password protocols is to improve network security without further
>inconveniencing the user. While it is not good practice to share passwords
>between sites, for example, some users will do it, and I don't think there's
>a easy way to prevent it.
Someone with no sympathy for SRP could twist those words into "SRP is
intended to encourage users to pick terrible passwrords that even SRP
cannot protect (e.g. human name) and to use the same terrible password
evreywhere." The less twisted might say that protecting poor (instead of
terrible) passwords is a much worse solution than almost eliminating the
problem.
With smartcards you could have dozens of unbreakable passwords with the
same safety and convenience as SRP, EKE, and so forth would allow with a
single password. It's not a minor detail that everyone has enough
different passwords that SRP cannot help.
> If zero-knowledge password protocols are in use,
>however, it makes it that much harder for, say, a rogue admin from one site
>to harvest passwords that he can try elsewhere.
That is true only of really bad authentication protocols, such as cleartext
FTP and Telnet, and stupid rogue admins. Zero-knowledge password protocols
do not matter to rogue system administrators who understand what they are
doing. They do not merely sniff packets to steal passwords.
Memorizing dozens of easy passwords is harder than memorizing a single
good password, and the assumption behind EKE, SRP, and so forth is that
latter is too hard for humans. The human authentication problem involves
proving yourself in many situations to many different others.
Zero-knowledge systems today are worse than cleartext telnet was in its
day. When telnet was created, the reasons that make cleartext passwords
silly did not exist, so that they made sense. The requirements for dozens
of separate passwords irrelevant exist today and make zero-knowledge
password protocols irrelevant at birth for anything but fixing obscure,
archane applications such as rlogin, telnet, and ftp.
In other words, the current reality of dozens of passwords forces people
to write them down. If you're writing them down, you may as well use good
ones, and in that case you don't need zero-knowledge password protocols,
except for things like telnet and ftp, which hardly anyone uses. (I and
probably anyone with a Xenon.Stanford.EDU use them, but we don't count.)
> ...
>When we get cheap, powerful, universal, interoperable, secure smartcards
>into everyone's hands, you might have a point. But that utopia may
>never materialize. Why bet on it?
So it's better to bet on people doing what you know they can't and
won't do, have sufficient distinct passwords and use SRP?
People already have non-portable smartcards in their laptops and even
desktop PC's, not to mention palmtops. There are several Windows
applications for managing passwords. Consider also how you could use the
data sync machinery of a palmtop to make it a fat smartcard.
If PC's did not run such incredibly insecure by design microstupid
operating systems, prudent people could use what might be called a virtual
smartcard. Take the familiar notion of a smartcard that applications talk
to get what's needed for an authentication dance. Modify it to consist
of a program, a well encrypted file, and an intra-host protocol such as
a dynamically loaded library ABI. You wouldn't want to use such thing on
a stranger's computer and perhaps not even on shared computer where bad
guys might arrange to watch the insides of a virtual smartcard. On your
own trojan-free laptop or desktop, that would be more secure and more
convenient than a zero-knowledge protocol system where the user necessarily
consults the sticky-note on the monitor for the right password.
Note that to use SRP, you must also hope to be trojan-free. For example,
you must trust everyone who can affect what runs on your computers,
including those who run NFS servers mounted without NOEXEC or at least
NOSUID.
>> In other words, there are good reasons why zero knowledge schemes have
>> not taken the Internet by storm, ...
>
>Reasons, maybe, but not particularly good ones. I'd attribute it mostly
>to a combination of ignorance and inertia. But even that is changing
>these days.
Consider the dates conveniently provided by your
http://www-cs-students.stanford.edu/~tjw/srp/analysis.html
EKE dates from 1992. SRP finally may solve the telnet and rlogin password
problem, which after all these years is a good thing, but very faint praise.
That SRP, EKE, and so forth do not solve the authentication problems most
of people is not merely ignorance and inertia.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Is RSA provably secure under some conditions?
Date: 2 Nov 2000 22:02:13 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Roger Schlafly wrote:
>Philip MacKenzie wrote:
>> So my point is, I'm not sure why you disparage my use
>> of the word proof. It's a completely accurate description
>> of many results--in a certain model and assuming certain
>> functions are hard to compute, a certain scheme is
>> _provably_ hard to break.
>
>Perhaps you missed by other post, but what bugs me the most is
>not just that you have an unverified hypothesis, but that you
>have an unverifiable hypothesis.
I agree that the distinction is important.
But all proofs are relative to some idealized model (e.g., "the adversary
can only interact with the system in the following ways"), and this too
is an unverifiable hypothesis. There are no guarantees that your model
is the right one, as witnessed by, e.g., timing and power attacks.
So models are one type of unverifiable hypothesis, and the random oracle
model is just one special case of this general phenomenom.
I agree that the random oracle "assumption" should not be compared to
the assumption that factoring is hard; but that doesn't mean that it is
any better or worse than other models.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: sqrt correlations
Date: Thu, 2 Nov 2000 21:06:40 GMT
Benjamin Goldberg wrote:
> Could someone tell me where (on the web) I could find a paper, or
> papers, describing how correlations in the digits of a square root can
> allow an attacker to learn the original number?
Any digit sequence is the square root of *some* number,
so there are no "correlations" in general. Also, given
the square root, simply squaring it gives the original
number. I guess your concern must be for digits starting
somewhere "in the middle". Consider the following:
1.00030002 squared =
1 + .0000009 + .000000000000004 the easy ones
+ .0006 + .00000004 + .00000000012 interactions
It is evident that the digits do not affect anything in
the original number to the left of their position. What
they affect to the right depends on how far to the right
of the decimal (or binary) point the current position is.
One might think of setting up a system of equations for
the next yay many digits (reflecting that in the original
number the sum of all contributions is 0, for integer),
but note that there are an unknown (large) number of
contributions from past (unknown) digits, at unknown
locations (due to not knowing the current position).
I don't know of any mathematics that can harness this
degree of variability. On the other hand, if the domain
from which the original number was selected is small
enough, we can simply search it for a sufficiently long
match to a stretch of the square root digits among the
square roots of all possible original values (carried
out to as many places as might have been used in the
cryptosystem). In practice there would have to be some
indicator for the starting digit position (right of the
decimal point), which would be visible to the
cryptanalyst as well as to the intended recipient.
------------------------------
Date: Thu, 02 Nov 2000 22:34:24 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: RSA MGF
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
> In RFC 2437, a Mask Generation Function is defined for use as encoding
> algorithm. Part of the algorithm is:
>
> For count from 0 to \lceil{l / hLen}\rceil-1 ...
>
> I do not understand the second part of this. What is "lceil"
> and "rceil"?
It means "For count from 0 to ceiling(l / hLen)-1", where
ceiling(x) is the smallest integer >= x.
The \lceil and \rceil are the symbols around l / hLen below:
_ _
| l |
| ---- | - 1
| hLen |
which are another way of writing ceiling(l / hLen)-1. For completeness,
this is how floor(l / hLen)-1 would be written in the same notation:
| l |
| ---- | - 1
|_ hLen _|
- --
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
iQEVAwUBOgDztjkCAxeYt5gVAQGb2Af9GnGFjKsL9eBrvB/+UUbwJ+C0waJbLv4h
FJ+1BLtkmWwXjz9TY4btY9Unrrl7dp/HSJt4aCjbSCgwxFZzMLjQu42LMSTNu1UT
Jly5lrWgG0rnUpBr0UVI02yhQvxGKawrdlocvFDyi/Lje9ck7yMHhdoOkbCIX9Ii
QPhsJWdqhe7JxRrFzKgYOpe3G+5DvWtb0VSMOJuiI/RsL4Frz/cUd9vdKpYZblnD
RYlTMGWS4iMRa1r3jOGLhxSbADsjgiqPzGUgh7R9co3gWBQdBifBrzqT8WY4mrEG
rsxWwyESzg6rxpL9rg+XnpzRE0NDY8KbYw2Vuy6AprCXFOo3W9b3fQ==
=ST+Q
=====END PGP SIGNATURE=====
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Crossposted-To: comp.security.unix,comp.os.linux.security
Subject: srp-1.7.0 released w/TLS Telnet security, X11 forwarding support
Date: 02 Nov 2000 14:37:03 -0800
Version 1.7.0 of the SRP distribution has been released. This is a major
release that contains many new features and bugfixes. From the release
notes:
- New Telnet feature support: SSL/TLS-based session security
(draft-ietf-tn3270e-telnet-tls-05.txt) and X11 session forwarding
(draft-altman-telnet-fwdx-02.txt).
- Secure Telnet authentication with TLS: SRP, Kerberos V5
(draft-altman-rfc2944bis-00.txt and draft-altman-rfc2942bis-00.txt)
- Classic Telnet authentication/encryption modes fully integrated
with new security options; new Telnet clients/servers interoperate
with both old and new Telnet clients/servers.
- Large amounts of code cleanup and portability fixes. Tested on
Linux 2.0/2.2, FreeBSD 4.1.1, Solaris 2.6/7/8, HP-UX 11, AIX.
- Improved PAM support. EPS modules are now automatically configured
and built on supported platforms.
- More streamlined integration with OpenSSL and other crypto libraries.
- Updated documentation.
Support for TLS Telnet security and X forwarding is in alpha, along with
RFC 2941 integration and Kerberos V5 (MIT Release 2.1) support. Testing
(especially interoperability testing) is welcomed and feedback is
encouraged.
http://srp.stanford.edu/
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/
------------------------------
From: [EMAIL PROTECTED]
Subject: Detectable pattern in encoded stegaanographic images
Date: Thu, 02 Nov 2000 22:40:33 GMT
have tried to set up a method of steganographic transmission of images
without suspicious attachments, by placing the file to be
steganographically hidden, within the .bmp of the e-mail stationery .
have used outlook express 5.5, used a .bmp of parchment texture [24
bit] to use as the background stationery, used s-tools 4 to hide a pgp
encrypted message within the background stationery, sent the e-mail
with an innocent cover text, was able to retrieve the .bmp by right-
clicking on the background and saving as a .bmp, and then retrieved the
message using s-tools 4, without any problems.
upon closer examination and comparison of e-mails with the plain
parchment bmp background, and the same background with a textfile
steganographically hidden within the background, found a very clear
pattern in the base 64 encoding {when viewing the 'message source' and
the encoding of the .bmp }, but no obvious patterns in the encoding of
the plain .bmp
is this just something in s-tools 4, or is it a consequence of the
steganographic method showing a pattern between altered pixels and non-
altered pixels.
would be happy to send two sample e-mails for comparison to whoever
would be interested.
thanks in advance,
vedaal
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "8aked 1c3" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Thu, 2 Nov 2000 14:43:34 -0800
> a) Some non-US people are capable of inventing cryptographic techniques
> ***outside*** the USA (gasp!) - I think I'm right in saying RSA falls
> into this category (although my being mistaken on this specific example
> would not disprove the general point). But even if this were false:
> b) The beans spilled out of the can some years ago. Source code in
> electronic form is widely accessible all over the world, for most USA
> cryptographic techniques. But even if this were false:
> d) What makes them think we want their crypto anyway? If they won't let
> us use theirs, we (and I use this word in the general sense - I myself
> am no cryptographer!) are perfectly capable of developing our own, thank
> you. (It has just occurred to me that this is the same point I was
> making in (a) above. Oh well, that's life...)
> Richard Heathfield
OpenBSD (motto is "Exporting Cryptography to the World") is made in Calgary,
Alberta.
8aked 1c3
------------------------------
From: "8aked 1c3" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Thu, 2 Nov 2000 14:45:08 -0800
> If course, the biggest problem is that no explanation is given of where
> the randomness actually comes from. You can mix numbers to get random
> numbers, but you need randomness in order to mix. Where does the initial
> randomness come from? No clue.
>
> DS
I know that Linux's "random" number generator, actually counts the seconds
since the Apoch. (I forget the date of the Apoch)
8aked 1c3
------------------------------
From: Philip MacKenzie <[EMAIL PROTECTED]>
Subject: Re: Is RSA provably secure under some conditions?
Date: Thu, 02 Nov 2000 17:46:44 -0500
Roger Schlafly wrote:
> Perhaps you missed by other post, but what bugs me the most is
> not just that you have an unverified hypothesis, but that you
> have an unverifiable hypothesis.
>
I'm not quite sure what you think my hypothesis is,
but I would say my general hypothesis is: "Assuming the existence
of random oracles seems to be a useful way to do
security analyses, and schemes proven secure in the
random oracle model, and which are implemented using
a hash function like SHA-1 in certain specific ways,
seem to not get broken in the real world."
This hypothesis can be verified, but only empirically.
> Factoring may indeed be hard, in the sense of complexity theory.
> But SHA-1 will never be proved to be a good instantiation of a
> random oracle, because there is no theory that tells us what is
> or is not a good instantiation.
>
> It is not that you have proved something secure under assumptions.
The assumption is "Random oracles exist." I agree it is
not a complexity theoretic assumption, and not something
you can prove (I don't think).
> You have proved it secure in some other universe that may not
> have any relation to the real universe.
I agree. It just _seems to_ have some relation to the
real universe when talking about practical security.
You may argue that there are better ways to get
practical and secure cryptographic schemes, but
at least with random oracle proofs, you won't have
situations like with ISO 9796-1.
-Phil
------------------------------
** 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
******************************
