Cryptography-Digest Digest #4, Volume #10 Sat, 7 Aug 99 07:13:03 EDT
Contents:
Re: frequency of prime numbers? (Bob Silverman)
Re: What is "the best" file cryptography program out there? (Jerry Coffin)
Re: Canadian Crypto (Eric Lee Green)
Re: Constants in hash functions (Jerry Coffin)
Re: OTP export controlled? (wtshaw)
Re: Americans abroad/Encryption rules? (wtshaw)
Re: Americans abroad/Encryption rules? (wtshaw)
Re: CFB mode with same initialization vector (John Savard)
Re: Americans abroad/Encryption rules? (Serge Paccalin)
Re: Looking for GSM Authentication Algorithm A3 (Marcello Ferri)
Re: Americans abroad/Encryption rules? (Serge Paccalin)
Re: What is "the best" file cryptography program out there? ("Thomas J. Boschloo")
Re: : I AM CAVING IN TO JA... ("Thomas J. Boschloo")
----------------------------------------------------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: frequency of prime numbers?
Date: Sat, 07 Aug 1999 02:49:59 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> John Savard wrote:
> > Actually, you see, IF our previous list contained all the primes, then
> > our new number would indeed, by not being divisible by any of them,
> > satisfy the _definition_ of a prime number, not being divisible by any
> > prime smaller than itself.
>
> Exactly right. Bob S protested too quickly this time.
>
No, I did not. Allow me to try to elucidate. Here is the original
quote:
"There's an infinite number of them, and an easy proof.� Suppose the number
were finite.� Then we can take the product of all the primes and add one to
it.� This number is not evenly divisible by any of the primes, since the
remainder modulo each prime is 1.� Therefore this number is also prime, which
contradicts our assumption that we could enumerate all of them.� Hence the
assumption is false and the number of primes is infinite."
We are all in agreement that the premises lead to a contradiction.
The issue is the nature of the contradiction. The original claim
was that the product plus one "is also prime". It is then backed
up by the argument at the top:
" Actually, you see, IF our previous list contained all the primes, then
our new number would indeed, by not being divisible by any of them,
satisfy the _definition_ of a prime number, not being divisible by any
prime smaller than itself."
However allow me to note that since we have assumed a finite set
of positive integers that the product of all the elements plus one is
larger than every element of that set and hence is not in that set.
Yet we assumed that this set is the entire set of primes. Since the
new element is not in that set, it must be composite, not prime.
That is to say the new number satisfies the definition of a composite
number because it is clearly not a unit and lies outside the set of primes.
So the argument at the top says it must be prime, yet this argument
says it must be composite. This is yet another way of reaching a
contradiction.
The only correct statement is that the new number may be prime
or it may be composite. If it is prime then it is a prime not in our
presumed complete set of primes. ---> contradiction. If it is
composite it must be divisible by primes not lying in out presumed
complete set of primes and again we get a contradiction.
But to just state *only* that the new number must be prime hence we
get a contradiction is wrong because it fails to consider all
possibilities. You can't just say "the new number is prime, hence
contradiction"
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: What is "the best" file cryptography program out there?
Date: Fri, 6 Aug 1999 21:00:22 -0600
In article <7offpu$obg$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> You have to remember that 'special' chip designs don't work against
> algorithms like Blowfish which require alot of key material.
IMO, "don't work" is rather poor wording. It may be more difficult to
design chips for breaking Blowfish than, say, DES, but that doesn't
mean it can't be done.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Canadian Crypto
Date: Fri, 06 Aug 1999 22:12:19 -0700
Winner wrote:
>
> > For example, a Canadian firm can sell an encryption DLL that can be
> > linked into many applications. In the US, the agency insists on
> > tightly coupled crypto and forbids the use of DLL. ("Crypto with a
> > hole" is the term.) I was with a US firm who was looking at being a
> > reseller of the Canadian firm's capability and we couldn't do it. The
> > US is clearly at a disadvantage in the marketplace.
>
> Can you tell us the agency's name that did not allow use of DLLs and
> can you tell us why?
Probably the Commerce Department, which currently oversees export
licensing for crypto products. (Actually, "in coordination with the NSA
and other defense agencies", i.e., probably the NSA calls the shots).
One of the requirements for exportable crypto is that the product cannot
be used in such a way that the crypto parts can be a general
encrypt/decrypt widget. Since the DLL could be linked against to create
other products that did encryption, it was a no-no.
I'm basically trying to figure out for my self what the NSA (through its
Commerce Department patsies) will allow to be exported. At the moment it
appears that they will only allow RSA for the authentication portion of
the protocol, and will only allow DES with a low rate for the encryption
portion. Blowfish need not apply.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Constants in hash functions
Date: Fri, 6 Aug 1999 21:43:29 -0600
In article <7ofm29$sve$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> I've noticed in some hash functions that some constants are declared.
> My question is why? Why can't these be values generated from the
> plaintext being hashed? Are they necessary?
Generally, they're picked for specific properties. Just for example,
SHA-1 uses a number of constants to do its job. The four main
constants in SHA-1 are all derived from the square roots of numbers
multiplied by a large enough number to make the digits approximately
fill a 32-bit integer. The square root of an integer is either an
integer or a transcendental number; all of these are (of course) of
the latter variety, which helps eliminate patterns and such.
If you base _everything_ in the output on the input, it becomes
relatively difficult to deal with things like an input of all zeros
without producing an output that's pretty obvious -- most of the basic
operations on all-zero inputs produce either all-zero or all-one bit
outputs. If you start with that, you'll generally end up with a LOT
of extra work to produce an output that isn't pretty easy to relate
back to the input.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: OTP export controlled?
Date: Fri, 06 Aug 1999 23:50:19 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] (wtshaw) wrote:
> >> The OTP system, as compared to DES/IDEA/skipjack/AES candidates,
> >> that cannot have any internal weakness, that could be exploited....
> >
> >Yep, its weaknesses are all external, and vulnerable by simple means.
>
> I really think that you are too negative, here. I would estimate
> that most undergraduate students would manage to build and run
> an OTP in a secure way, using our development kit. I have thought
> that I may include a two-time-pad program - but in sci.crypt,
> there is a continuous discussion, emphasising that no OTP could ever
> be used more than once. I currently do not have the energy to
> introduce that system.
> Bo D�mstedt
> Chief Cryptographer
> Protego Information AB
> Malmoe,Sweden
Of course, one would have to call such a thing other than a OTP.
Aw, shucks! I figure with the AES crowd doing all this work to give the
world safe cryptography, the last thing you would need to do is worry that
the outcome would not satisfy your every little need. So, you should have
lots of time on your handand have lots of boundless energy just waiting to
be harnessed...but we know different, don't we?
I surely know how to do some of what you talk about, and have the tools in
lab form to demonstrate the techniques, but I'm awfully busy being
compulsive at building lots of these dumb little new cute ciphers of mine.
--
Sometimes you have to punt, and hope for the best.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Americans abroad/Encryption rules?
Date: Sat, 07 Aug 1999 00:23:51 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> Serge Paccalin wrote:
> > - You DO need to learn a secret to decode ROT-N (namely, the value of
> > N), so ROT-N is encryption. The algorithm is weak (frequencies...) and
> > the key is laughably short (< 5 bits), but that's another matter...
>
> For messages of very modest length, you don't need to learn
> a secret to decode the ROT-N message.
Like half a dozen characters or so in lots of cases.
--
Sometimes you have to punt, and hope for the best.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Americans abroad/Encryption rules?
Date: Sat, 07 Aug 1999 00:22:21 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> Maybe I'm biased because I'm French and can refer to laws of my
> country, but the French law draws that line on whether you need a
> secret info to decode or not:
>
> - You don't need to learn a secret to "UUdecode" so UUEncode is not
> encryption.
What if you modify UU somehow so that the software to do the job is known,
but just not readily available. You could even write a few thousand RFC's
with slight differences, but, unless the software was in play, timely
results would take some effort to obtain, surely not when the problem of
decrypting first came up.
So, is being secret enough, or is being readily available also an
important factor.
>
> - You don't need to learn a secret to decode ROT-13, so ROT-13 is not
> encryption, either.
>
Tell it to the judge and see what he says. I doubt than many even
understand what ROT13 is. Of course, the little function I use makes 13
the default key, but can be overridden by one of the other choices. It
would seem that using a default key is not sufficient to deny something is
encryption, but if it were, I could post lots of interesting crippled
algorithms.
Then, one could even clearly label ciphertext as something other than what
it was. You could for instance label something as PGP, but have it be
something else. Hey, that sounds like a useful utility: Just take one of
my algorithms that outputs in the same set as PGP, and format it the same
way too.
--
Sometimes you have to punt, and hope for the best.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: CFB mode with same initialization vector
Date: Tue, 03 Aug 1999 20:34:13 GMT
[EMAIL PROTECTED] (Daniel Vogelheim) wrote, in
part:
>why is encryption in CFB mode insecure, if you use the same
>initialization vector multiple times?
Well, CFB mode takes the IV, encrypts it, and XORs it with the first
block of your message.
So, if you use the same initialization vector multiple times, you are
sending multiple messages - which may have different beginnings - with
the same thing XORed to their first blocks. This is like using a
one-time pad twice, and can be solved by the same method, without
having to break the DES (or other block cipher) encryption at all.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Serge Paccalin)
Subject: Re: Americans abroad/Encryption rules?
Date: Sat, 7 Aug 1999 10:06:20 +0200
Reply-To: [EMAIL PROTECTED]
On/le Sat, 07 Aug 1999 00:22:21 -0600,
wtshaw <[EMAIL PROTECTED]> wrote/a �crit...
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> >
> > Maybe I'm biased because I'm French and can refer to laws of my
> > country, but the French law draws that line on whether you need a
> > secret info to decode or not:
> >
> > - You don't need to learn a secret to "UUdecode" so UUEncode is not
> > encryption.
>
> What if you modify UU somehow so that the software to do the job is known,
> but just not readily available. You could even write a few thousand RFC's
> with slight differences, but, unless the software was in play, timely
> results would take some effort to obtain, surely not when the problem of
> decrypting first came up.
If the software is not readily available, how can you export it in the
first place? ;-)
I'm not sure about what you mean about "thousand RFC's with slight
differences".
If you mean: "the software is very complicated and needs thousands of
documents to be described fully", it's irrelevent; it's fully
described and there is no secret, period.
It you mean: "there are thousands of variants, you need one of them
and you must dig thousands of documents before finding the right one",
then you have encryption (I'm talking about French law, remember). The
secret is the applicable RFC's numbers. I think French law tries to
avoid workarounds like these.
> So, is being secret enough, or is being readily available also an
> important factor.
Having to know a secret is enough. And I repeat, it has to be readily
available to be of use, anyway.
> > - You don't need to learn a secret to decode ROT-13, so ROT-13 is not
> > encryption, either.
> >
> Tell it to the judge and see what he says. I doubt than many even
> understand what ROT13 is. Of course, the little function I use makes 13
> the default key, but can be overridden by one of the other choices. It
> would seem that using a default key is not sufficient to deny something is
> encryption, but if it were, I could post lots of interesting crippled
> algorithms.
If 13 is a mere default that can be overriden, I won't call the
algorithm ROT-13, but ROT-N, and it's encryption. All my point is
there.
Computer illiteracy among judges is another problem (not only in the
USA...).
> Then, one could even clearly label ciphertext as something other than what
> it was. You could for instance label something as PGP, but have it be
> something else. Hey, that sounds like a useful utility: Just take one of
> my algorithms that outputs in the same set as PGP, and format it the same
> way too.
Something like the following, for instance?
=====BEGIN PGP MESSAGE=====
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>
Npghnyyl, guvf vf abg n CTC zrffntr ohg n EBG-13 rapbqrq fragrapr.
=====END PGP MESSAGE=====
How will you decode the message above? You will try a list of
algorithms you know. That's cryptanalysis. Or you will try several
keys for each algorithm. that's brute-force cracking.
How can you cryptanalyse or brute-force crack something that is not
encryption?
--
___________
_/ _ \_`_`_`_) Serge PACCALIN
\ \_L_) [EMAIL PROTECTED]
-'(__) L'hypoth�se la plus �labor�e ne saurait remplacer
_/___(_) la r�alit� la plus bancale. -- San Antonio
------------------------------
From: Marcello Ferri <[EMAIL PROTECTED]>
Subject: Re: Looking for GSM Authentication Algorithm A3
Date: 7 Aug 1999 08:17:31 GMT
This is a multipart message in MIME format
--15114842
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message by Eugeniusz Bodo <[EMAIL PROTECTED]> on: 05/08/99
>
>> A3 is used to calculate a result using a 128 bit "random" number,
>> generated by the network, and a shared secret. If the results match, you
>> may proceed. The SIM contains both the secret and the A3 function.
>>
>> Since only the random excitation and the result need be transferred in
>> the network, A3 can be anything. It is meant to be a trapdoor function
>> that the operators may choose themselves, and need not publish it. The
>> A8 function, used to generate session keys, is operator-dependent in the
>> same way.
>
>Do you know anything about A5?
>
> Eugeniusz
Look at: www.scard.org/gsm/
Bye !
Marcello.
--15114842
Content-Type: text/html
Content-Transfer-Encoding: Quoted-Printable
<html>
<BASEFONT FACE=3D"MS Sans Serif" COLOR=3D#000000>
<p></p>
<p></p>
<p><FONT SIZE=3D2>Message by Eugeniusz Bodo=
<[EMAIL PROTECTED]> on: 05/08/99</FONT></p>
<p>></p>
<p><FONT SIZE=3D2>>> A3 is used to calculate a result using a=
128 bit "random" number,</FONT></p>
<p><FONT SIZE=3D2>>> generated by the network, and a shared=
secret. If the results match, you</FONT></p>
<p><FONT SIZE=3D2>>> may proceed. The SIM contains both the=
secret and the A3 function.</FONT></p>
<p><FONT SIZE=3D2>>> </FONT></p>
<p><FONT SIZE=3D2>>> Since only the random excitation and the=
result need be transferred in</FONT></p>
<p><FONT SIZE=3D2>>> the network, A3 can be anything. It is=
meant to be a trapdoor function</FONT></p>
<p><FONT SIZE=3D2>>> that the operators may choose=
themselves, and need not publish it. The</FONT></p>
<p><FONT SIZE=3D2>>> A8 function, used to generate session=
keys, is operator-dependent in the</FONT></p>
<p><FONT SIZE=3D2>>> same way.</FONT></p>
<p><FONT SIZE=3D2>></FONT></p>
<p><FONT SIZE=3D2>>Do you know anything about A5?</FONT></p>
<p><FONT SIZE=3D2>></FONT></p>
<p><FONT SIZE=3D2>>Eugeniusz</FONT></p>
<p></p>
<p></p>
<p></p>
<p><FONT SIZE=3D2>Look at: www.scard.org/gsm/</FONT></p>
<p></p>
<p><FONT SIZE=3D2>Bye !</FONT></p>
<p><FONT SIZE=3D2>Marcello.</FONT></p>
</html>
--15114842--
------------------------------
From: [EMAIL PROTECTED] (Serge Paccalin)
Subject: Re: Americans abroad/Encryption rules?
Date: Sat, 7 Aug 1999 09:41:20 +0200
Reply-To: [EMAIL PROTECTED]
On/le Fri, 6 Aug 1999 22:23:07 GMT,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote/a �crit...
> Serge Paccalin wrote:
> > - You DO need to learn a secret to decode ROT-N (namely, the value of
> > N), so ROT-N is encryption. The algorithm is weak (frequencies...) and
> > the key is laughably short (< 5 bits), but that's another matter...
>
> For messages of very modest length, you don't need to learn
> a secret to decode the ROT-N message.
Because ROT-N is weak; technically you crack the message, just like
the EFF's DES-cracker can retrieve a DES-encrypted message without
knowing the DES key beforehand.
--
___________
_/ _ \_`_`_`_) Serge PACCALIN
\ \_L_) [EMAIL PROTECTED]
-'(__) L'hypoth�se la plus �labor�e ne saurait remplacer
_/___(_) la r�alit� la plus bancale. -- San Antonio
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: What is "the best" file cryptography program out there?
Date: Sat, 07 Aug 1999 11:55:29 +0200
KidMo84 wrote:
>
> I feel that with new advances in technowledgy, there will be processors out
> there that will be be able to run at 5000mhz+ in the next 20-30 years. So
> though with the processing speed now it might take 485 years to crack an 80bit
> key, in the future with faster processors, and maby special computers just made
> to crack these high bit algorithms brute force, it will greatly reduce time.
And you could scale up your hardware, letting the new 5000 Mhz computer
continue where your current computer will be in 20-30 years. (Well, I
think 5000 Mhz will be reached in about five years for Intel like
processors, so call me an optimist).
So basically, assuming you buy a new computer every year to continue the
search, you would need a formula like:
keyspace / (speedin1999 * 1 year + speedin2000 * 1 year + speedin2001 *
1 year + etc. )
If you applied Moores law (every 18 months computers get twice as fast)
the formula would be something like:
keyspace / (speed * 18 months + 2 * speed * 18 months + 4 * speed * 18
months + ... + 2^n * 18 months )
Here you buy a new computer every 18 months that is twice as fast as its
predecessor. Speed is the current day speed of your computer. And n is
the number of years that you spend searching the key space.
Other things to take into account are that not only computers get twice
as fast, but also twice as small. So if you ran things in parallel, you
could possibly gain an extra factor two every eighteen months.
In other words, calculations like cracking a 128 bit key would take
8,984,715,530,573,906 years doesn't impress me at all!! I just want to
know where Moores law stops, and physics kick in like "A computer will
never be faster then the time light takes to cross the diameter of an
atom" or "A computer will never be larger than the biggest planets in
our solar system combine". Things like that. And I wouldn't mind being
off by a factor 1,000,000 because that would only be 20 bits.
So what can our future accendency crack (underbound) and what can they
not crack? 80 bits and 192??? I am interested in this because I might
one day decide to write software with a fixed keysize, that will be
secure for ever (if no weaknesses are found by then).
Thanks for replying,
Thomas
--
Buy an AMD K6-III <http://www.bigbrotherinside.com/#help>
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: : I AM CAVING IN TO JA...
Date: Sat, 07 Aug 1999 11:49:19 +0200
"SCOTT19U.ZIP_GUY" wrote:
>
> >Javascript seems like a bad choice.
> ><http://www.w3.org/Security/Faq/wwwsf7.html#Q64> You will force users to
> >enable a dangeous 'feature' in their browsers, possibly resulting in
> >installed trojans that can defeat the whole security of scottu19.zip!
> >Better stick with standard HTML (don't know which version). Support the
> >Anybrowser Campaign! <http://www.anybrowser.org/campaign/>
> >
>
> Again I see someone bitching that has not even been to my site
> lately. I am sorry I felt compelled to keep up with all the sites that
> say "sorry but you must have Java nad/or JavaScript enabled" even
> though there seems to be no dam reason for it.
I am a user of Netscape 4.5, and as you could have read in
<http://www.w3.org/Security/Faq/wwwsf7.html#Q64> it has a bug that would
allow the website to read arbitrary files from my system.
> Ability to Read Arbitrary Files on User's Machine (November 1998)
>
> A bug in the JavaScript implementation in Netscape Communicator 4.5 and
> 4.04-4.05 allows a Web page to read arbitrary files from the user's
> machine and transmitted across the Internet. Any file that can be read
> with the user's permissions is vulnerable, including the system password
> file. The bug affects both Windows and Unix versions of Communicator.
> Any HTML page can carry this exploit, including ones that are
> transmitted as an e-mail enclosure. Internet Explorer has not been
> reported to be vulnerable.
>
> See http://www.geocities.com/ResearchTriangle/1711/b6.html for a
> demonstration and details.
My pgpkey is on my computer, the password to my account is saved by
netscape and while I was under the impression that the bug would also
allow websites to *write* arbitrary files to my system, it is reason
enough for me, not to switch javascript on and visit your page.
Regards,
Thomas
(BTW If you think you would be safe with MS Internet Explorer, think
again. A similar hole exists for IE 4.0 and 4.01 and a lot of people
don't know it!)
--
Buy an AMD K6-III <http://www.bigbrotherinside.com/#help>
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
------------------------------
** 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
******************************
