Cryptography-Digest Digest #620, Volume #9 Sat, 29 May 99 23:13:04 EDT
Contents:
i have an encrypted password file that i want to decrypt, can anyone tell me any
ways of going about it? ("Jim Whitehead")
Re: OTP Problems (Nicol So)
Re: The BRUCE SCHNEIER Tirade (Tim Smith)
Re: The BRUCE SCHNEIER Tirade (Tim Redburn)
RSA theorems--need reminder (Bill Unruh)
Re: Stream Cipher using LFSRs ([EMAIL PROTECTED])
Re: Reasons for controlling encryption (Bill Unruh)
Re: SV: Europe and USA encryption export restrictions (Bill Unruh)
Re: The BRUCE SCHNEIER Tirade (SCOTT19U.ZIP_GUY)
PGP probability of choosing primes? (Bill Unruh)
Re: HushMail -- Free Secure Email ("rosi")
Re: DSA (Digital Signature Standard) and the Schnorr Patents (Bodo Moeller)
Re: PGP probability of choosing primes? (DJohn37050)
Certicom Crypto Whitepapers (DJohn37050)
Re: Micro-tutorial: one-time pads (OTPs) (DJohn37050)
Re: RSA theorems--need reminder (Nicol So)
Re: The BRUCE SCHNEIER Tirade
----------------------------------------------------------------------------
From: "Jim Whitehead" <[EMAIL PROTECTED]>
Subject: i have an encrypted password file that i want to decrypt, can anyone tell me
any ways of going about it?
Date: Sat, 29 May 1999 23:11:57 +0100
i have an encrypted password file that i want to decrypt, can anyone tell me
any ways of going about it?
thanks, [EMAIL PROTECTED]
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: OTP Problems
Date: Sat, 29 May 1999 19:02:45 -0400
Dan wrote:
>
> Bob meets Alice once a month and delivers to her a CD-ROM containing
> 650MB of randomly generated data. Each time Alice and Bob communicate,
> the message of length n is sent, and is prefixed with offset y. Starting
> at offset y, using n bytes, the message is decrypted.
>
> The problems with this are obvious:
>
> i) Anyone duplicating the CD can read messages
> ii) Any overlap in the keys will weaken the process
>
> Ignoring the problems caused by (i), ...
You really shouldn't have to worry about i).
> ... I wouldn't mind trying something of
> the following nature. Instead of prefixing the encrypted message with
> a single offset, prefix it with randomly generated n offsets.
>
> In other words, instead of reading the key sequentially, you use the bytes
> one at a time, in random order. Your 650MB CD is suddenly capable of
> being used for a lot more than 650MB of messages. However, this method
> increases the size of the message being sent by 4 (assuming 32 bit offsets)
> and is also much, much SLOWER.
It's probably more trouble than it is worth. If you don't reuse key
material, you don't have to worry about properties of the plaintexts and
what a priori partial knowledge your adversary may have of them. If
you've decided to give up unconditional secrecy in the first place,
there are better ways of doing things.
Regards,
Nicol
------------------------------
From: [EMAIL PROTECTED] (Tim Smith)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Date: 29 May 1999 16:14:12 -0700
fungus <[EMAIL PROTECTED]> wrote:
>> A true one-time pad is... unusable? Why: because no one has shown how
>> it can be done yet?
>>
>
>Very, very simple.
>
>A one time pad has a key which is a big as the message. If you
>can securely transmit the key to the other party then you obviously
>don't need cryptography - you could just send the message by the
>same route.
The exact same argument applies to conventional cryptography. If you have a
secure channel to transmit the key over, you could transmit the message. Your
argument only applies if for some reason the secure channel does not have
enough bandwidth to transmit the key, and the message is available when the
key is given. Neither of these assumptions is justified.
--Tim Smith
------------------------------
From: [EMAIL PROTECTED] (Tim Redburn)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Date: Sat, 29 May 1999 23:56:42 GMT
On Fri, 28 May 1999 15:10:28 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> Actually Bruce stuck his foot in his mouth. He should now better than to
>spout the BS about a OTP since it is PROVABLE SECURE and Bruce
If you believe that a OTP is generally practical, why would
anyone have a need to use SCOTT19u.zip ?
Any way, isn't the maximum key length of SCOTT19u.zip the
same as the maximum file length it can encrypt ?
In effect, if you want to use SCOTT19U.zip at it's
maximum strength, then you have all the problems of a OTP, ie a huge
key that needs securely transmitting, storing or remembering,
with the added bonus of *provably* less security.
If you disagree with these comments please explain the following:
1. How does someone use scott19u.zip for email communication and
how does this differ, in practical terms, from using a OTP for the
same purpose ?
2. How does someone use scott19u.zip for hard disk file encryption,
and how does this differ, in practical terms, from using a OTP for
the same purpose ?
3. Is there a situation I haven't thought of where scott19u.zip is
practical but a OTP isn't? If there is please describe it.
I presume that because you accept a OTP's provable security,
then you would agree that where practical, a OTP should be used.
Just one final question .......... why use scott19u.zip ?
-Tim.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: RSA theorems--need reminder
Date: 30 May 1999 00:43:23 GMT
was talking with a friend and explaining RSa to him. But for the life
of me I could not remember how to prove that for all numbers c<N, that
c^phi(N) mod N =1
(phi(N) is I think the totient function-- numberof numbers less than N
relatively prime to N, and equals (usually) (p-1)(q-1) if N=pq, p,q
prime.)
In fact I could not remember how to prove that c^(N-1) modN =1 if N is
prime.
Any hints please?
Thanks.
Bill Unruh
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Stream Cipher using LFSRs
Date: Sun, 30 May 1999 00:10:08 GMT
>
> You're right. What I should have said is that the top bit of x always
> matches the top bit of y, when z=1. This gives you the necessary
linear
> relation.
>
Hmm, well I will check that out for larger sizes. The idea is not to
hide the solutions but the solution. There is only one solution and
finding it is not possible (unless you can guess several adjacent
solutions). There might be a linear relation as you have noted.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Reasons for controlling encryption
Date: 30 May 1999 01:10:29 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Pwrk) writes:
>If you were to ban encryption, shouldn't that include everything that alters
>information into a form which cannot be read by those not meant to read it?
>Such as the encoding of cable TV so only those with the decoder box can watch
>it?
>Messages containing credit card info?
You seem to think that the legislators are totally stupid. They would
simply ban all encryption except... and then write a list of those which
are OK. They already do that. Read ITAR or the EAR in the USA. Lots is
exempted from the regulations (including bank transfers, etc)
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: SV: Europe and USA encryption export restrictions
Date: 30 May 1999 01:07:37 GMT
>Nils Zonneveld <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>>
>> Does anyone have a clue why there is still no decent encryption in
>> European browser software? Technically it is a piece of cake to use
>> European based algorithms. There seem to be a lot of political
>> obstructions, that hinder the protection of european consumers.
Because most European browser software is written in the USA. It is
illegal to export ANY encryption from the USa without a license, even if
that encryption was invented in Iraq or Lybia. ANY. Thus it is illegal
to ship browser software to Europe without a license. Licenses are not
granted for anything but weak encryption. Thus, Eurpose needs to design
and make popular browser software of its own, and not keep using US
software like IE or Netscape.
Alternatively get Fortify, which alters Netscape to make
them deliver 128 bit encryption.
www.fortify.net
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Date: Sun, 30 May 1999 02:11:14 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim
Redburn) wrote:
>On Fri, 28 May 1999 15:10:28 GMT, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote:
>
>> Actually Bruce stuck his foot in his mouth. He should now better than to
>>spout the BS about a OTP since it is PROVABLE SECURE and Bruce
>
>If you believe that a OTP is generally practical, why would
>anyone have a need to use SCOTT19u.zip ?
They don't have. As some one once said you only have to die and
pay taxes and there are some who don't even pay taxes/
>
>Any way, isn't the maximum key length of SCOTT19u.zip the
>same as the maximum file length it can encrypt ?
Tim no the maximun length is a function of your virtual memory. On
a 4 meg machine I have encrypted files 8 megs in lenght
>
>In effect, if you want to use SCOTT19U.zip at it's
>maximum strength, then you have all the problems of a OTP, ie a huge
>key that needs securely transmitting, storing or remembering,
>with the added bonus of *provably* less security.
>
Actally if you want to use it at full strength the keyenc.key file is
a little over one meg in size. however there are many ways to send
portions of text that can be use for the key. But as other methods
you still would need some sort of key sequence to use to unlock the
key. IF it becomes comprimised you need a new key.
But it is not a OTP you can use the same key several times
so don't confuse the two.
>If you disagree with these comments please explain the following:
>
>1. How does someone use scott19u.zip for email communication and
> how does this differ, in practical terms, from using a OTP for the
I use it with my son we don't have problem. I encrypt then pkzip the
file so that it gets bigger and mail the file like any other zip file. He
then unzips the file so it gets smaller and then decodes it.
I have not changed keys with hin for at least a year so unlike an OTP
we don't need a new key and we don't need to keep track of where
we are if we where using a long key
>
> same purpose ?
Anwsered above
>
>2. How does someone use scott19u.zip for hard disk file encryption,
> and how does this differ, in practical terms, from using a OTP for
>
> the same purpose ?
You should get the program it only encrypte files so not sure what
you are trying to get at.
>
>3. Is there a situation I haven't thought of where scott19u.zip is
> practical but a OTP isn't? If there is please describe it.
I can't read your mind but if it is very close and narrow it would
be a waste of both our time so say where it can be used and where
it can not. You should have the brains to know when an OTP is best
and when it is not.
>
>I presume that because you accept a OTP's provable security,
>then you would agree that where practical, a OTP should be used.
Yes where practical that is where a OTP should be used. By
defination. I gave examples in other posts that you have read so
no need to repeat them.
>
>Just one final question .......... why use scott19u.zip ?
I suppose the best reason to use scott19u.zip is when one needs to
encrypt files for his self that he does not want some one else to read or
if you have a close friend or two banks for file data being changed it is
quite useful. "the all or nothing feature" insures that if you recevie a file
then you either get the whole thing or none of it. This would be a great
help so mistakes are not made when decoding inferior methods you can
get errors in the middle of files so that one thinks the file is ok. But it is
not. Of course there are other ways to send CRC or checksums but if
your going to encrypt you might as well do at all in one with out adding
extra words for a checksum. Or you could get double confidence add
your checksum in file and use scott19u for the whole thing. Hay if you
don't like it don;t use it.
And as you know every day on this form I jump to say hay this is a good
place to use it. So don't act dumb I am not going to type pages and pages
of stuff
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: PGP probability of choosing primes?
Date: 30 May 1999 00:50:43 GMT
mathamatical question:
As I recall, PGP chooses its primes by choosing a random number of L/2
bits (L is the length of the modulus N) It makes sure it is odd, and
then tests it for primality. If it is not prime, it adds two and tries
again. Now, this would make the selection of primes which follow a long
stretch of non-primes much more likely that a prime with another prime
close by but smaller. (Teh relative probability is proportional to the
number of non-primes between that prime and the immediately smaller
prime). Does anyone know what the distribution of distances between
primes is for numbers of lenth L/2? How much does this weaken PGP? Do
primes which have a large distance from the next smallest prime have any
peculiar features that might make them more susceptible to being
cracked? (The average distance between primes of length L is roughly
ln(L), but what is the distribution?)
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: HushMail -- Free Secure Email
Date: Sat, 29 May 1999 20:40:28 -0400
Dear Terry,
Any info on what scheme(s) used? How it works? Or where I can get
a look at such? Sorry, not good at reading code and lack of math
background. Any 'technical' info in layman's terms would be good.
Thanks
--- (My Signature)
Terry Ritter wrote in message <[EMAIL PROTECTED]>...
>
>Most people on sci.crypt should probably check out the new free
>encrypted email web site:
>
> http://www.hushmail.com/
>
>Encryption is end-to-end and occurs locally by downloading a public
>key Java applet. Source is available. The company is outside the US.
>
>
>If this ends up being practical, it could obsolete PGP in many cases,
>and might change the practical situation for cryptography more than
>any court decision.
>
>Also see the CNET story:
>
> http://www.news.com/News/Item/0,4,36868,00.html?owv
>
>---
>Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
>Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
>Free Encrypted Email www.hushmail.com [EMAIL PROTECTED]
>
------------------------------
From: [EMAIL PROTECTED] (Bodo Moeller)
Crossposted-To: talk.politics.crypto
Subject: Re: DSA (Digital Signature Standard) and the Schnorr Patents
Date: Sun, 30 May 1999 00:56:50 GMT
"Roger Schlafly" <[EMAIL PROTECTED]>:
> Have you looked at the Schnorr patent? It is a patent
> on a very specific interactive smart card identification system. The
> claims don't even mention GAK or encryption, or even signatures.
Of course it doesn't mention GAK or encryption (well, not in the
claims -- encryption is mentioned in the summary), but with the
exception of claim 1, all claims are about signatures. (Real
digital signatures -- not the universally forgeable kind of Schnorr
"signatures" that allegedly is equivalent to DSS :-)
In claim 1, e is a random challenge; but in claim 2 and 3, from which
the further claims are derived, the standard trick to turn
identification schemes into signature schemes is used, namely, compute
e as the hash of the message and some per-signature value.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: PGP probability of choosing primes?
Date: 30 May 1999 02:18:09 GMT
yes, the second in a twin prime will hardly ever get picked, for example.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Certicom Crypto Whitepapers
Date: 30 May 1999 02:25:43 GMT
The web site www.certicom.com has many excellent white papers on crypto and
particularly on elliptic curve.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Micro-tutorial: one-time pads (OTPs)
Date: 30 May 1999 02:22:56 GMT
In reading books about spies during wartime, finding a pad of random looking
numbers on a person is tantamount to an admission of spying. Recall that
during wartime, spies can get shot when captured, as they are not wearing a
uniform.
Don Johnson
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: RSA theorems--need reminder
Date: Sat, 29 May 1999 22:44:19 -0400
Bill Unruh wrote:
>
> was talking with a friend and explaining RSa to him. But for the life
> of me I could not remember how to prove that for all numbers c<N, that
> c^phi(N) mod N =1
> (phi(N) is I think the totient function-- numberof numbers less than N
> relatively prime to N, and equals (usually) (p-1)(q-1) if N=pq, p,q
> prime.)
> In fact I could not remember how to prove that c^(N-1) modN =1 if N is
> prime.
> Any hints please?
Some relevant facts:
1. If N is prime, {1,...,N-1} is a (cyclic) group under multiplication,
of order N-1.
2. Lagrange's theorem says that the order of a subgroup divides the
order of the (super)group. (Let H be a subgroup of G, all cosets aH are
of the same order, and they induce a partition on G)
3. Take any element a of a group G, H = {a, a^2, a^3, ...} is a (cyclic)
subgroup of G.
4. Let o(H) be the order of H, the first o(H) of a, a^2, ... are
distinct, and then the sequence repeats.
5. Therefore a^(o(H)+1) = a.
6. a^o(H) = 1.
7. Let o(G) = c*o(H), where c > 0 is an integer. a^o(G) = a^(c*o(H)) =
1^c = 1, where '1' is the identity element of G.
8. Therefore, if N is prime, for all a in {1,...,N-1}, a^(N-1) = 1 (mod
N).
9. a = 0 is an easy special case.
10. Therefore, Fermat's Little Theorem.
11. The result extends to RSA moduli using the Chinese Remainder
Theorem. (Think of Chinese remaindering as a transform, represent
integers mod N i.t.o. their Chinese remainders. Argue about each
"coordinate" separately.)
Hope that helps.
Nicol
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Date: 30 May 99 02:44:17 GMT
John Kennedy ([EMAIL PROTECTED]) wrote:
: I was responding to the statement:
: "A true one-time pad is provably secure (against certain attacks), but
: is also unusable."
: ...attributed to Schneier.
: It refers to a true one-time pad, not snake oil posing as one.
I will then focus my remarks very specifically on your point.
a) The statement was quoted, and attributed to Bruce Schneier, by someone
producing a cryptographic product which is a stream cipher calling itself
a one-time pad. Hence, my previous replies were based on a view of your
posts as defending the original poster.
b) Strictly speaking, you are right that if Bruce Schneier actually made
the exact statement above, he was mistaken. A one-time pad is not (in all
cases) unusable. There are valid practical applications for it.
c) However, for most applications, the one-time pad is sufficiently
inconvenient that there is no reason to consider it. Especially now that
computers can carry out faultlessly encryption algorithms of enormous
complexity: sufficient complexity as to give a reasonable assurance of
security.
The main problem with the OTP from a practical standpoint is not that it
requires *more* secret key per unit of plaintext transmitted than a
conventional cipher. (And as opposed to a PKC system, which requires
"none": however, some secure contact between parties is still required in
the beginning for authentication.)
Rather, it is that once you use up your last keypad, it is *gone*. So you
have to anticipate the _maximum possible_ requirement for secure
communications _in advance_ with the OTP. This is what makes it highly
problematical for many applications.
John Savard
------------------------------
** 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
******************************
