Cryptography-Digest Digest #990, Volume #9 Thu, 5 Aug 99 11:13:02 EDT
Contents:
Re: OTP export controlled? (Bo Dömstedt)
Re: Is breaking RSA NP-Complete ? (Safuat Hamdy)
Will someone please flame me??? (Michelle Davis)
Re: Looking for GSM Authentication Algorithm A3 ("Lassi Hippeläinen")
Re: What is "the best" file cryptography program out there? (wtshaw)
Re: With all the talk about random... (Shawn Willden)
Re: where to start? (Michelle Davis)
Re: Microsoft Word 97 (pwrecover)
Re: How to keep crypto DLLs Secure? (Jim Felling)
Re: Good generators and primes for Diffie Hellman (DJohn37050)
Re: Construction of permutation matrix (Mok-Kong Shen)
Re: What is "the best" file cryptography program out there? (KidMo84)
Re: Construction of permutation matrix (Mok-Kong Shen)
Re: Bad Test of Steve Reid's SHA1 ([EMAIL PROTECTED])
Re: What is "the best" file cryptography program out there? ([EMAIL PROTECTED])
Re: What is "the best" file cryptography program out there? (KidMo84)
Re: Will someone please flame me??? (SCOTT19U.ZIP_GUY)
Re: Is the output of 3DES really pseudorandom??? (fungus)
Re: Americans abroad/Encryption rules? (JPeschel)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bo Dömstedt)
Crossposted-To: talk.politics.crypto
Subject: Re: OTP export controlled?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 05 Aug 1999 11:36:16 GMT
W.G. Unruh wrote:
>The purpose of all export reguations is to prevent US citizens from supplying
>things to foreigners. It says nothing anywhere that it is to prevent the
>foreigners for doing things themselves.
Precisely! We other people, us foreigners, can manage to run
an OTP without the U.S.,
http://www.protego.se/sg100_en.htm
...we hold an unrestricted export license for the above product!
According to Swedish law of commerce, we cannot refuse to sell,
based upon some opinion of the customer (or the country where
he lives).
>The stated or unstated purpose is not to keep it out of the hands of citizensi,
>although it is clear that there are some who would love to do that.
The OTP system, as compared to DES/IDEA/skipjack/AES candidates,
that cannot have any internal weakness, that could be exploited,
would surly not be appreciated by the tree-letter-agency-people.
Bo Dömstedt
Chief Cryptographer
Protego Information AB
Malmoe,Sweden
------------------------------
From: Safuat Hamdy <[EMAIL PROTECTED]>
Subject: Re: Is breaking RSA NP-Complete ?
Date: 05 Aug 1999 12:54:56 +0200
Nicol So <[EMAIL PROTECTED]> writes:
> > > I have seen different definitions of NP-Hard. The definition I prefer
> > > is:
> > >
> > > A problem is NP-Hard if it is polynomial time reducible (in the sense
> > > of Karp reducibility) to the hardest problem in NP.
> >
> > My impression (derived from a possibly too small set of samples) was
> > that nowadays most people agree that NP-hardness is about
> > Turing-reductions ... isn't that also the definition that Garey &
> > Johnson seem to prefer?
>
> I could be wrong, but my impression is that people these days prefer
> (polynomial-time) many-one reduction to (polynomial-time) Turing
> reduction when dealing with NP-completeness. Do people have a different
> preference when dealing with NP-hardness?
Since complexity theory was one of my main subjects, I claim to have some
knowledge about the terms used here. For reference I prefer Baclazar, Diaz,
Gabarro, Structural Comlexity, 2nd ed, 1994. This is much more up to date
than most other books like Garey, Johnson or Hopcroft, Ullman.
Some clarifications:
Let C be any complexity class
1. C-hard and C-complete by default refers to poly-time many-one reduction,
whenever C is above P, while for P and NLOG (and all other classes above
LOG) it refers to log-space many-one reduction. For two sets A and B we
write A <= B, whenever A is many-one reducible to B. Note also,
"reducible" means by default poly-time many-one reducible.
2. When we really want to speak about Turing reducibility, we say C-T-hard
and C-T-complete (of course, in certain contexts where there is no
ambiguity, we can abbreviate this). For two sets A and B we write A <=_T
B, whenever A is Turing reducible to B. Note that Turing reducibility
usually refers to poly-time Turing reducibility.
3. Def: Some set A C-(T-)hard if and only if any set B from C is
(Turing-)reducible to A. Moreover, if A itself is in C, then A is
C-(T-)complete.
These are the modern definitions for hard and complete, everything else
is fuzz from the past.
4. To remove any doubts: Def: Let A and B be sets over some alphabet S. A
is poly-time many-one reducible to B, if and only if there exists a
deterministic poly-time computable function f such that for any x from
S^*, x is in A if and only if f(x) is in B; similar for space-bounded
many-one reducibility, although here f additionally must not expand it's
input too much (why? Well, we do want our reducibility to be transitive,
don't we?).
Turing reducibility is somewhat more subtle for it requires the notion of
oracles (See Structural Complexity). But believe me that many-one
reduciblity is the "natural" one, therefore it makes perfectly sense to
make it the default reducibility.
--
S. Hamdy | All primes are odd except 2,
[EMAIL PROTECTED] | which is the oddest of all.
|
unsolicited commercial e-mail | D.E. Knuth
is strictly not welcome |
------------------------------
From: [EMAIL PROTECTED] (Michelle Davis)
Subject: Will someone please flame me???
Date: Thu, 05 Aug 1999 10:07:07 GMT
I put up my 'infallible authentication scheme' a few days back, and
got absolutely nothing save for a polite response from Tom Dennis,
saying that the 3DES was overkill. Come on, people, I'm dissapointed.
I was expecting at least eighteen messages within the first day,
filled with razor-sharp comments about my scheme's stupidity. I need
criticism!!! Please supply it, you do it so well.
Here is the previous message, in case you're at all inclined...
>>
I've come up with an identification solution that looks
too good to be true. I'd really appreciate it if someone could tell me
if I'm right or wrong, because I've gone over this a hundred times and
can't find a problem with it. The scheme is as follows:
Key generation: A pseudorandomly-generated central key-seed is split
in half. Each half is
coupled to one half of a user ID, such that two 1024 strings are
obtained (The 36-bit ID comprises only 18 bits of each). Each of these
strings is run through 3DES, with the key being a derivative of the
central key seed. The two results are separately hashed. The two
message digests are joined to form a 320-bit secret key. This key can
be extrapolated by any entity knowing the central key seed, without
having to keep a database of secret keys.
Authentication: The user attaches a timestamp to his ID, joins this to
his secret key (320 bits), and pads it to 512 bits. This string is
then 3DES-encrypted, using a key which is a derivative of the secret
key. The result is hashed, yielding a 160-bit message digest. The left
80 bits are sent to the authenticating entity, together with the ID
and timestamp in unencrypted form. The authenticating computer
performs the exact same operation: obtains the user's secret key
through the procedure detailed in Key Generation; attaches the
timestamp and ID; pads; encrypts; and hashes. The left 80 bits of the
result are compared with what was sent by the user, and if equal, it
authenticates.
Attack: Now comes the good part. This thing is completely and utterly
resistant to attack. Let's say our attacker knows 192 bits of the
string to be hashed (timestamp, padding, etc.), and wants to use this
to do a dictionary attack. He finds that since the 512-bit string has
been passed through 3DES, what has been hashed is in fact a completely
pseudorandom string, which has zero known elements (we are working on
the still-valid assumption that a feistel cipher like 3DES produces
effectively pseudorandom ciphertext). So maybe he wants to attack
3DES. Well, let's assume this is 2010, and our attacker has a machine
which can break 3DES in one second flat. What does he use for his
analysis? All he has is a partial plaintext. He has no ciphertext, no
idea what the key is: In other words, absolutely nothing. _If_ he had
the 3DES ciphertext, supposedly he could do a correlated dictionary
search, using known elements of the plaintextext, and find the unknown
320-bit secret key. But to obtain the ciphertext, he must first get
back to 512 bits from a truncated message digest. This, even in the
year 2100, could take several thousands of years, unless serious
faults were found in SHA-1.
>>
Thanks,
Michelle
------------------------------
From: "Lassi Hippeläinen" <[EMAIL PROTECTED]>
Subject: Re: Looking for GSM Authentication Algorithm A3
Date: Thu, 05 Aug 1999 15:22:44 +0300
Nikle Lin wrote:
>
> Hi All:
>
> I'm looking for the design and implemetation of GSM Authentication
> Algorithm A3. Can anyone give me a ahnd?? Thanks in advance!!
Well, there isn't any...
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.
-- Lassi
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What is "the best" file cryptography program out there?
Date: Wed, 04 Aug 1999 23:59:46 -0600
In article <7oa65a$u0u$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Basically there is more to security then a good algorithm. We have the
> algorithms now. Just no good way to implement them, which is the real
> problem (note CMEA/ORYX/A5 and MS-VPN have all been broken which are
> good examples of systems falling).
I have no problem implementing algorithms in good style. Don't say there
is no way when there is; the goals in implementing crypto correctly are
doable, just not popularly supported by government or Microsoft.
Go back to Stewart Baker's report to the White House (1994-5?) on the
status of encryption. He covered all the basics, reporting that no
implementations did the things they were afraid of them doing, most of
which I had already addressed, the rest, soon thereafter.
>
...
>
> BTW comparing 'ease of use' with 'strength' is really apples vs.
> oranges. People say PGP is hard to use, but strong, does that make it
> bad?
>
For some purposes, there are better solutions than PGP; for some uses, PGP
is satisfactory. If PGP is not a satisfactory choice for some, it makes
it bad from their point of view.
One advantage to a private key system, even to a good or obscure one it
that an attacker might not know the right questions to ask.
--
MY lock, MY key.
------------------------------
Date: Thu, 05 Aug 1999 07:15:59 -0600
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: With all the talk about random...
"Tony T. Warnock" wrote:
> "Douglas A. Gwyn" wrote:
>
> > "Trevor L. Jackson; III" wrote:
> > > This claim amounts to assuming the universe is newtonian.
> >
> > There are quantum phenomena, but you don't need to invoke them to
> > explain the randomness of dice rolling. They would appear to be
> > random even if the universe *were* Newtonian.
>
> I've seen some simulations (two dimensional, four-sided dice) that
> indicate if a die is dropped from a great enough height onto an elastic
> surface, the results are random.
Possibly it would be more precise to say that die-rolling is chaotic, and in
a chaotic system, without *exact* knowledge of initial conditions,
prediction of the exact result is impossible. Of course, if there are
quantum effects involved as well, exact knowledge of initial conditions is
impossible.
Shawn.
--
Shawn E. Willden,
Senior Object Architect, IBM Global Services
------------------------------
From: [EMAIL PROTECTED] (Michelle Davis)
Subject: Re: where to start?
Date: Thu, 05 Aug 1999 13:09:31 GMT
On Wed, 4 Aug 1999 20:26:07 +0200, "Claudio Facilla" <[EMAIL PROTECTED]>
wrote:
>Well, i was starting to study cryptology - I've found on net many
>information but no point of start...
>
>any help for this?
>
>My problem: i have 3 or 4 number (as 2358 2569 2558 and 2589 3698 4571)...
>and so on - i want to find the algorithm of generation... where to start?
>
>There are any programs to help me? Where i find it?
>
>Any - any kind of help will be appreciated (like go there and study - start
>from there... u can do this and so on)...
>I repeat - i m a newbe and i was unable to find any point where to start...
>
>
Okay, first of all, the best place to start off is RSA labs' excellent
cryptography FAQ, which details almost all the basics in clear
language. You can find it at www.rsa.com (surf your way to the FAQ, I
don't remember the exact URL). This will tell you everything you need
to know (to start off with) about cryptography in general, and various
existing cryptographic techniques and algorithms which do various
things.
As for your specific problem, let's see if I can make sense of it. You
have 4 separate numbers, which you think were encrypted by some
algorithm? 235825692558 looks to be 48 bits in length. Most block
ciphers (these are algorithms that take a block of data, and encrypt
it using a key, turning out a same-length block of ciphertext - this
is called symmetrical) have output blocks of 64 bits, the primary
example being DES. There are many more block ciphers with which I am
not personally familiar - Blowfish, Skipjack and so forth. It you find
an algorithm which turns out ciphertext in 48-bit blocks, it's
reasonably safe to assume that it turned out the output you have.
But this brings us to another question: Why? I don't really understand
why you have to find out which algorithm turned out these numbers.
Just ask the person who gave them to you. Generally, it's not too
difficult to find out which algorithm was used in encryption - the
problem is breaking the algorithm. And so, even if you did know which
algorithm turned out these numbers, it wouldn't help you to find the
plaintext, or the original unencrypted message.
Let's assume for a moment that you do, for some incomprehensible
reason, need to know which algorithm generated these numbers. Do you
at least know which class of algorithm was used (block cipher, hash
function, etc.)? If all you have is these numbers, there's no way you
could know for certain which algorithm generated them.
Michelle
------------------------------
From: pwrecover <[EMAIL PROTECTED]>
Subject: Re: Microsoft Word 97
Date: Thu, 05 Aug 1999 13:07:49 GMT
Reply-To: [EMAIL PROTECTED]
You can find help with your Word 97 password recovery problem at
Password Crackers, Inc. check out http://www.pwcrack.com/ for more
information. They offer the only absolute Word 97 cracking guaranteed
for any length password in 10 business days.
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I lost the password for a Microsoft Word 97 document.
> Help me !!!
> Thank's
> NPW
>
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: How to keep crypto DLLs Secure?
Date: Thu, 05 Aug 1999 09:09:36 -0500
[EMAIL PROTECTED] wrote:
> In article <V12q3.2139$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Dmitri Alperovitch) wrote:
> > All right, before this dicussion goes any further, I'd like to make
> one point.
> > Basically, you can do various things (i.e. checksums, etc) to make
> the
> > attacker's life difficult, but the end result is that it's ALL going
> to be
> > reversible. Some "solutions" may be more difficult to reverse than
> others, but
> > neverthless they can ALL be reversed and cracked. There is simply no
> way
> > around it. All programs can be disassembled and debugged and all it
> would
> > take is a smart cracker to NOP the encryption routine and reverse
> whatever
> > checks you've placed in your program.
>
> One way is to disasm all incoming programs before you run them ... Or
> keep multiple copies and compare or ...
>
> You can make things difficult if you hash the binaries, right down the
> hash and compare before using. If the installation binary was correct
> any modification would most likely show up. But of course this could
> be subverted (worm the hash program as well ...)
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
The fact is that any system can be subverted, given enough time and
resources, if the opponent can control the physical hardware.
It is impossible with any present OS that I am aware of to secure against
an opponent that has complete access to all physical hardware components.
To secure any software you must secure at least some of the hardware.
Assuming that this is accomplished, you then use the secured hardware to
verify the unsecured hw/sw.
Securing SW is like nailing jelly to a wall. You can always attack the
outermost layer of security, compromise it, and move inward. The
objective is not to make the crypto DLL 100% secure, just more difficult
to do than it is worth. An exe, and family of DLL's that all self verify,
and verify other dll's is going to be very dificult to trip up, and should
be adequate for the job in most cases.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Good generators and primes for Diffie Hellman
Date: 05 Aug 1999 14:02:07 GMT
I suggest reading up on DH in IEEE P1363.
Don Johnson
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Construction of permutation matrix
Date: Thu, 05 Aug 1999 15:26:54 +0200
Kwong Chan wrote:
>
> I am looking for algorithms to construct a permutation matrix from a random
> seed.
> For example:
>
> Seed Permutation
> 000 -> (0,1,2)
> 001 -> (2,0,1)
> :
> :
> 111 -> (1,2,0)
What you need are 2^n random permutations (n=3 above) of [0,1, ... n-1].
Use a PRNG to generate these. See Knuth's book, vol. 2.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (KidMo84)
Subject: Re: What is "the best" file cryptography program out there?
Date: 05 Aug 1999 14:24:55 GMT
You know, i always wonder what the NSA has broken but has not released to the
public yet:).
Signed,
KidMo
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Construction of permutation matrix
Date: Thu, 05 Aug 1999 15:35:53 +0200
Mok-Kong Shen wrote:
>
> What you need are 2^n random permutations (n=3 above) of [0,1, ... n-1].
> Use a PRNG to generate these. See Knuth's book, vol. 2.
>
Addendum:
In the case n=3 one necessarily has duplicates, since there are
only 6 different permutations. If n>3 one can have distinct
permutations (simply check for duplicates), if desired.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Bad Test of Steve Reid's SHA1
Date: Thu, 05 Aug 1999 14:24:15 GMT
Paul, thanks again for taking time for a useful and interesting reply.
Believe it or not, I feel that my knowledge is sufficient enough that I
don't have any more questions.
Also, my new SHA1m.dll is working ("m" for minus since I handle only 1-
55-char messages; however, that easily could be changed). If anyone
sends me an e-mail, I would be happy to send a copy of the code.
Rob
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Thank you very much for a clear and interesting answer. Correct me
> > if I am wrong: It appears that, since I got the "right" answer when
> > defining LITTLE_ENDIAN, it is because it is required for my Intel
> > processor. If this is so, does Reid's SHA1 routine not work to
compute
> > the "network byte order" you refer to on Intel platforms?
>
> "Network byte order" is a concept that applies only to multibyte
> things -- integers or the like that are 2 or 4 or 8 bytes long.
> SHA-1 operates on strings; for strings there is only one order,
> which is that the first byte goes first. :-)
>
> The reason endian setting matters is that the algorithm picks up
> bytes and puts them into 32-bit integers, and the way it does
> that depends on whether the first byte is the low order or the
> high order byte of the 32-bit word in which it lives.
> In other words, it's an internal issue for the processor, not
> a protocol issue.
>
> paul
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: What is "the best" file cryptography program out there?
Date: Thu, 05 Aug 1999 13:32:00 GMT
In article <7ob41j$mu6$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Actually I have windows 95 and run it in a dos window. A friend of
mine is
> using scott19u on a windows 98 but I have not tested it on such a
system.
> I will release 2 newer versions after my contests end in November. As
you
> can see I get lots of hate mail. Even Mr B.S. and Dave Wagner have
> slammed my stuff and Dave even claimed his new Slide Attack would
> mean the death of my method. But like most pompous asses he was
> just blowing smoke out his ass. Many of the creeps on this site can't
> seem to follow source code. My stuff comes complete with all source
> code and is in C. It was compiled with DJGPP C.
hmm... wonder why you get hate mail.
Cryptography is not aboud programming, it's not about source code, hell
it's not just about an algorithm. And you completely ignore this line
of thought which makes you look like a snake oil peddler.
You haven't even read my open questions have you? Can't answer them?
Figures ...
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (KidMo84)
Subject: Re: What is "the best" file cryptography program out there?
Date: 05 Aug 1999 14:19:59 GMT
Hehe, i think i seen somethin on tv a while back, to create something so simple
but so strong, you have to be either a total fool or a total genious.
I think you might just be both:)
Signed,
KidMo
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Will someone please flame me???
Date: Thu, 05 Aug 1999 14:31:55 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Michelle
Davis) wrote:
>I put up my 'infallible authentication scheme' a few days back, and
>got absolutely nothing save for a polite response from Tom Dennis,
>saying that the 3DES was overkill. Come on, people, I'm dissapointed.
>I was expecting at least eighteen messages within the first day,
>filled with razor-sharp comments about my scheme's stupidity. I need
>criticism!!! Please supply it, you do it so well.
>
>Here is the previous message, in case you're at all inclined...
>
>>>
>I've come up with an identification solution that looks
>too good to be true. I'd really appreciate it if someone could tell me
>if I'm right or wrong, because I've gone over this a hundred times and
>can't find a problem with it. The scheme is as follows:
>
>Key generation: A pseudorandomly-generated central key-seed is split
>in half. Each half is
>coupled to one half of a user ID, such that two 1024 strings are
>obtained (The 36-bit ID comprises only 18 bits of each). Each of these
>strings is run through 3DES, with the key being a derivative of the
>central key seed. The two results are separately hashed. The two
>message digests are joined to form a 320-bit secret key. This key can
>be extrapolated by any entity knowing the central key seed, without
>having to keep a database of secret keys.
Sorry I don"t have rasor sharp comments. But the first part seems
to be a complicated procedure which in summary says. If some knows
the central key seed all they need to know is the ID to get every thing
else. If this is true and if all the users and assumed attacker have the
central key. Then the whole idea rests on keeping the ID secrect. If
both are secret way not just have a secrect 320 bit key in the first place.
>
>Authentication: The user attaches a timestamp to his ID, joins this to
>his secret key (320 bits), and pads it to 512 bits. This string is
>then 3DES-encrypted, using a key which is a derivative of the secret
>key. The result is hashed, yielding a 160-bit message digest. The left
>80 bits are sent to the authenticating entity, together with the ID
>and timestamp in unencrypted form. The authenticating computer
>performs the exact same operation: obtains the user's secret key
Sorry you lost me. There is a public and a secret key? Where?
>through the procedure detailed in Key Generation; attaches the
>timestamp and ID; pads; encrypts; and hashes. The left 80 bits of the
>result are compared with what was sent by the user, and if equal, it
>authenticates.
>
>Attack: Now comes the good part. This thing is completely and utterly
>resistant to attack. Let's say our attacker knows 192 bits of the
>string to be hashed (timestamp, padding, etc.), and wants to use this
>to do a dictionary attack. He finds that since the 512-bit string has
>been passed through 3DES, what has been hashed is in fact a completely
>pseudorandom string, which has zero known elements (we are working on
>the still-valid assumption that a feistel cipher like 3DES produces
>effectively pseudorandom ciphertext). So maybe he wants to attack
>3DES. Well, let's assume this is 2010, and our attacker has a machine
>which can break 3DES in one second flat. What does he use for his
>analysis? All he has is a partial plaintext. He has no ciphertext, no
>idea what the key is: In other words, absolutely nothing. _If_ he had
>the 3DES ciphertext, supposedly he could do a correlated dictionary
>search, using known elements of the plaintextext, and find the unknown
>320-bit secret key. But to obtain the ciphertext, he must first get
>back to 512 bits from a truncated message digest. This, even in the
>year 2100, could take several thousands of years, unless serious
>faults were found in SHA-1.
>>>
>
>Thanks,
>Michelle
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: fungus <[EMAIL PROTECTED]>
Subject: Re: Is the output of 3DES really pseudorandom???
Date: Thu, 05 Aug 1999 17:09:25 +0200
Alwyn Allan wrote:
> > Answer: No statistical test can ever tell you if a number is
> > random - you can't prove a negative.
>
> I can prove a negative. Here is a negative:
>
> 2 is not the largest prime.
>
> Here is my proof:
>
> 3 is prime.
>
> What's wrong with that?
That's not what "proving a negative" means.
Proving a negative is like proving that UFOs don't exist or that
Astrology doesn't work. UFO nuts and astrologers rely on the
fact that you can't disprove their theories to stay in business.
The burden of proof should be on them, but you'll find them
strangely reluctant to provide undisputable proof.
Similarly, you can never prove a number is really random or that
a crypto algorithm is secure.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Americans abroad/Encryption rules?
Date: 05 Aug 1999 14:00:21 GMT
>[EMAIL PROTECTED] (wtshaw) writes:
> > [EMAIL PROTECTED] (JPeschel) I wrote:
>>
>> >I doubt ROT -{n} would be of much of much concern, either.
>>
>> Hmm, I seem to have stuttered.
>> Any way, ROT-13 does have a key, but it's not
>> much of a secret.
>>
>So, you suggest that the difference is whether the key can be kept secret,
>large enough keyspace? Then there should be a lower threshold for
>keyspaces that should be openly excluded from any regulation.
>
>And, take something like UUencode, declared not to be encryption despite
>the suggestive name. There is no reason that a simple manipulation or two
>might make an application that does UU non-standard. I maintain that all
>coding is encryption in a broad sense.
WT, someone wrote that ROT-13 didn't have a key, but it does,
13, Caesar's key was three.
The security of a system should be within the key: K.'s principle.
A lot of these classical ciphers have a huge keyspace, even a Caesar
cipher. The size of the keyspace, though, of course is meaningless
for a Caesar cipher's security. So I think the US government
would not bother to prosecute anyone for, say, making classical ciphers
available from a US web site. (Doesn't the ACA do that?) I think
a regulation that tried to specifically spell out what was exempt
would run into trouble mainly because people would try to find loopholes.
I suppose you could call UUencoding a form of encryption in a broad
sense. Still, if you were teaching a class on encryption, it might
be better not to consider UUencoding and the like as a subset of
encryption. Too confusing, I think.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
