Cryptography-Digest Digest #587, Volume #13 Mon, 29 Jan 01 17:13:00 EST
Contents:
Re: security of cd-rw erasure? ("John Feth")
Re: MIKE - alternative to SPEKE and PAK ("Michael Scott")
Re: A Password Protocol (John Myre)
Re: Primality Test (Bryan Olson)
Re: Primality Test (Bryan Olson)
Re: Recommendations on simplest way to add client/server encryption ("Joseph
Ashwood")
Re: Mr Szopa's encryption (was Why Microsoft's Product Activation ("Joseph Ashwood")
Re: Mr Szopa's encryption (was Why Microsoft's Product Activation Stinks)
("Joseph Ashwood")
Re: How many bits of security can a password give? ("Joseph Ashwood")
Re: How many bits of security can a password give? ("Joseph Ashwood")
Re: Why Microsoft's Product Activation Stinks (Matthew Montchalin)
Re: A Password Protocol ("Lyalc")
Re: Recommendations on simplest way to add client/server encryption (Rob Yampolsky)
Very short redundant serial number ([EMAIL PROTECTED])
Re: A Password Protocol (John Savard)
----------------------------------------------------------------------------
From: "John Feth" <[EMAIL PROTECTED]>
Crossposted-To: alt.comp.periphs.cdr
Subject: Re: security of cd-rw erasure?
Date: 29 Jan 2001 18:45:06 GMT
For CDR's used to store files, I believe that when you delete a file, or
update a file, the writing software simply disables, the address of the
file. In the case of an updated file, a new address is generated.
For CDRW's, I believe the write process heats the recording film in the
presence (or absence) of a magnetic field. The read process
differentiaties between the two write conditions because the bit written in
the presence of the magnetic field rotates the polarization state of the
read beam while the bit written with no magnetic field applied does not
rotate the polarization state. The reflected read beam returns through a
polarizer to a detector which makes the detected intensity of bits written
with a magnetic field appled less than the detected intensity of bits
written with no magnetic field applied.
For both CDR's and CDRW's, it appears that if you really want your previous
use inaccessible, it is best to heat the CD to a molten state so that it
ends up looking like a Salvadore Dali watch.
John Feth
John Savard <[EMAIL PROTECTED]> wrote in article
<[EMAIL PROTECTED]>...
> On 28 Jan 2001 21:53:49 -0800, Paul Rubin <[EMAIL PROTECTED]>
> wrote, in part:
>
> >Anyone know if it's possible to recover any info from a cd-rw disc
> >after it's been reformatted? Is there some way to look at the actual
> >bits under a conventional microscope, or do you need infrared?
>
> >Yeah, this is OT for sci.crypt, but I figure some of the right people to
> >ask might be here.
>
> Right off the top of my head, my guess would be that it is _much_
> easier to do this than it would be to recover, say, previously
> overwritten data from magnetic media (which _is_ possible).
>
> For that matter, the article a friend mentioned to me - about data
> being recoverable as much as ten rewrites ago - was from back in the
> days of IBM 2311 removable disk packs. The much higher densities of
> todays hard drives may mean there is less extra "room" on the media
> for traces of old information.
>
> A dye can be changed from a reflective state to an absorptive one, and
> vice versa, by intense laser beams in CD-Recordable media.
>
> Two things might give away previously recorded data. Possibly the
> previous pattern of dye states might remain along one edge of the
> groove, if there was variation in the alignment of the laser. Also,
> there is the chance there might be slight marks on the polycarbonate
> of the disk itself from the previous writing processes.
>
> Visible light gives a better resolution than infrared, and will likely
> be as effective. But any traces of previous writes will be difficult
> to see.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
>
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: MIKE - alternative to SPEKE and PAK
Date: Mon, 29 Jan 2001 19:38:39 GMT
"Thomas Wu" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Michael Scott" <[EMAIL PROTECTED]> writes:
>
>
> Have you given any thought to how a verifier-based version of MIKE could
> be derived? I can't think of any easy way other than by using the
> existing, patented A- and B- extensions, and these also tend cripple the
> performance of the protocol to below the level of existing verifier-based
> protcols like SRP. MIKE would be much more interesting if an efficient
> alternate verifier-based construction could be found.
>
Yes. In fact MIKE (and I now regret the name, but if your name ends in KE
its hard to resist), seems to support a verifier based SRP-style protocol
very naturally as the password is already in the exponent. Using the
notation of SRP, x=H(s,P), and the verifier stored by Steve v=4^x, then in
your description of SRP (Table 4) replace steps 3, 4 and 5 as follows (p is
a safe prime):-
3. A=3^a.4^x mod p Carol sends A to Steve
4. B=3^b. Steve sends B to Carol.
5. Carol calculates S=B^a. Steve calculates S=(A/v)^b
Then proceed as for SRP. Note that 3 and 4 are both generators of the
(p-1)/2 sub-group for any safe prime.
I suspect a PAK-like proof of security may also be possible here, as MIKE is
very similar to PAK.
Mike Scott
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: A Password Protocol
Date: Mon, 29 Jan 2001 12:42:00 -0700
Both forms of this protocol are vulnerable to an off-line
password guessing attack, requiring only eavesdropping on
the user's communications. It is not necessary to deal
with the "host computer" or the "security computer" at all.
The user's response to the challenge vector is computed
from the challenge vector and the password, and nothing
else. Therefore, a password guess can be confirmed by
duplicating the user's computations.
JM
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Primality Test
Date: Mon, 29 Jan 2001 19:38:54 GMT
John Savard wrote:
> Adam Smith wrote, in part:
> >Any tips on generating 512 bit prime numbers?
>
> Are you making use of certain trivial optimizations, such as making
> sure that you only generate numbers with one of the applicable values
> modulo, say, 210? (210 = 2 * 3 * 5 * 7)
Generating candidates that are odd is easy enough, and
possibly-prime modulo 6 is also short using
candidate = something congruent to 1 mod 6
increment = 4
loop until candidate is prime
candidate = candidate + increment
increment = 6 - increment
But the advantage of avoiding generating such candidates
versus removing them before a Fermat test is negligible. Even
if using trial-division to remove multiples of small primes,
this is an order N^2 optimization to an order N^4 algorithm.
If using a sieve or offset-array, it's an order N
optimization. It speeds up a part of the algorithm that
should take less than one ten-thousandth of the run time
anyway.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Primality Test
Date: Mon, 29 Jan 2001 19:58:48 GMT
Bob Deblier wrote:
> Tom St Denis wrote:
[...]
> > 2. Try dividing by the first 1000 small primes. This rules
> > out about 90% of all numbers you try.
[...]
> Instead of using step 2, you can also do something a little
> smarter and faster, which is take the product of the N first
> primes (greater than 2) and compute the GCD of the that
> number and your prime candidate. If the GCD is 1 the
> candidate passes on to step 3. Anything else means you
> discard it. This way you avoid having to do long divisions
> and test a whole bunch of small primes in one operation.
Have you tested that? The trial-division method gains a
significant advantage from early-stopping. When
trial-dividing, the most effective small primes are the first
ones. Five will divide twenty percent of candidates, while
101 will divide less than one percent. Dividing by each small
candidate is linear time, while the GCD is quadratic.
The real smarter and faster techniques are the sieve and
"offset array". They're not even all that much faster, since
the first Fermat test still dominates the run time.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Recommendations on simplest way to add client/server encryption
Date: Mon, 29 Jan 2001 12:02:29 -0800
Crossposted-To: comp.security.misc
Use OpenSSL, strip out the extras that you don't want. For example you only
need one cipher so strip out everything except 3DES with CBC, you don't need
the private key generation (you can do this sepereately). Just basically
remove everything you don't care about. The result should be rather small.
Joe
"Rob Yampolsky" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi. I'm trying to add encryption to my client/server app, and am
> looking for suggestions as to the easiest way to do it in an 'acceptably
> secure' manner. The client runs on Windows, and the server on Unix
> (AIX or Linux). I'd also like to control whether encryption happens at
> all from the server at connection time. I'm also (somewhat) concerned
> about the code size on the client side. My client app is only 350KB -
> I'd hate to quadruple the size just to get encryption.
>
> So far, I'm looking at OpenSSL and another free library called
> libmcrypt. Libmcrypt seems to provide the same basic encryption
> algorithms without doing the SSL handshake for you. Haven't found any
> good code samples yet, but it sure sounds like SSL makes things more
> complicated. Would it be reasonable to implement a simple handshake for
> key exchange and just do encryption in the app (via libmcrypt)? Or is
> 'simple handshake for key exchange' an oxymoron?
>
> And of course sample code would be greatly appreciated.
>
> Thanks,
> Rob Yampolsky
> [EMAIL PROTECTED]
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Mr Szopa's encryption (was Why Microsoft's Product Activation
Date: Mon, 29 Jan 2001 12:08:41 -0800
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
[We really should remove or.politics and misc.survivalism from this,
actually we need to remove Szopa from this then the others won't matter]
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> The entire theory upon which OAP-L3 is based in published on my web
> site in the Help Files and the software is available.
> Are you trying to assail my encryption theory or my implementation of
> it?
And just as the theory that the earth is flat, we know it to be wrong. Your
handwaving fluff from your website, is useless.
Now as to whether we are attacking your "theory" or your implementation?
Both are grossly wrong, why pick one over the other. Although since you
don't seem to have any "theory" to speak of, I suspect we are basically
after your implementation. If you ever manage to learn what an algorithm is,
that is our primary choice for things to attack.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Mr Szopa's encryption (was Why Microsoft's Product Activation Stinks)
Date: Mon, 29 Jan 2001 12:12:32 -0800
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Can you implement this? Generate all 3,628,800 unique ten digit
> permutations of the digits 0 - 9. This means generate all unique
> sequences of the digits 0 - 9 where there is no digit repeated in
> any one sequence of these ten digits and no ten-digit sequence is
> repeated in all 3,628,800 generated.
Certainly we can, the problem lay in the fact that you rely on the order of
these permutations later, and you do not specify what ordering. Therefore
1/(3,628,800!) attempts will generate the correct sequence, and so a
software engineer can in no way generate this initial step.
All other errors of gross omission are deleted.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: How many bits of security can a password give?
Date: Mon, 29 Jan 2001 12:29:51 -0800
"George Weinberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Wed, 24 Jan 2001 11:50:11 -0800, "Joseph Ashwood" <[EMAIL PROTECTED]>
> >Depends on the password. If you let the user choose an English word, it
is
> >rather predictably 1 bit of entropy per character. If you require that
there
> >be at least one capital, they will almost certainly capitalize the first
> >letter, so maybe .25 bits of entropy added. Adding a number on the end
adds
> >an average of log2(10) although it will be biased towards 1. So your
normal
> >passwords would have anywhere from 6 to ~12 bits of entropy.
>
> This is way pessimistic. 12 bits of entropy implies you could get it
> with a dictionary attack with only 4000 guesses. six bits
> means you would only need 64 guesses!
Actually I need simply refer back to the proofs by, I believe it was,
Shanon. Which proved rather conclusively that English has between 1 and 1.5
bits of entropy per character. Even assuming 2 bits per character (which
would be a much better password than is typical) that is still only 16 bits
or so. These are not wild guesses, these are based on mathematical proofs.
There's some hedgeway here because people tend to choose more obscure words
for passwords, and those words have a higher average entropy. The thing is
if they use English you're not going to get much entropy.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: How many bits of security can a password give?
Date: Mon, 29 Jan 2001 12:32:05 -0800
"Rex Stewart" <[EMAIL PROTECTED]> wrote in message
news:94vg0l$ec9$[EMAIL PROTECTED]...
> passphrazes between 8 and 14 characters
> (the standard advice given nowadays for networks)
That's wrong. That is the lengths expected for passwords, the expected
length for passphrases is in the 20 to 100 character range. That is the
primary reason for moving from passwords to passphrases, it's not simply a
name change.
Joe
------------------------------
From: Matthew Montchalin <[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Mon, 29 Jan 2001 12:40:36 -0800
On Sun, 28 Jan 2001, Anthony Stephen Szopa wrote:
|> I'd say that things are not settled yet.
|> --
|> Some people say what they think will impress you, but ultimately
|> do as they please. If their past shows this, don't expect a
|> change.
|
|I like your sense of humor.
|
|Bill Gates is worth nearly a hundred billion dollars and you can say
|things are not settled yet.
|
|Ha ha ha.
Whom do you mean to sue? Gates or MS? Are you attempting to pierce
the corporate veil? I don't think you can do so here. I doubt
greatly that Gates himself reviewed your algorithm, let alone your
implementation of that algorithm, and let alone embedding that sort
of thing in Windows, as you seem to have alleged. But what the hey,
what if he did? I'm sure you will want to have your chance to prove
that he did.
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: A Password Protocol
Date: Tue, 30 Jan 2001 07:59:17 +1100
Like many password protocols of this form, secure remote user computing is
required, and one-time encrypt/hash keys.
The latter is still easily acheived, without public keys.
Lyal
John Myre wrote in message <[EMAIL PROTECTED]>...
>
>Both forms of this protocol are vulnerable to an off-line
>password guessing attack, requiring only eavesdropping on
>the user's communications. It is not necessary to deal
>with the "host computer" or the "security computer" at all.
>
>The user's response to the challenge vector is computed
>from the challenge vector and the password, and nothing
>else. Therefore, a password guess can be confirmed by
>duplicating the user's computations.
>
>JM
------------------------------
From: Rob Yampolsky <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Recommendations on simplest way to add client/server encryption
Date: Mon, 29 Jan 2001 16:30:08 -0500
If I were to do as you recommend and strip out the private key generation,
presumably I'd be generating the keys on the server. No problem there as far as
library size is concerned.
So, if I have this right, the client would have to request an unencrypted public
key, and then initiate SSL using that key. Or is it not necessary for the
client to know any of the keys - can OpenSSL (securely) exchange all key info
without the app needing to know any of this?
As you can see, I'm pretty sketchy on how this all works, except that (I think)
you want to use public/private key encryption to exchange a symmetrical
encryption key, no?
Hey, wait. You said all I need is 3DES with CBC. That's for symmetrical
encryption, so how do I exchange the symmetrical key in that scenario? And can
OpenSSL even work without a key exchange handshake? I think I have some more
reading to do...
Thanks,
Rob
Joseph Ashwood wrote:
> Use OpenSSL, strip out the extras that you don't want. For example you only
> need one cipher so strip out everything except 3DES with CBC, you don't need
> the private key generation (you can do this sepereately). Just basically
> remove everything you don't care about. The result should be rather small.
> Joe
------------------------------
From: [EMAIL PROTECTED]
Subject: Very short redundant serial number
Date: Mon, 29 Jan 2001 21:26:40 GMT
I know this is borderline faq, but hopefully one of you can help me
out. I need to create a very short list of serial numbers, only 100.
Users will be entering in the number manually on a keypad. I would
like to build in some redundancy so they have a lower chance of
accidently entering the wrong number. Say 2 more digits (4 total).
I've considered a couple of schemes based on previous posts on the
topic, but most of these seem to be geared towards much larger numbers,
and much lower relative redundancy. Can any of you suggest a simple
scheme that will catch the common mistakes like swapped numbers and
digits off by one?
Ken
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: A Password Protocol
Date: Mon, 29 Jan 2001 21:20:02 GMT
On Mon, 29 Jan 2001 12:42:00 -0700, John Myre <[EMAIL PROTECTED]>
wrote, in part:
>Both forms of this protocol are vulnerable to an off-line
>password guessing attack, requiring only eavesdropping on
>the user's communications. It is not necessary to deal
>with the "host computer" or the "security computer" at all.
Yes. Of course, that's obvious; no attempt is made to strengthen the
password through the use of EKE or similar techniques.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
