Cryptography-Digest Digest #67, Volume #9 Wed, 10 Feb 99 23:13:04 EST
Contents:
Re: SRP: several questions/ideas (Thomas Wu)
Re: Intel's description of the Pentium III serial number ("Paul A. Jacobi")
Re: simple challenge protocol (Thomas Wu)
Re: Questions about pseudoprimes, testing primes (mathematical) (Ted Kaliszewski)
Looking for papers/info on PIN number security (Dean Povey)
Re: Two simple questions about RSA (Scott Fluhrer)
Re: Clarification on PGP. pls (fungus)
Re: Clarification on PGP. pls ("Wm. Toldt")
Re: Entropy and SHA1 (Nicko van Someren)
Re: GPL'ed RNG (Nicko van Someren)
Positions Vacant (Yi Mu)
Positions vacant (Yi Mu)
----------------------------------------------------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: SRP: several questions/ideas
Date: 10 Feb 1999 15:00:54 -0800
[EMAIL PROTECTED] writes:
> hello, I'm considering using SRP (http://srp.stanford.edu/srp) for
> authentication (and key exchange?) in a program I'm designing. Any
> comments on the following questions?...
>
> Question: can the server's public value g^b be fixed without impacting
> on security? The SRP specification calls B (the server's public
Not in the way you're suggesting. If clients know that g^b is fixed,
then a client can initiate a session, get v+g^b, compute g^b, snoop
someone else's connection to get v'+g^b (v' == someone else's v), and
do a dictionary attack against their password. This happens with
nearly all auth protocols - the server has to randomize its response
to the client to thwart replays, if nothing else.
> value, v+g^b) a "public ephemeral value". But Diffie-Hellman can be
> used with non-ephemeral values (eg in SKIP, or putting your public
> value in an X.509 certificate, as SSL supports). There are two parts
> to this question, really:
> a) is there any reason for revealing v+g^b, but not g^b?
> b) would it be okay if g^b was fixed (probably obtained from a
> certificate) instead of randomly generated each session?
a) is explained in the paper, and the answer to b) is "no".
> Question: what is the purpose of u, called the "random scrambling
> parameter" in the specs? What vulnerability does it prevent and/or
> how does it make the protocol more secure? Would being able to choose
> a value for u (instead of using a random one) weaken the security?
This is also explained in the paper. u thwarts the "inverted verifier
attack", where an attacker who has the verifier gains access to the
host. Read section 3.2.4.
> would it introduce a vulnerability if the user generated this value
> instead of the server? If randomness is important, the user could
> "prove" that the number is not a "constructed" one, by sending a value
> w to the server and using u = hash(w), instead of simply sending u.
Doesn't matter. The absolute requirement is that the user must not
know u until after he has sent his initial message A. Any protocol
in which the user generates u all by himself won't work.
> Question: what is the purpose of the salt? It's quite annoying <grin>
> how the user has to download it from the server each time the SRP
> handshake is used. Does it need a high degree on entropy? If the
> only requirement is that most users have a different salt, then would
> it be acceptable to use the username itself as the salt?
The reference implementations of SRP use both the username and a
random 80-bit salt. You can do away with the 80-bit explicit salt
if it simplifies your protocol - eliding it doesn't break anything.
> Wondering what all these questions are in aid of? Well, if g^b is
> known before hand, the salt can be obtained from the username instead
> of having to ask the server, and "u" can be supplied by the user
> rather than the server, then the server's first response in the
> protocol is completely unnecessary.
Ripping out that message, in any protocol, makes it by definition
vulnerable to a replay attack unless you want to deal with timestamps
or other out-of-band communication. No authentication protocol can help
you there!
> Unfortunately, it turns out that this is actually of very little help.
> It still take three messages to verify the user, because they still
> have to prove they know the shared key, S. I probably won't be able
> to use these ideas in my program, especially if (when :) someone
> points out security flaws in the ideas. In any case, I'm still very
> interested in the answers to these questions.
>
> Thankyou to anyone who read down this far! :) and TIA.
Just use SRP as originally specified either in the paper or according
to Internet-Draft <draft-wu-srp-auth-02.txt>. You'll learn very quickly
in this business that optimizing secure protocols is something that should
be undertaken *very* delicately.
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "The pen may be mightier than the sword, but my
Phone: (650) 723-1565 mouse can crash Windows with one click."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: "Paul A. Jacobi" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.intel
Subject: Re: Intel's description of the Pentium III serial number
Date: Wed, 10 Feb 1999 18:42:11 -0500
Terje Mathisen wrote:
>
> CPUID is a user-mode instruction, as well as the documented way to
> serialize the cpu instruction stream from user code.
>
> I.e. there's no way Intel could make this a ring 0 opcode.
>
Oh, and what happens on a multi-CPU system?
I suppose your user-mode thread would get the CPUID of whatever random
CPU happens to be executing the thread! That's probably going to cause
lots of problems. I'm sure somebody will write code assuming that a
system has one unique CPU serial number, which will break on multi-CPU
system that have multiple CPU serial numbers.
To get consistent CPU serial number on a multiple CPU system, you need
to force your thread to execute on a particular CPU, such as always
CPU #0. Is this something that is easy to do in Windows NT?
Alternative, the O.S. could store the CPUID in memory during the boot
process on CPU #0, then alway use the in-memory copy of the CPU serial
number instead of the special instruction.
+---------------------------------------------------------------------+
| Paul A. Jacobi Phone: (603) 884-1948 |
| Compaq Computer Corporation FAX : (603) 884-0189 |
| OpenVMS Systems Group, ZKO3-4/U14 Email: [EMAIL PROTECTED] |
| 110 Spitbrook Road |
| Nashua, NH 03062-2698 |
| |
| To reply, remove "nospam-" from the return address. |
+---------------------------------------------------------------------+
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: simple challenge protocol
Date: 10 Feb 1999 15:04:44 -0800
Cameron <[EMAIL PROTECTED]> writes:
> The server does not have to store the plain-text password, it can in
> fact store a one-way has of the password so long as the same one-way
> hash is used by the client. Put simply when the client uses the
> password k in the hash function in step 3 before including it with c and
> r it first passes it through another hash function, preferably not the
> same one used in the protocol for communications between the client and
> the server, and then includes it in the final hash sent to the server.
> This means that the server need only store the hash of the password and
> not the plain-text version.
Unfortunately, even if the server stores h(k) instead of plaintext k,
if an attacker compromises the server and steals h(k) they now have
instant access to the user's account. h(k) becomes "plaintext-equivalent"
to the password k, even if it is not a plaintext string. That's what I
believe the original poster was afraid of.
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "The pen may be mightier than the sword, but my
Phone: (650) 723-1565 mouse can crash Windows with one click."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: Ted Kaliszewski <[EMAIL PROTECTED]>
Subject: Re: Questions about pseudoprimes, testing primes (mathematical)
Date: Wed, 10 Feb 99 19:53:05 -0500
Let me assure you that having a modulus that is a pseudoprime, especially
a strong pseudoprime, does not impart any security to the system at all!
I have easily factored 513-bit modulus that was a strong pseudoprime and
posted results in this forum. If you are interested in finding how it is
done send yor e-mail directly to me at [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Dean Povey)
Subject: Looking for papers/info on PIN number security
Date: 11 Feb 1999 00:07:17 GMT
Hi all,
I am looking for any papers/info which examines distributions of 4 digit PIN
numbers which are chosen by the user. I am sure such a beast must exist
somewhere :-)
Thanks in advance.
--
Dean Povey, | e-m: [EMAIL PROTECTED] | Cryptozilla:
Research Scientist | ph: +61 7 3864 5120 | www.cryptozilla.org/
Security Unit, DSTC | fax: +61 7 3864 1282 | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ | oscar.dstc.qut.edu.au/
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: Two simple questions about RSA
Date: Thu, 11 Feb 1999 01:10:57 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Rubin) wrote:
>In article <79rmn8$1d3$[EMAIL PROTECTED]>,
>Gustavo <[EMAIL PROTECTED]> wrote:
>>Hallo everyone.
>>A couple of questions about RSA:
>>1. On many books it is shown that, given the key pair (d,e),
>> the modulus n=pq and a message m, RSA works thanks to the Euler
>> theorem, provided that (m,n)=1. What if (m,n)!=1 (i.e. p or q
>> divide m)?
>
>If (m,n)!= 1 then (m,n) = p or q, so you have accidentally guessed
>a factor of n. Needless to say the chance of this happening by
>accident is very low, for large n :). So you just don't worry
>about that possibility.
Actually, RSA works in that case as well -- encryption and decryption
work as advertised. So, as long as the attacker isn't wasting his
time computing gcd(n,m) for intercepted messages m, you don't have to
worry about that at all :-)
>
>>2. What if the modulus n has more than two prime factors
>> (apart from the obvious fact that factoring is easier)?
>
>You have to compute phi(n) differently, that's all.
Well, you do have to make sure that n is 'square-free', that is,
isn't divisible by p**2 for any prime p. If it isn't, you will not
be able to decrypt messages which are a multiple of p. Other than
that, you're right.
--
poncho
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Clarification on PGP. pls
Date: Thu, 11 Feb 1999 13:06:36 +0100
"Wm. Toldt" wrote:
>
> I said I could "factor large primes" and you posted a composite number.
> Composite numbers are much harder to factor than prime numbers.
I would have said it was the other way round - in my experience, prime
numbers are among the most difficult numbers to factor.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: "Wm. Toldt" <[EMAIL PROTECTED]>
Subject: Re: Clarification on PGP. pls
Date: Wed, 10 Feb 1999 16:15:31 -1000
Michael Kjorling wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I bet you're thinking of trial divisions or something:)
>
> The problem is not the algorithm, it is the time required to execute the
> algorithm with cryptographically good input. Try to factor (2^256-3)/2, it'll
> take a while, but it isn't impossible (I've got the factors many lines down if
> you want them...)
>
> For those who's interested, the number I want you to factor is:
> 57896044618658097711785492504343953926634992332820282019728792003956564819966
> //Michael
>
> On Wed, 10 Feb 1999 01:33:52 -1000, "Wm. Toldt" <[EMAIL PROTECTED]> wrote:
>
> >There is a way to factor large primes which I am willing to divulge to
> >you. Once you see how it is done, you will wonder why you did not think
> >of it by yourself. If you want the secret, just ask for it here.
I said I could "factor large primes" and you posted a composite number.
Composite numbers are much harder to factor than prime numbers. I charge
up front for composite numbers. If you post a prime number, I will factor
it for you for free. It will take less than 36 hours to factor using
pencil and paper. I will also reveal the algorithm, if you ask real nice
like.
Wm. Toldt
------------------------------
From: Nicko van Someren <[EMAIL PROTECTED]>
Subject: Re: Entropy and SHA1
Date: Wed, 10 Feb 1999 21:38:08 -0500
[EMAIL PROTECTED] wrote:
> Since compression does not lose entropy
> and since hashing does. Is it not the usually case that when
> working with files that are compressable one should get a
> more random result when hashing occurs after compression
If the hash function is good then the compression of the input
should make little difference to the entropy of the output.
If the input file has an entropy of X then a losslessly compressed
version of the file should also have an entropy of X. If the hash
function is good, which I will for the moment assume SHA1 is,
then if X is less than the output size then the entropy of the output
should be X (since we hope collisions are rare). If X is more than
the output size then the entropy of the hash output will, we hope,
be the same as the output size. It clearly can not be more and
assuming the output is fairly randomly distributed it should not be
any less except when X is close to the output size. The mapping
between input entropy X and output entropy Y for a good hash
function with an output size of S should be very close to
Y = min(X,S) but I expect in practice the knee in the graph is
rounded off a little (due to collisions).
> I thought you that were a little brighter than tht dim
> wit Hmalton but maybe I was wrong.
I'm not sure you server either yourself or this group well by
slinging insults.
Nicko
------------------------------
From: Nicko van Someren <[EMAIL PROTECTED]>
Subject: Re: GPL'ed RNG
Date: Wed, 10 Feb 1999 21:41:03 -0500
Patrick Juola wrote:
> In article <[EMAIL PROTECTED]>, Wm. Toldt <[EMAIL PROTECTED]> wrote:
> >Do the letters GNU stand for some words?
>
> "GNU's Not Unix."
>
> The MIT-ers are fond of "recursive acronyms."
Like the "MIT Institute of Technology" :-)
Nicko
------------------------------
From: [EMAIL PROTECTED] (Yi Mu)
Subject: Positions Vacant
Date: 11 Feb 1999 03:09:57 GMT
******************************
The following positions are available in the School of Computing and
Information Technology, University of Western Sydney, Nepean.
SENIOR LECTURER IN SYSTEM AND NETWORK SECURITY (tenurable)
Vacancy Reference No. 15/99
Salary : $58,715 - $67,704 per annum - Level C (increasing to $62,825 -
$72,443 per annum from 18 April 1999)
Applications are invited for a Senior Lecturership position in the School
of Computing and IT in the area of system and Network Security.
The research interests in this area include Network Security, Security
Protocols, Distributed Systems and Applications Security, Database
Security, Formal Modelling of Secure Systems, Mobile Security and Secure
Electronic Commerce. This is an important area of research in the School.
The School of Computing and IT is responsible for computing programs at
Bachelors, Masters and PhD level at both the Penrith and Parramatta
campuses of the University of Western Sydney, Nepean. The School is
equipped with modern laboratories and is one of the largest schools of the
University.
The successful applicant should have research competence and experience in
the area of secure systems. The candidate is expected to be actively
involved in the research activities, organise and teach courses in
undergraduate and postgraduate programs, supervise honours and postgraduate
research projects and take part in administrative activities.
Position enquiries to: Professor Vijay Varadharajan, Chair of School
Phone: +61 2 9685 9097 or email:
[EMAIL PROTECTED]
Detailed job description,person specification and application form are
available from:
Elizabeth Reyes
Human Resources Officer, UWSN
Phone: +61 2 9685 9029 or email: [EMAIL PROTECTED]
****************************************************************************
LECTURER IN SYSTEM AND NETWORK SECURITY (tenurable)
Vacancy Reference No. 14/99
Salary : $47,932 - $56,919 per annum - Level B (increasing to $51,287 -
$60,903 per annum from 18 April 1999)
Applications are invited for a Lecturership position at the School of
Computing and IT in the area of Networking. The networking areas of
interest include internetworking, broadband integrated networks, network
architectures and protocols, wireless networks and networking services and
management. The School conducts research in network security, distributed
computing, network management, information systems, knowledge based systems
and neural networks and software applications.
The School of Computing and IT is responsible for computing programs at
Bachelors, Masters and PhD level at both the Penrith and Parramatta
campuses of the University of Western Sydney, Nepean.
The successful applicant is expected to be actively involved in research,
to organise and teach courses in undergraduate and postgraduate programs,
supervise honours and postgraduate research projects and take part in
administrative activities.
Position enquiries to: Professor Vijay Varadharajan, Chair of School
Phone: +61 2 9685 9097 or email:
[EMAIL PROTECTED]
Detailed job description,person specification and application form are
available from:
Elizabeth Reyes
Human Resources Officer, UWSN
Phone: +61 2 9685 9029 or email: [EMAIL PROTECTED]
Equality of employment opportunity and a smoke free work environment are
University policies.
--
===
Yi MU
------------------------------
From: [EMAIL PROTECTED] (Yi Mu)
Subject: Positions vacant
Date: 11 Feb 1999 03:16:09 GMT
******************************
The following positions are available in the School of Computing and
Information Technology, University of Western Sydney, Nepean.
SENIOR LECTURER IN SYSTEM AND NETWORK SECURITY (tenurable)
Vacancy Reference No. 15/99
Salary : $58,715 - $67,704 per annum - Level C (increasing to $62,825 -
$72,443 per annum from 18 April 1999)
Applications are invited for a Senior Lecturership position in the School
of Computing and IT in the area of system and Network Security.
The research interests in this area include Network Security, Security
Protocols, Distributed Systems and Applications Security, Database
Security, Formal Modelling of Secure Systems, Mobile Security and Secure
Electronic Commerce. This is an important area of research in the School.
The School of Computing and IT is responsible for computing programs at
Bachelors, Masters and PhD level at both the Penrith and Parramatta
campuses of the University of Western Sydney, Nepean. The School is
equipped with modern laboratories and is one of the largest schools of the
University.
The successful applicant should have research competence and experience in
the area of secure systems. The candidate is expected to be actively
involved in the research activities, organise and teach courses in
undergraduate and postgraduate programs, supervise honours and postgraduate
research projects and take part in administrative activities.
Position enquiries to: Professor Vijay Varadharajan, Chair of School
Phone: +61 2 9685 9097 or email:
[EMAIL PROTECTED]
Detailed job description,person specification and application form are
available from:
Elizabeth Reyes
Human Resources Officer, UWSN
Phone: +61 2 9685 9029 or email: [EMAIL PROTECTED]
****************************************************************************
LECTURER IN SYSTEM AND NETWORK SECURITY (tenurable)
Vacancy Reference No. 14/99
Salary : $47,932 - $56,919 per annum - Level B (increasing to $51,287 -
$60,903 per annum from 18 April 1999)
Applications are invited for a Lecturership position at the School of
Computing and IT in the area of Networking. The networking areas of
interest include internetworking, broadband integrated networks, network
architectures and protocols, wireless networks and networking services and
management. The School conducts research in network security, distributed
computing, network management, information systems, knowledge based systems
and neural networks and software applications.
The School of Computing and IT is responsible for computing programs at
Bachelors, Masters and PhD level at both the Penrith and Parramatta
campuses of the University of Western Sydney, Nepean.
The successful applicant is expected to be actively involved in research,
to organise and teach courses in undergraduate and postgraduate programs,
supervise honours and postgraduate research projects and take part in
administrative activities.
Position enquiries to: Professor Vijay Varadharajan, Chair of School
Phone: +61 2 9685 9097 or email:
[EMAIL PROTECTED]
Detailed job description,person specification and application form are
available from:
Elizabeth Reyes
Human Resources Officer, UWSN
Phone: +61 2 9685 9029 or email: [EMAIL PROTECTED]
Equality of employment opportunity and a smoke free work environment are
University policies.
******************************
The following positions are available in the School of Computing and
Information Technology, University of Western Sydney, Nepean.
SENIOR LECTURER IN SYSTEM AND NETWORK SECURITY (tenurable)
Vacancy Reference No. 15/99
Salary : $58,715 - $67,704 per annum - Level C (increasing to $62,825 -
$72,443 per annum from 18 April 1999)
Applications are invited for a Senior Lecturership position in the School
of Computing and IT in the area of system and Network Security.
The research interests in this area include Network Security, Security
Protocols, Distributed Systems and Applications Security, Database
Security, Formal Modelling of Secure Systems, Mobile Security and Secure
Electronic Commerce. This is an important area of research in the School.
The School of Computing and IT is responsible for computing programs at
Bachelors, Masters and PhD level at both the Penrith and Parramatta
campuses of the University of Western Sydney, Nepean. The School is
equipped with modern laboratories and is one of the largest schools of the
University.
The successful applicant should have research competence and experience in
the area of secure systems. The candidate is expected to be actively
involved in the research activities, organise and teach courses in
undergraduate and postgraduate programs, supervise honours and postgraduate
research projects and take part in administrative activities.
Position enquiries to: Professor Vijay Varadharajan, Chair of School
Phone: +61 2 9685 9097 or email:
[EMAIL PROTECTED]
Detailed job description,person specification and application form are
available from:
Elizabeth Reyes
Human Resources Officer, UWSN
Phone: +61 2 9685 9029 or email: [EMAIL PROTECTED]
****************************************************************************
LECTURER IN SYSTEM AND NETWORK SECURITY (tenurable)
Vacancy Reference No. 14/99
Salary : $47,932 - $56,919 per annum - Level B (increasing to $51,287 -
$60,903 per annum from 18 April 1999)
Applications are invited for a Lecturership position at the School of
Computing and IT in the area of Networking. The networking areas of
interest include internetworking, broadband integrated networks, network
architectures and protocols, wireless networks and networking services and
management. The School conducts research in network security, distributed
computing, network management, information systems, knowledge based systems
and neural networks and software applications.
The School of Computing and IT is responsible for computing programs at
Bachelors, Masters and PhD level at both the Penrith and Parramatta
campuses of the University of Western Sydney, Nepean.
The successful applicant is expected to be actively involved in research,
to organise and teach courses in undergraduate and postgraduate programs,
supervise honours and postgraduate research projects and take part in
administrative activities.
Position enquiries to: Professor Vijay Varadharajan, Chair of School
Phone: +61 2 9685 9097 or email:
[EMAIL PROTECTED]
Detailed job description,person specification and application form are
available from:
Elizabeth Reyes
Human Resources Officer, UWSN
Phone: +61 2 9685 9029 or email: [EMAIL PROTECTED]
Equality of employment opportunity and a smoke free work environment are
University policies.
------------------------------
** 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
******************************
