Cryptography-Digest Digest #752, Volume #10 Fri, 17 Dec 99 05:13:00 EST
Contents:
Re: 8192bit Encrypt - Easy ! (CLSV)
Re: Not Quite Identity-Based RSA Variant ("karl malbrain")
Re: 8192bit Encrypt - Easy ! (Raphael Phan Chung Wei)
Re: Why no 3des for AES candidacy (Jerry Coffin)
Re: 8192bit Encrypt - Easy ! (Tom St Denis)
Re: Cryptanalysis (Scott Fluhrer)
Re: The Code Book (David Hopwood)
Re: Deciphering without knowing the algorithm? (wtshaw)
US Patent Office: How Stupid? Look Here... (Anthony Stephen Szopa)
Re: Keystrokes monitored/encryption useless (Johnny Bravo)
ARC4 cipher... ("Andrej Madliak")
Re: BBS (Mok-Kong Shen)
Re: Non-linear PRNGs (Mok-Kong Shen)
Re: 8192bit Encrypt - Easy ! (Johnny Bravo)
Re: Deciphering without knowing the algorithm? ("Douglas A. Gwyn")
Re: I was just thinking about a potential Cipher system... ("Douglas A. Gwyn")
Re: 8192bit Encrypt - Easy ! ("Douglas A. Gwyn")
Re: More idiot "security problems" (Xcott Craver)
----------------------------------------------------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: 8192bit Encrypt - Easy !
Date: Fri, 17 Dec 1999 02:26:59 +0000
Glen Bridgland wrote:
> Hi, I new to the group however, I hope to be sharing a lot with the Users
> here over the next few months as I finalise my Project. I am current
> developing an encryption program that will offer 8192bit Encryption along
> with a host of features.
> It Can be Reviewed at http://www.glen-bridgland.co.uk/Project/Crypt.htm
> Please read the document and express your thoughts.
[Please read the FAQ, please read the FAQ, please read the FAQ.]
[It is at
http://www.cis.ohio-state.edu/hypertext/faq/bngusenet/sci/crypt/top.html]
<Done expressing thoughts.>
Ok, having thought all that I am a bit curious about Nanosim.
What is the algorithm?
- CLSV
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: Not Quite Identity-Based RSA Variant
Date: Thu, 16 Dec 1999 19:07:18 -0800
John Savard <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> It would seem that the security of RSA would not be decreased if,
> after choosing one prime, I chose the second prime so that the
> product, a very long number, began with a string giving my identity.
Of course this approach is just a BACKWARD version of the current method --
taking the product AS your identity. What is wrong with this, anyway. Karl
M
------------------------------
From: Raphael Phan Chung Wei <[EMAIL PROTECTED]>
Subject: Re: 8192bit Encrypt - Easy !
Date: Fri, 17 Dec 1999 11:09:06 +0800
Hey Glen, your links are broken
Glen Bridgland wrote:
> Hi, I new to the group however, I hope to be sharing a lot with the Users
> here over the next few months as I finalise my Project. I am current
> developing an encryption program that will offer 8192bit Encryption along
> with a host of features.
>
> It Can be Reviewed at http://www.glen-bridgland.co.uk/Project/Crypt.htm
>
> Please read the document and express your thoughts.
>
> Thanks - Glen.
--
Regards,
Raphael Phan
Faculty of Engineering
Multimedia University
+603-83125314
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Why no 3des for AES candidacy
Date: Thu, 16 Dec 1999 20:48:41 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... why 3DES isn't be considered as part of AES ]
> Because NSA can't break triple DES. In other word, NSA wish to be AES as
> breakable cipher.
How does this make any sense? Keep in mind that 3DES is already in
fairly wide use, and will be standardized in FIPS 46-3 long BEFORE the
work on AES is finished...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: 8192bit Encrypt - Easy !
Date: Fri, 17 Dec 1999 03:57:19 GMT
In article <83bv1d$i9$[EMAIL PROTECTED]>,
"Glen Bridgland" <[EMAIL PROTECTED]> wrote:
> Hi, I new to the group however, I hope to be sharing a lot with the
Users
> here over the next few months as I finalise my Project. I am current
> developing an encryption program that will offer 8192bit Encryption
along
> with a host of features.
Here is my response.
DO NOT SPAM THIS GROUP YOU DARN NEWBIE.
Also what the heck is 8192bit symmetric keys need for anyways?
Oh btw
http://www.pgpi.com
and
http://www.cell2000.net/security/peekboo/index.html
and
http://www.pgp.com
and
http://www.scramdisk.clara.net
and
...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis
Date: Fri, 17 Dec 1999 05:46:49 GMT
In article <83arld$2ga4$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>In article <839t3o$96d$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>>I'm doing a paper on Cryptography and It's Affect On The Information
>>Age. It's mostly about crypto in regards to current US law, however,
>>I have a brief primer on crypto in the first few pages. I need to
>>source everything that is not an oppinion. I remember reading
>>sometihng a few weeks ago about how cryptosystems are often created to
>>meet a purpose and you wouldn't use a difficult cryptosystem to apply
>>to a message to send info that will expire in one week.
>>
>>My line is "The basic theory is to make a cryptosystem which can be
>>applied with the least amount of effort but is impractical to break
>>before the information becomes irrelevant using the currently available
>>equipment."
>>
>>I need to source that, anyone know a web page, book, magazine article,
>>etc which covers the above? I can't remember for anything where I saw
>>that info.
>>
>>I'd appreciate a quick reply.
>>
>
> The problem with crypto that almost makes it an art and not a science is
>that one can never be sure how secure a method really is. One should try to
>use a method that is as secure as possible yet will not take to long to do the
>encryptopm or decyption. It is quite possible systems toted as secure till
>the sun burns out may already be broken by someone with only a few weeks
>of effort. While some other method commonly dismissed as snake oil could
>very well be stronger than anything out there. That is what makes crypto fun.
Hey -- the above is coherent, intellegent, shows some knowledge of cryptography
and has only 4 spelling errors.
OK: Who's posting under DAS's name???
--
poncho
------------------------------
Date: Fri, 17 Dec 1999 05:16:06 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: The Code Book
=====BEGIN PGP SIGNED MESSAGE=====
Warner wrote:
>
> The first sentence of Simon Singh's _The Code Book_ is, "On the morning
> of Wednesday, 15 October 1586, Queen Mary entered the crowded courtroom
> of Fotheringhay Castle". The calendars I have referred to give this date
> as being on a Saturday. I'm interested in hearing comments on this
> apparent inconsistency or references to such.
Are you sure that the calendars you referred to are using Julian dates?
(Most of Europe changed to the Gregorian calendar in 1582; Britain waited
until 1753, IIRC.)
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOFnE1TkCAxeYt5gVAQFdbggAp1bWm5/K4YeXCHCvsRaWAP/nBlWMws8w
DIvr1L+00Qb83f2rP+UZ6Q8KDw+j8E1sxB8ZPTiSSk9Hxbj9DAzcg3/xGLP/2qsA
8zWr/8Whwoc5sNgZoPrc9SgNCI8dWG76fh8UcvyD3dV9keULA30VjBjzwaMaq2EK
CFsiniZd+xwfQn2NPeILkQeqKX5wO2RTjI59G9hqjs9vHEes9hVTRy+UhNXla3mw
ARKdmZTxXJXqpGTCiR49Mus7aR95GtaObFwxupZ4ybkgagB1VjujbPBwXj8/noox
t+yBepbhx45eUl2SUk4JCd/2ZTE5WLc7vkbLwOl++TWAGYrez3JHaA==
=XxFC
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Deciphering without knowing the algorithm?
Date: Fri, 17 Dec 1999 01:13:40 -0600
In article <[EMAIL PROTECTED]>, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>
> ...Scott's code exhibits the classic wholistic doctrine that one cannot
> infer the operation of the assembly from inspection of the parts. No
> amout of reading the code he generated will allow you to deduce his
> intentions at the time he wrote the code. This is why his referrals to
> "read the code" and attacks upon others programming skill fall on deaf
> ears. His position is not defensible.
He explained that he primarilly an assembly programmer. To him what he
writes makes perfect sense. I remember the struggle to get mayself to
adopt a different programming style years ago, but it does not mean that
what I did before was wrong, as it worked.
Indeed, I use some rather unorthodox procedures myself, from time to time,
rather hard to explain to the average programmer, but sometimes they are
better than what others might do. I still like to see beauty in code
anyway.
--
There are those who are neither constrained by in belief of
their power over time and space.
All will have found too late when their time has run out,
and others find for them, a little space to be forgotten in.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: US Patent Office: How Stupid? Look Here...
Date: Fri, 17 Dec 1999 00:25:21 -0800
Reply-To: [EMAIL PROTECTED]
US Patent Office: How Stupid? Look Here...
Here is a patent that has already been issued:
Use a random noise generator and connect it to an analog to digital
converter. Run it through a bias monitor to eliminate bias. Record
the random noise bits on a CD-ROM disk. Create about 1000 such
disks.
Use two or more of these disks and designate where in each disk to
start reading. Merge each bit read using modulo 2 addition to
create a combinational sequence of random bits.
Here is my invention:
Create a file comprised of all possible permutations of the digits
0 - 9 in ascending order with no digit repeated in any of the
permutations. There are 3,628,800 such permutations: 0123456789,
0123456798, 0123456879...
Use one of 6 routines to shuffle the order of the permutation
sequences using random user input.
Create three such files with the 3,628,800 unique permutations in
different random sequence order.
Use the following routine to reference the three random sets to
create two random sets. Then these two random sets to generate a
random number sequence.
Set1 Set2 Set3 Set4 Set5 Num
6327491805 5382460791 1352094678 9275041683 4256083719 0
7246301598 6153704298 7801354926 4851973062 9034178562 4
7845069213 4019682573 2184065379 0219578634 3706259814 0
It is said that each ten-digit array has ten elements or locations
where a single digit is stored. The elements are numbered from left
to right: 0 - 9. The first element is element zero, the second
element is element one, the next is element two, etc.
Let's look just at the first row of ten-digit arrays. Set4 is
derived by using Set2 to index / transform Set3. This is done by
taking the digit stored in element zero at the left in Set2, which
is the digit 5, and using this to index Set3 by going to element
five in Set3, which is the sixth element from the left in Set3.
The digit stored in element five in Set3 is the digit 9. So element
zero in Set4 is made a 9.
Next we take the digit stored in element one in Set2, which is the
digit 3, and use this to index Set3 by going to element three in
Set3, which is the fourth element from the left in Set3. The digit
stored in element three in Set3 is the digit 2. So element one in
Set4 is made a 2.
Again we take the digit stored in element two in Set2, which is the
digit 8, and use this to index Set3 by going to element eight of
Set3, which is the ninth element from the left in Set3. The digit
stored in element eight in Set3 is the digit 7. So element two in
Set4 is made a 7. This process is continued until all ten digits
are accounted for in Set4.
This same process is used to derive Set5 but by using Set1 to index
Set3 instead of using Set2 as was done when Set2 was used to index
Set3 to derive Set4.
This is all very simple. Just relax and take it one step at a time.
But don't worry. The computer does all this work for you.
Finally, the three digit groups placed vertically in the Num column
are derived from Set4 and Set5. The idea is similar in that Set5 is
used to index Set4. But the process is a little different. Here is
how we will index Set5 as we go down each row. (Keep in mind that
each row is also numbered from 0 - 3,628,799 going from top to
bottom.) In row zero, Set5 is indexed at element zero and we find
the digit 4. In row one, Set5 is indexed at element one and we find
the digit 0. In row two, Set5 is indexed at element two and we find
the digit 0. This process continues as we go down the rows
incrementing by one the indexing of Set5. After we have indexed row
nine, we then go on to row ten and we then go back and index Set5 at
element zero again and proceed across Set5 as before. It is sort of
like a typewriter action at the end of a typed line where we make a
carriage return and start back at the beginning of a new line.
Now let's go back to row zero again. We indexed Set5 at element zero
and found the digit 4. So we then use this digit 4 to index Set4.
Element 4 in Set4 is the digit 0. This is the first digit in the
Num column in row zero. We indexed Set5 in row one at element one
and found the digit 0. So we then use this digit 0 to index Set4
in row one. Element 0 in Set4 in row one is the digit 4. This is
the second digit down in the Num column in row one. We indexed Set5
in row two at element two and found the digit 0. So we then use
this digit 0 to index Set4 in row two. Element 0 in Set4 in row two
is the digit 0. This is the third digit down in the Num column in
row two.
Now here is what the patent office has to say:
... the different media storage devices (CD-ROMs) are essentially
different files containing random data, and these random data files
are used to generate random digits or numbers (after they are merged).
Clearly, this is the same as your invention.
... the original random sequences from the CD-ROMs is reordered
(merged) to create multiple random number files, and this process
is analogous to reordering your original permutation files, etc.
The patent office sees no difference between random bits and a random
ordering of the permutation sequences of the digits 0 - 9 with no
repeats.
The patent office sees no difference between modulo 2 addition and
the referencing / transforming process I describe above to be used
with these permutations.
The fact that my method will not work unless you have these random
orderings of these permutations is immaterial to the US patent office.
The fact that the random noise generator cannot possibly create such
a random ordering of the permutations I use and therefore that
inventor could not have possibly contemplated my method is of
no concern to the US patent office.
All that matters is that files of random data are used to create
random numbers therefore that patent supersedes all other patents
regardless of the specific method used. In other words, that other
inventor has been granted a patent so broad that even if another
process hadn't even been invented or existed before that patent was
issued, that inventor's invention will be interpreted to have
contemplated that method / invention.
Is that stupid or what?
I could go on but do you think they are just giving me a hard time?
I will be answering their objections in much more detail and I
believe a patent will be issued for my method for creating random
digits.
(Don't you think generating random bits using a random noise
generator, etc. is certainly obvious? Then why was that patent
even issued?)
For all you random noise generator buffs, he suggests using one or
more analog noise generators such as an NC manufactured by NOISE/COM
of Paramus, N.J.
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Keystrokes monitored/encryption useless
Date: Fri, 17 Dec 1999 03:45:46 GMT
On 16 Dec 1999 22:13:17 GMT, [EMAIL PROTECTED] (Keith A Monahan)
wrote:
>First off, if they think they can prevent some pirate from distributing
>DIRT around to everyone and their brother, they are crazy. I can't
>beleive I haven't seen a pirated copy yet. Perhaps I'll take a look :)
>I'm sure they are charging an arm and a leg for this software which
>was pretty easy to write.
For the actual hackers they get all the kicks they need from real
intrusion software like BackOrifice, why screw around with a key
logger when they can have full control of an entire system including a
GUI that shows the screen just the same as the target computer.
Just for laughs I let a friend of mine access my computer in this
way and turned my protection software off. For most of a night we
played around with it, he took control of my keyboard and mouse and
commented on the pictures I was editing with a pop up message box.
>From his point of view, he was sitting at my computer.
The only thing I could do to stop it was turn the computer off
(ctrl-alt-delete was disabled), and not reconnect to the internet
until I found the offending program. It wasn't hard, I didn't even
need AtGuard to do so. The program was being called from the win.ini
file upon startup, the latest version of McAfee's VShield detected it
as a trojan as well when I restarted the system with all the
protections back in place.
That is the appeal to the LEOs, since it is not in common use, DIRT
won't be detected by virus checkers, but anyone really concerned about
security will be running a properly configured firewall anyway. :)
Best Wishes,
Johnny Bravo
------------------------------
From: "Andrej Madliak" <[EMAIL PROTECTED]>
Subject: ARC4 cipher...
Date: Fri, 17 Dec 1999 09:42:11 +0100
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Hi!
Has anybody heard of
ARC4 stream cipher (w/128-bit key) and/or about its security and
attacks against it?
Thanks,
Andrej
P.S.: It's used in Certicom's (http://www.certicom.com/) ScureMemo
Pad for Palm organizers.
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
Comment: Quis custodiet ipsos custodes?
iQA/AwUBOFnpUoaZUlJQw2ggEQKzGQCfaQL39a/dK7wji1gsahd66YjMhYQAoNwf
FUkdYax6qXlYJZcv1Cpec0CV
=hUzp
=====END PGP SIGNATURE=====
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: BBS
Date: Fri, 17 Dec 1999 10:17:23 +0100
Michael Scott wrote:
>
> I think that if a cycle can be found, then the modulus can be factored.
>
> So the randomness, and non-cycling nature of the generator are both
> predicated on the difficulty of factoring the modulus, and hence cycling
> will not be a problem, assumuing factoring the modulus is difficult.
My consideration is the following: I suppose that given any Blum
integer n, whatever constraints that are placed on it, there may
always be seeds that lead to very small loops. (See my first post.)
Let's call these bad seeds (analogous to weak keys). I have the
impression that such bad seeds are not rare at all. Now a user of
BBS trusts its well-known high security. Even if he does a number
of tests on the generator, he may not necessarily hit on the
bad cases. Then in an actual encryption, with some bad luck, he
employs a bad seed with catastrophic consequences without his having
any suspicion on that. Note that any seed ultimately leads to a loop.
There can be (usually is) an initial unrepeated segment. That
segment can be quite long, so that, even if the user examines that,
he may find everything is o.k. and isn't aware that the sequence
eventually leads to a loop whose length could be as small as 2 or 3.
I should appreciate very much comments on the above.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Non-linear PRNGs
Date: Fri, 17 Dec 1999 10:15:06 +0100
Tim Tyler wrote:
>
> You will find that - at *best* - the bottom bit has a period of two - i.e.
> at its *most* random, it goes 1010101010101010101010101010101010... :-(
Indeed true. So even with non-linear generators one must be very
careful in examining them and consider employing postprocessing
techniques (see my follow-up in the thread 'Linear congruential
generators' of 13 Dec.)
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: 8192bit Encrypt - Easy !
Date: Fri, 17 Dec 1999 04:16:19 GMT
On Fri, 17 Dec 1999 00:18:52 -0000, "Glen Bridgland"
<[EMAIL PROTECTED]> wrote:
>Please read the document and express your thoughts.
LOL, sure, you did ask for it.
1). Encrypt any Media on a Windows 9x Operating System.
What would be the point of not including this. "We can only encrypt
.doc files!"
2). Provides Secure Transfer over a Network with an Encryption rate of
8912bits (DES - Sapphire II).
And the point of all this computationally expensive overkill is?
There are applications where you just don't have time to use 8912 bits
of DES on the network.
3.) Compression Support Applied.
Mr DS is going to insult you and use bad language if you don't use
one-to-one compression! <grin>
4). Multi Password Locking and Encryption Routines.
This is more than a bit vague, is the program password locked, are
the files locked with multiple passwords, can each file be unlocked
with more than one password? Multiple encryption? Why in the hell
would you want more than 8912 bits of some DES variant?
5). Supports more than Thirty of the Best Checksum, Hash, Cipher and
DES Algorithm Types.
TEA is on the list, and is hardly the BEST of anything.
6). Simple, Non Complexed Graphic User Interface.
Just like many other crypto programs we could mention. Hell, there
is even a GUI for PGP 2.6.3.
Now we move on to the Snake Oil portion of the Show.
"It Must be the Best Value Encryption Product on the Market For
Security." and "I feel confident that it is One of the best, if not
the best, Encryption Program available at its price in public
circulation."
We can get good crypto for free. Since your product is not free,
this is a lie, next.
"I would claim this provides an encryption process that would take
decades to break, if posssible at all..."
No proof offered that the multiple encryption is any stronger than
conventional encryption. And the author suggests using a "simple
password phrase" for protection, no matter the encryption, it is only
as strong as the passphrase used to protect it.
"Can you break the Nanosim Code ? Be the first in the World. What does
the text message say ?"
Wow, a stupid crypto challenge, without even a prize, or a point it
seems.
"WHEN IT COMES TO ENCRYPTION WE KICK ARSE!"
I don't really think that this statement needs further explanation.
Johnny Bravo
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Deciphering without knowing the algorithm?
Date: Fri, 17 Dec 1999 09:38:14 GMT
wtshaw wrote:
> He explained that he primarilly an assembly programmer. To him what he
> writes makes perfect sense. I remember the struggle to get mayself to
> adopt a different programming style years ago, but it does not mean that
> what I did before was wrong, as it worked.
Programs have several purposes, only *one* of which is to "work".
Another, very relevant in this context, is to communicate with a
future (maintenance) programmer. Some code is easy for another
competent programmer to fully comprehend, but much code is awful.
There are many books, several of them very good, on programming
style (as opposed to just getting a program to appear to "work").
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: I was just thinking about a potential Cipher system...
Date: Fri, 17 Dec 1999 09:45:54 GMT
Pipian wrote:
> I was thinking that a polymorphic cipher would be fairly secure
> (well it's the same as a one-time pad, I guess) ...
It is not at all the same as a one-time pad, neither in mechanism
nor in security.
> (Sounds similar to a Vigenere cipher on top of Enigma)
> This, I would think, would be fairly secure, ...
Why would you think that?
Knuth (in TAOCP Vol 2) said something like "A good random number
generator must not be designed at random," and explained why.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: 8192bit Encrypt - Easy !
Date: Fri, 17 Dec 1999 09:48:26 GMT
Johnny Bravo wrote:
> "WHEN IT COMES TO ENCRYPTION WE KICK ARSE!"
> I don't really think that this statement needs further explanation.
Maybe it was a typo, intended to be LICK.
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: More idiot "security problems"
Date: 17 Dec 1999 09:55:08 GMT
Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
>
>There is no reason to expect crypto to be better than average in algorithm
>research. There are lots of reasons to expect crypto to be worse than
>average. Chief among these is the fact that the author is unable to tell,
>without great effort, when he has failed.
>But encryption is almost the exact opposite of sort(). The removal of order
>rather then the imposition thereof. So the average coder can't
>tell a good output from a bad one. Even an expert cryptologist requires
>an effort to distinguish the really bad from the merely fatally flawed.
>
>The effect of these conditions is so predictable it ought to have a name like
>"<Someone>'s Law of Cryptology"
Bruce Schneier and Counterpane have been known to assert, in
talks and white papers, that good crypto/security cannot be
distinguished from bad crypto/security. I've always considered
this "Schneier's first law."
His second law being a remark he made at HOPE-II, which, in context,
referred to the tendency of people to simply disable annoying or
restrictive security measures: "The user will pick dancing pigs
over security every time."
-Scott
------------------------------
** 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
******************************
