Cryptography-Digest Digest #266, Volume #14 Sun, 29 Apr 01 22:13:01 EDT
Contents:
Re: DSA in GF(2^W)? ("Sam Simpson")
Re: DSA in GF(2^W)? (those who know me have no need of my name)
Re: GF(2^m) ("Peter L. Montgomery")
Re: Secure Digital Music Initiative cracked? ("Roger Schlafly")
Re: GF(2^m) ("Tom St Denis")
Re: Censorship Threat at Information Hiding Workshop ("Trevor L. Jackson, III")
Re: Secure Digital Music Initiative cracked? ("Trevor L. Jackson, III")
Poor NSS ("Dr. Yongge Wang")
Re: A practical idea to reinforce passwords (David Hopwood)
Re: GF(2^m) ("Eric M")
Re: A practical idea to reinforce passwords (David Hopwood)
Re: A practical idea to reinforce passwords (David Hopwood)
Re: A practical idea to reinforce passwords (David Hopwood)
They seem to know something... Look (bob)
----------------------------------------------------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: DSA in GF(2^W)?
Date: Sun, 29 Apr 2001 23:11:51 +0100
*LOL*
--
Regards,
Sam
http://www.scramdisk.clara.net/
CrapMail Bait <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> CrapMail Bait wrote:
> ^^^^^^^^
>
> My brother likes fixing my netscape settings to bug me. I appologise
> to everyone here. Let me step off and slap him.
>
> JLC
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: DSA in GF(2^W)?
Date: Sun, 29 Apr 2001 22:49:54 -0000
<[EMAIL PROTECTED]> divulged:
>test
please use a test newsgroup next time.
--
okay, have a sig then
------------------------------
From: "Peter L. Montgomery" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,comp.arch.arithmetic
Subject: Re: GF(2^m)
Date: Sun, 29 Apr 2001 22:00:10 GMT
In article <LN%G6.93534$[EMAIL PROTECTED]>
"Tom St Denis" <[EMAIL PROTECTED]> writes:
>I typically implement GF mults via tables or shift/conditional xors.
>How is squaring simple in GF?
If you use a normal basis, squaring is a 1-bit shift.
>From here on I'll assume you use a polynomial basis.
Squaring is linear -- (x + y)^2 = x^2 + y^2.
To square a 26-bit value ABCDEFGHIJKLMNOPQRSTUVWXYZ you need
0A0B0C0D0E0F0G0H0I0J0K0L0M0N0P0Q0R0S0T0U0V0W0X0Y0Z.
You can get this with four look-ups into 256-entry tables
(which square an 8-bit value) or by clever bitwise and
shifting operations.
You still need to reduce this product modulo the minimal
polynomial defining the basis. If the latter polynomial is sparse
(e.g., a trinomial) then the reduction operation takes time
linear in the length of the input. You have an O(m) time
operation for adding or squaring in GF(2^m).
--
The 21st century is starting after 20 centuries complete,
but we say someone is age 21 after 21 years (plus fetus-hood) complete.
[EMAIL PROTECTED] Home: San Rafael, California
Microsoft Research and CWI
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Secure Digital Music Initiative cracked?
Date: Sun, 29 Apr 2001 21:52:01 GMT
"William Hugh Murray" <[EMAIL PROTECTED]> wrote in message
> Napster users are another issue entirely. It is in the nature of music
> that any performance is a shared experience; any performance creates
> "copies." It is in the nature of music that "fair use" includes the
> right to perform and, to a more limited extent, to copy. However, "fair"
> use also includes the right of the authors, performers, and publishers to
> be compensated for their efforts.
I think the issue is one of control more than compensation. Napster has
offered money, but the music label will not accept a Napster at any price.
A reasonable solution to the current conflict would be to require
mandatory licensing of MP3s, with royalties going to authors and
performers. But that is not what the labels want -- they want control
of distribution.
> The most recent instance where the publishers have tried to restrict
> access to copying technology is when they attempted to restrict the
> capability to record broadcasts of video programming on home VHS
> machines. The courts struck that down. ...
There have been others. The RIAA tried to stop the portable MP3
players (that have now become a big fad) and even won in the lower
court, but the RIAA lost big on appeal. Also, Hollywood is suing to
prevent dissemination of the DeCSS code (for accessing DVDs).
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,comp.arch.arithmetic
Subject: Re: GF(2^m)
Date: Sun, 29 Apr 2001 23:10:39 GMT
"Peter L. Montgomery" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <LN%G6.93534$[EMAIL PROTECTED]>
> "Tom St Denis" <[EMAIL PROTECTED]> writes:
>
> >I typically implement GF mults via tables or shift/conditional xors.
> >How is squaring simple in GF?
>
>
> If you use a normal basis, squaring is a 1-bit shift.
> From here on I'll assume you use a polynomial basis.
Sorry I don't get the diff. What I normally use is where something like x^2
+ 1 would be 101_2.
When I flipped thru Mike's ECC book I saw "ONB" too I assume that's
"Optimal" Normal Basis?
Tom
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Censorship Threat at Information Hiding Workshop
Date: Sun, 29 Apr 2001 23:38:22 GMT
Mok-Kong Shen wrote:
> "Douglas A. Gwyn" wrote:
> >
> > David A Molnar wrote:
> > > Can we agree that Felten et. al. are not pirates?
> >
> > Sure, they weren't the one I was replying to.
> > The real crime is not cracking the copy protection scheme.
> > My point was that it is *also* not in using a copy protection scheme.
> > Rather, the real problem here is the theft of content that started
> > the chain of developments.
>
> So Felten et al. are innocent, since they presumably don't
> do any actual theft using their knowledge but the develpment
> of techniques that circumvent the protection seems nonetheless
> to be considered by the industry to be a big crime.
This illustrates at least one of the inconsistencies in the position of the
SDMI consortium. The purpose of the contest was to evaluate the strength
of the technology. The organizers _invited_ people to develop techniques
that circumvent the protection schemes. I suspect that the click-though
agreement does not contain sufficient teeth to legally enjoin the
researchers from publicizing their results. The depth of the pockets of
the those weilding the threats may be daunting, but when someone challenges
the (ahem) "overly broad interpretation" of the agreement I suspect the
challengers will win.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Secure Digital Music Initiative cracked?
Date: Sun, 29 Apr 2001 23:44:10 GMT
Harvey Taylor wrote:
> In article <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]> Marc wrote:
> >
> >> The suppressed paper is online. Read it while you can.
> >
> > Right said. Xerox is trying to remove the paper from the web.
> >
> http://cryptome.org/sdmi-attack.htm
> http://cryptome.org/sdmi-attack02.htm
Was there anything the SDMI could have done that would be more effective
at publicizing the contents of the paper? What fraction of the
conference attendees will not have read it by the conference? Are the
authors enjoined from all speech on the topic? Even if they are, others,
having read the paper, and _not_ executed the contest agreement, will be
free to pursue the topic and publish their results. There's a word for
this technology: /history/.
------------------------------
From: "Dr. Yongge Wang" <[EMAIL PROTECTED]>
Subject: Poor NSS
Date: 29 Apr 2001 23:46:08 GMT
Poor NTRU Signature Scheme is broken again.....
It might still be the case that NTRU encryption scheme
is secure. But this also illustrate that it is quite hard
to desing a signature scheme...
FOr more information, see:
http://www.di.ens.fr/~stern/nss.html
--
========================
Yongge Wang
http://cs.uwm.edu/~wang/
========================
------------------------------
Date: Mon, 30 Apr 2001 01:30:33 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
=====BEGIN PGP SIGNED MESSAGE=====
Harald Korneliussen wrote:
> I've come up with a way to reinforce passphrases
> against brute-force attacks without memorizing longer
> ones. This may already be in use, but I don't think so
> because it should be configurable and I haven't seen
> anything like that... It's really mostly for PGP but
> it is relevant to everywhere passwords are used, so I
> post it here.
> =
> My idea is that upon selecting a password, X bits of
> random data is added to the password. You are not
> informed of what these bits are, nor does the computer
> store them. The computer only stores how many bits
> there are, and brute-forces them every time you enter
> you password.
This is called "key stretching", and is described in:
J. Kelsey, B. Schneier, C. Hall, and D. Wagner
"Secure Applications of Low-Entropy Keys,"
1997 Information Security Workshop (ISW'97), September 1997,
pp. 121-134.
It is a good idea; congratulations for re-inventing it.
Another idea that achieves a similar effect by different means
is "key strengthening", which is intentionally using a
computationally expensive function to derive a key from the
password. A good example of that is the bcrypt scheme described
in:
Niels Provos, David Mazi=E8res,
"A Future-Adaptable Password Scheme,"
Presented at USENIX '99.
http://www.usenix.org/events/usenix99/provos.html
Key stretching has the advantage over key strengthening that the
encryptor does not need to do additional work; only the decryptor
does. OTOH, it isn't always applicable (for example it can't be
used with strong password protocols like SRP, SNAPI, etc., because
in those protocols the password verifier has to be calculated in
advance).
> The reason this is a good idea is: It only adds a few
> bits of security, but it does this at something
> important, something that is the weak link in schemes
> like PGP.
I agree entirely. However, note that OpenPGP already supports
key *strengthening*, in the form of the "iterated and salted"
string-to-key algorithm (see RFC 2440 section 3.6.1.3). That RFC
also says that either the "salted" or "iterated and salted"
algorithm SHOULD be used; IMHO it should be restricted *only* to
"iterated and salted". New versions of PGP should not be using
the other string-to-key algorithms except to decrypt files
created by older versions.
There are far too many applications that use password-based
encryption without any form of key stretching or strengthening,
though :-(. PKCS #12 does not support it, for instance (the earlier
DES-based PKCS #5 password-based encryption standard did, so this
was a retrograde step). Personally I think that it is partly this
kind of poor protocol design, that is keeping the NSA still in
business doing cryptanalysis.
- -- =
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
iQEVAwUBOuyx8zkCAxeYt5gVAQEWqggAgdbmqFMPZ905Sk01CINO569Pa2JlllRI
NH0In35lB5x/C6Bxi3b9lBG/QECXAcZI2Z1ZgwNOZEcuTInX1O9Y9t3V1rfM5Vw3
CdqNlPC89Mf6audrcF+o+8/AyZFPxWhxqQIhta4gLdulVti1MFw7m9ErR0j76SCl
lTVfkc38rt76tUd/K+GfYAhOSOVTSrO2icXGIjhbkDVq8mG9v2Kp7RzkKoUPurQW
GtybYdRfUj7xnhq0yyGQD7E/3d0c7rM0o5EyHwI/VQwhrS/fa0Hr81K/lBEY+ARk
BM7EXsP+bN2UruwNLl8zQb3YneCuzcOmCdoE3HOXTiOr3KbCYKYQCg=3D=3D
=3DYGgt
=====END PGP SIGNATURE=====
------------------------------
From: "Eric M" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,comp.arch.arithmetic
Subject: Re: GF(2^m)
Date: Sun, 29 Apr 2001 21:26:53 -0400
"Peter L. Montgomery" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <9cgomr$7lc$[EMAIL PROTECTED]>
> "Andre" <[EMAIL PROTECTED]> writes (on sci.math):
> >What's the main advantage of Galois Field operation compared to Integer
> >operation?
> >And, how does GF operation use in Cryptosystem?
> >Your regards!
>
> GF(2^m) operations can be implemented without
> worrying about carries. For example, if you want to add
> two elements of GF(2^100) on a 32-bit machine
> (so each operand uses CEIL(100/32) = 4 words),
> you need only four exclusive OR (plus loads and stores).
> Adding two values modulo a 100-bit prime p would require
> one add, three adds with carry. Then you check whether
> the sum is >= p, possibly subtracting p.
> The operation modulo p is about three times as costly.
>
> Many common architectures support 32 x 32 -> 64
> integer multiply (with carries) but few support
> 32 x 32 -> 64 GF multiply. However special-purpose
> hardware for a GF multiply is simpler than for an integer multiply.
> There was a recent sci.crypt series on GF mults.
> The GF(2^m) squaring is simple.
>
> There is only one field of sise GF(2^m).
> If somebody breaks the discrete logarithm problem over GF(2^m),
> you must switch to another size m,
> changing the lengths of many messages.
> If somebody breaks the discrete logarithm problem over GF(p),
> you may be able to use another p of the same size.
It should be emphasized here that if somebody breaks the DLP over GF(p) *for
a particular number p* any system using that value of p will no longer be
secure. This does not preclude one from using a p' that is that the same
length (Floor(ln p') = Floor(ln p)) as p, since the DLP over GF(p') will
require the same precomputation as breaking DLP over GF(p).
------------------------------
Date: Mon, 30 Apr 2001 01:53:39 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
=====BEGIN PGP SIGNED MESSAGE=====
Volker Hetzer wrote:
> Paul Pires wrote:
> > If it only brute forces the added bits, doesen't this mean that
> > the true password is stored on the machine so that when the
> > added bits are correctly guessed, the machine can know to
> > stop? I guess it could check against a hash of the proper
> > password + real bits added.
>
> I don't know how the exact algorithm on Unix works but it's
> probably the password encrypted with itself or so.
If you don't know, why are you speculating? The algorithm is described
at the end of this post.
[...]
> > It seems like your work is multiplied 256 times when you
> > log in where the adversarys is increased 256 * each guess.
> >
> > Isn't this what is called "key stretching"?
>
> Yes.
The method that the OP proposed is key stretching; the method used
by crypt(3) is key strengthening, which is different.
====
This is the "traditional" Unix crypt(3) algorithm, based on DES.
Unfortunately there appears to be no definitive reference for this
algorithm, so it is described below:
A 12-bit salt is used, considered here as an integer between 0
and 4095. The password is represented as a US-ASCII string, and
padded with zeroes up to 8 bytes. Passwords containing non-US-ASCII
characters (with code points >= 128), or that are longer than
8 characters are invalid. (Note that many Unix implementations
silently truncate passwords to 8 characters.)
Each byte of the US-ASCII-encoded, zero-padded password is then
shifted left by one bit, and the result used as a key for a
modified variant of DES. The key is used to encrypt a block of 8
zero bytes, 25 times. The parity of key bytes is ignored.
In standard DES, the output of each expansion permutation is a
block of 48 bits, which are numbered as in FIPS PUB 46-2 (i.e.
from 1 on the left to 48 on the right). Salt bits are numbered
from 1 for the least significant bit, to 12 for the most
significant bit. The modification of DES is that if salt bit i
is set, then bits i and i + 24 are swapped in the DES expansion
permutation (a.k.a. "E-box") output.
The salt and final modified-DES ciphertext are encoded in 13
bytes as follows:
encode(x) =
("./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ" ||
"abcdefghijklmnopqrstuvwxyz")[x]
E_salt(P) = encryption of the 8-byte block P, using DES modified
by the salt.
C = E_salt^25(<0, 0, 0, 0, 0, 0, 0, 0>)
output =
encode(salt & 0x3F) ||
encode(salt >>> 6) ||
encode(C[0] >>> 2) ||
encode(((C[0] << 4) & 0x3F) | (C[1] >>> 2)) ||
encode(((C[1] << 2) & 0x3F) | (C[2] >>> 6)) ||
encode(C[2] & 0x3F) ||
encode(C[3] >>> 2) ||
encode(((C[3] << 4) & 0x3F) | (C[4] >>> 2)) ||
encode(((C[4] << 2) & 0x3F) | (C[5] >>> 6)) ||
encode((C[5] & 0x3F) ||
encode(C[6] >>> 2) ||
encode(((C[6] << 4) & 0x3F) | (C[7] >>> 2)) ||
encode((C[7] << 2) & 0x3F)
where
<< denotes shift left,
>>> denotes unsigned shift right,
|| denotes concatenation,
& denotes bitwise AND,
| denotes bitwise OR.
When verifying an authenticator A, the salt is recovered from
the first two characters of A (least significant 6 bits first):
salt = encode^-1(A[0]) | (encode^-1(A[1]) << 6)
and the authentication succeeds iff the correct output can be
derived from the password and this salt.
Some Unices use variations on this, for example where the salt
is 16 bits, and some use completely different algorithms.
Also see
R. Morris, Ken Thompson,
"Password Security: A Case History",
Communications of the ACM, vol. 22, pp. 594-597, November 1979.
Also in troff format (readable as ASCII) at
http://plan9.bell-labs.com/7thEdMan/vol2/password
Don't use crypt(3) in new protocols, BTW; use bcrypt (referenced in
my other follow-up), or key stretching instead.
- --
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
iQEVAwUBOuy3ZzkCAxeYt5gVAQHZUAf9EcaXOzp5XzdSID0eFXLfBQWwblIH+G//
7+vNfJqW+y/ENm3mOk4EVBkrusjsuFg5qMCE4oHecowPMx2U/MIAXuMcTE1I4+LB
anoj8woE5muO8taO8qVMXiSv7W0JlH3lVBrE5eIO22X1AstKLflUho0TmlkO5iAM
jaNOGET58wyLdivxqVRlLCMrMFtA7fKXmlvT1/foNRLrv6W5dZURqx+QsiC1iguq
kfq7SGpGs1tguEDPn8OgYQsL4w4l+DwI1x6ac4E+mP9s0FQdGajR59eVh7qbs5Ya
hlHBugGJc875rllRNi8SCeU38nN3i2zrTRck1r7PgQJ99fgnr2mbUA==
=Eykf
=====END PGP SIGNATURE=====
------------------------------
Date: Mon, 30 Apr 2001 02:40:17 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
=====BEGIN PGP SIGNED MESSAGE=====
Tom St Denis wrote:
> > Harald Korneliussen wrote:
> > > My idea is that upon selecting a password, X bits of
> > > random data is added to the password. You are not
> > > informed of what these bits are, nor does the computer
> > > store them. The computer only stores how many bits
> > > there are, and brute-forces them every time you enter
> > > you password.
=2E..
> The reason this idea hasn't been done before is because it's stupid.
Sometimes you can give completely clueless and bad advice, Tom.
The rationale for methods that slow down dictionary attacks, such as
key stretching and strengthening, is that regardless of how vigorously
you tell users to choose strong passphrases, they will not always do so,
or they may choose passphrases that are on the edge of being breakable.
Key stretching/strengthening can add ~20 bits to the effective entropy of=
a passphrase, which may make a critical difference to security, bearing
in mind that many people seem to have difficulty remembering phrases
that represent more than about 50 bits of entropy. If the passphrase is
generated by diceware or a similar method, it can safely be made smaller,=
and therefore easier to remember. This is quite different from the case
of symmetric keys, which can be made as long and as random as necessary.
Therefore, one of these methods *should* be used by *all* new protocols
that rely on passphrases, IMHO. Read the Provos/Mazi=E8res paper that I
referenced in my other follow-up.
(Ideally, off-line dictionary attacks should be prevented entirely.
However, that is only possible when you have an separate server that
authenticates the passphrase; it isn't possible when using a passphrase
to protect a locally stored private key or an encrypted disk, for
example. Even when a protocol resistant to off-line dictionary attack
is used, it is still a good idea to employ key strengthening when
computing passphrase verifiers, to slow down dictionary attacks in
the case where the verifier is stolen.)
- -- =
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
iQEVAwUBOuzCdDkCAxeYt5gVAQHX4Qf/QnfNVB0Lsqk3KpIg/mzdavPbNtTKX/Ni
nnPL1t3qX40G0r+fCebeRvANX+FajaN1JTHJKxN1AZpRLXziZ2YkNSkJKiTyDrEK
K9lcN/iE5EKi7mKVRiSl3r3AazQj7WfASXwfH7eXRaxX33miD3BXjGw+L5p4vw+s
LZoTwq8IX2Fg4d0UMsKdE7KtqpRXXy+MSJ/c/EOfBbQaRG7dUOG0f9i7ht4gClVP
wIk6glO2pGKbfRp6XhUDftd2BVi8pTLpc4VU82tzEgjSAKuasmAqBHN6cKSgbtZX
AZ2tj+GieOWsmkxbpsJxPNIeZhX5iVmf83RLaPH55blDz5r7NqOqVQ=3D=3D
=3Dp4iS
=====END PGP SIGNATURE=====
------------------------------
Date: Mon, 30 Apr 2001 03:06:14 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
=====BEGIN PGP SIGNED MESSAGE=====
Paul Crowley wrote:
> Thomas Wu <[EMAIL PROTECTED]> writes:
> > This isn't really a good idea. The problem is, you slow down
> > a legitimate login by the same factor that you slow down an
> > attack. It's easy to come up with slow hashes that make
> > everything slower, the real innovation is with methods that
> > make a brute force attack exponentially harder while having
> > less of an impact on legitimate users, say a linear workfactor
> > difference.
>
> I'm surprised you say this; what he proposes is essentially key
> strengthening, which under some circumstances is a good idea. Of
> course, for network logons key stretching doesn't play well with
> protocols such as your SRP, which is I guess why you're coming out in
> favour of key stretching here. I'm not sure under what circumstances
> strengthening is clearly better than stretching, but it's sometimes at
> least as good.
You have key stretching and strengthening the wrong way round (an
easy mistake to make; I'd have preferred these terms to be more
descriptive). I think you intended to say something like:
| I'm surprised you say this; what he proposes is essentially key
| stretching, which under some circumstances is a good idea. Of
| course, for network logons key stretching doesn't play well with
| protocols such as your SRP, which is I guess why you're coming out in
| favour of key strengthening here. I'm not sure under what circumstances
| stretching is clearly better than strengthening, but it's sometimes at
| least as good.
Stretching is better than strengthening for passphrase-based encryption,
because the encryptor doesn't have to do any extra work. As you say, it
doesn't work with strong password protocols, so in that case strengthening
should be used instead.
If I remember correctly, the reference implementation of SRP does *not*
use strengthening; if the verifier file has been compromised, the cost
of testing a passphrase guess is effectively one modular exponentiation
or elliptic curve multiplication. IMHO those operations are not slow
enough for this to be a good idea. There's nothing about the SRP protocol
that precludes using strengthening, of course.
- --
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
iQEVAwUBOuzHsTkCAxeYt5gVAQHAjggAtv342xGzA4tsTuEENE07NbGpVrqEqxUR
0JwN1iUyaS3orZ41vK2CDeEbhE3Ax2zuN3cbs5AhKHQMv/EhTom7mbQvfYVOe3hn
HJqq3WOSLQ7Yd7tM885xZzwvJySU17hRvNUrdWm0T0las1ve+XGHO4BmzU7hAVAs
Qxf9aVDp5gCiPJ9+EJIt305Z83Ro5CIDdbp4mQ5RgQAIuaj/WkT8S7F01Q3HIvUM
gH/bPY3TfE4XR8DESeml+PWMj6iblxZZ/c912FZgrq1/ukNv4uqFNO9nzUjIAbaM
48f6PWo1DQDQkSp/QiH0OAjRKrddQivjQwmOU4ZaISGcYKx7cHG2ww==
=cQpO
=====END PGP SIGNATURE=====
------------------------------
Subject: They seem to know something... Look
From: [EMAIL PROTECTED] (bob)
Date: Mon, 30 Apr 2001 02:09:44 GMT
This is from the Security Portal Press Releases
http://www.securityportal.com/pr
KERVILLE, TX - The Centers for Sustainable Peace and Development picks
VSpace, Inc. as it's choice for global information security solutions.
VSpace, Inc., an industry leader in global information security and
information warfare has agreed to develop and implement secure computer
systems for the transfer, storage and dissemination of open source
intelligence data for the Center for Sustainable Peace and Development. The
mission of CSPD is in the establishment of global regional centers as a
site for peace negotiations, training in conflict resolution in addition to
readily offering support to humanitarian and disaster relief undertakings.
Model systems have been developed through a research partnership with
American University�s Peace Studies Program and with the cooperation of the
University of Missouri.
�For the first time ever, world-wide legislatures, organizations and
individual activists will have tools and information to use for peacework
equal to or better than that available to the executive branches of
governments.�, comments Director Jones. �We are pleased that VSpace, Inc.
will play an integral role in developing the platforms vital to protecting
the integrity of this data.�
Dr. Jeffrey Byrd, CSO and Vice President of Research and Development for
VSpace, Inc. adds, �� while the task is a monumental undertaking, it is a
worthy challenge to be handled with extreme precision. By providing
specialized modifications to mission-critical systems we already have
operation today, I believe we can deliver what they require.� VSpace, Inc.
will be implementing an intelligent database handling system that will be
protected by a custom version of its proprietary proactive AI-driven
security and encryption technologies.
About VSpace, Inc. (Gov/Mil Code -1TRS5)
VSpace, Inc. is a provider of global security solutions for government,
military, and commercial applications. A recent addition to the commercial
information security field, VSpace, Inc. was formed out of a
merger/acquisition of Colorado-based AMA Web Solutions, LLC. and VSpace
Communications of Michigan, forming a strong contender in the commercial
security arena. The certified professionals at VSpace, Inc. have training
and experience in a wide range of areas including military intelligence,
network and internet security and supports a full staff of engineers,
networking specialists, programmers and mathematicians. For more
information about products and services offered, email:
[EMAIL PROTECTED]
------------------------------
** 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
******************************
