Cryptography-Digest Digest #197
Cryptography-Digest Digest #197, Volume #14 Sat, 21 Apr 01 04:13:01 EDT
Contents:
Re: Basic AES question (David Formosa (aka ? the Platypus))
Re: ancient secret writing (John Savard)
On the Validity of Non-Logical Modes of Thought (The Constrained OTP) (John Savard)
Re: XOR_TextBox: Doesn't write to swap file if... (Anthony Stephen Szopa)
Re: MS OSs "swap" file: total breach of computer security. (Anthony Stephen Szopa)
Re: Minimal Perfect Hashing (wtshaw)
Re: newbie: cryptanalysis of pseudo-random OTP? ("Osugi Sakae")
Re: Can this be done? ("Mark Lomas")
Re: digital certs What is the format of the file? ("Bryan Olson")
From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Subject: Re: Basic AES question
Reply-To: [EMAIL PROTECTED]
Date: Sat, 21 Apr 2001 04:23:10 GMT
On Fri, 20 Apr 2001 13:23:51 GMT, Lou Grinzo [EMAIL PROTECTED] wrote:
Thanks to Paul and the others for responding.
As best I can tell from the replies, there doesn't seem to
be a technical reason for limiting keys to those three
sizes.
There is a technical reson. If you know the key sizes it makes
protocols design easer.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: ancient secret writing
Date: Sat, 21 Apr 2001 04:43:44 GMT
Although posting binaries to discussion groups is *very* naughty, the
image appears to be of shorthand, perhaps the well-known and
still-used Pitman or Gregg.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
--
From: [EMAIL PROTECTED] (John Savard)
Subject: On the Validity of Non-Logical Modes of Thought (The Constrained OTP)
Date: Sat, 21 Apr 2001 05:11:39 GMT
Somewhat offhandedly, I proposed that a "serious" military OTP
application might take the form of a five-step encipherment, wherein
between three applications of some conventional encryption with a
short secret key, one first applied a 'constrained' OTP, and the
second time a truly random OTP:
i.e.
plaintext - DES - add COTP - DES - add UOTP - DES - ciphertext
Someone asked, quite legitimately, if I was kidding. After all, the
chance of a one-time-pad page coming up with all zeroes to the length
of the message is no greater than the chance that this method might
just happen to have the right UOTP page values to, by coincidence,
produce a ciphertext that matches the plaintext.
This is quite true, and I did know that.
In my response, I pointed out that a cipher system might be 'designed
by committee', and the committee members might include people of
varying cryptologic sophistication.
Thus I posited 'General Jones', who wanted the COTP, because he was
uncomfortable without being sure to change the message before
encrypting, 'Dr. Smith', who, recognizing the theory behind the OTP,
insisted on the true OTP, which I distinguished by calling it the
UOTP, or unconstrained one-time-pad, and 'Mr. Robinson', who took
practical considerations into account, and saw that a simple additive
or XOR combiner of an OTP with a message was dangerously simple, and
the massive volumes of OTP key were vulnerable to compromise, and
insisted on also having conventional encryption layers.
But I could go further than that.
For one thing, Mr. Robinson, if he is the NSA representative on the
committee might think as follows about the COTP and the UOTP:
begin "quote"
In practice, looking for OTP pages that look like LFSR output, for
example, is a waste of time, one won't find them. But on the other
hand, electrical failures that cause an all-zero page come often. So
even the UOTP page producers will have to check, after an all-zero or
all-one page, that something hasn't happened to the device. But even
an electrical failure that goes away, leaving no trace, after the
generation of a page with a large string of zeroes or ones, is vastly
more probable than a truly randomly generated large string.
Thus, instead of a COTP run by people with a sentimental viewpoint,
and a UOTP run by people with a theoretical viewpoint, two OTPs run by
people of a more practical bent would be optimal. However, these two
pads are adequate - and by being generated with different philosophies
help to ensure separate generation and distribution networks, which
are highly desirable from a security standpoint.
end "quote"
Already we're seeing that practice may vary from theory.
Now then, though, I can understand that the position of General Jones
may seem downright silly, based on the mathematical fact I noted above
- that plaintext is just as likely by accident in this kind of system
as an all-zero OTP page is. Is General Jones, then, like the toddler
who, when asking for another cookie, is sat
Cryptography-Digest Digest #197
Cryptography-Digest Digest #197, Volume #13 Tue, 21 Nov 00 11:13:00 EST
Contents:
Re: "unsecure data structures" ? (Paul Crowley)
Re: More about big block ciphers (Tom St Denis)
Re: S/MIME (Tom St Denis)
Re: [Question] Generation of random keys (Alan Rouse)
Re: vote buying... (Jeffrey Williams)
Re: Cryptogram Newsletter is off the wall? (Daniel James)
Re: Cryptogram Newsletter is off the wall? (Daniel James)
Re: Cryptogram Newsletter is off the wall? (Daniel James)
New Algorithm, and what ? (Sylvain Martinez)
Re: A Simple Voting Procedure ("Tony T. Warnock")
Re: "unsecure data structures" ? (Bob Silverman)
Re: Security of Norton YEO (Your Eyes Only) (Mack)
Re: A Simple Voting Procedure ("Trevor L. Jackson, III")
Re: A Simple Voting Procedure ("Trevor L. Jackson, III")
Re: Algorithm with minimum RAM usage? (Mack)
Re: vote buying... ("Trevor L. Jackson, III")
From: Paul Crowley [EMAIL PROTECTED]
Subject: Re: "unsecure data structures" ?
Date: Tue, 21 Nov 2000 11:57:10 GMT
Rainer Nausedat wrote:
Am I right if I assume that one could easily break such a header if is
encrypted ? dwFileCrc for example could be least any 32bit value, but
dwFileAttribute is one of say 12 known possible values, and
cCompressionMethod is one 6 known possible values etc.
Fortunately, no. If you correctly implement strong crypto, you don't
have to worry at all about massaging your data formats to be "crypto
friendly": strong ciphers resist known and even chosen plaintext attack.
Correctly implementing strong crypto is tricky however. CTR mode
Rijndael is likely to become a US national standard soon, and isn't too
hard to implement using one of the free Rijndael implementations; it's
also rather fast. However, if you can use a library like OpenSSL you'll
be better off. Still, there will be many other issues to consider in
building a strong system and you should consider getting a security
consultant in to review what you're doing if you need security.
Schneier's "Secrets and Lies" provides a good perspective.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: More about big block ciphers
Date: Tue, 21 Nov 2000 11:48:33 GMT
In article 8vdg9j$48m$[EMAIL PROTECTED],
Manuel Pancorbo [EMAIL PROTECTED] wrote:
In article 8vceh3$a0b$[EMAIL PROTECTED],
Tom St Denis [EMAIL PROTECTED] wrote:
In article d1fS5.294$[EMAIL PROTECTED],
"Manuel Pancorbo" [EMAIL PROTECTED] wrote:
Huge-block cipher BUTTERFLY
In a previous thread I discussed with some of you about big-block
ciphers
with a feedback stream engine. Now I present my own proposal that
I
name
"butterfly". See source code, testvectors, performance test
programs
and so
on in:
I already posted why your S0[S1[x xor k) 4] is a bad mixing
function (when S0/S1 are parallel 8x8 substitutions).
If I misunderstood then I am sorry, but if you are not listening
SHAME
ON YOU!
Shame on your eyes or on your news server Tom. I did post an answer to
your objection (11, 17 2000). Again:
answer This apply when x is 8-bit and S acts on 8-bits words. But in
this case x is 32-bit and there is 4 8bit-sboxes; so the intermediate
rotation is usefull. /answer
smarteranswerConsider any difference that has input/output under 5
bits and is in the lsb position./smarteranswer
Of course the mixing is not complete but the cipher is not only its
stream engine but the way this is applied on the packet. Please take a
glance at the source code (bfly.c).
If the mixing is not 'complete' then your diffusion is hardly "ideal".
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: S/MIME
Date: Tue, 21 Nov 2000 11:50:22 GMT
In article 8vci72$d0q$[EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
Would anyone happen to know the key differences between S/MIMEv2 and
S/MIMEv3. Is it just the addition of more encryption algoritms?
hmm.. With more algorithms it must be better, no question about it.
hehehe.
40-bit RC2 all the way!
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Alan Rouse [EMAIL PROTECTED]
Subject: Re: [Question] Generation of random keys
Date: Tue, 21 Nov 2000 13:02:55 GMT
The original post on this thread was requesting source code to generate
a random key. I've never seen source code that could flip a coin or
roll dice.
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Jeffrey Williams [EMAIL PROTECTED]
Subject: Re: vote buying...
Date: Tue, 21 Nov 2000 07:35:07 -0600
Although I'll point out tha
Cryptography-Digest Digest #197
Cryptography-Digest Digest #197, Volume #12 Tue, 11 Jul 00 00:13:00 EDT
Contents:
Re: Steganographic encryption system ("Joseph Ashwood")
Re: SCRAMdisk or PGPdisk? (Early Minko)
Re: Random Numbers (Terry Ritter)
Re: Proposal of some processor instructions for cryptographicalapplications
(Terry Ritter)
Re: One plaintext, multiple keys (Terry Ritter)
Re: Proposal of some processor instructions for cryptographical applications (Jayant
Shukla)
Re: Steganographic encryption system (jungle)
Re: Random Numbers (Nicol So)
Re: A thought on OTPs (Nicol So)
Re: Use of EPR "paradox" in cryptography (Roger Schlafly)
Re: One plaintext, multiple keys (S. T. L.)
Re: Steganographic encryption system ("Chris Severn")
Re: A new cipher (wtshaw)
Re: Proposal of some processor instructions for cryptographical (Boris Kazak)
Re: Another AONT (less expensive, this time) (Benjamin Goldberg)
Who was that girl? (An Metet)
Re: One plaintext, multiple keys (Joaquim Southby)
Re: Proposal of some processor instructions for cryptographical applications
("Stephen Fuld")
Re: Compression Encryption in FISHYLAND ("Douglas A. Gwyn")
Re: Proposal of some processor instructions for cryptographical ("Douglas A. Gwyn")
Re: Proposal of some processor instructions for cryptographical ("Douglas A. Gwyn")
From: "Joseph Ashwood" [EMAIL PROTECTED]
Subject: Re: Steganographic encryption system
Date: Mon, 10 Jul 2000 16:52:00 -0700
Crossposted-To: comp.os.linux.development.apps
If I have an encrypted file, and a key which purports to be a valid key
for my system, then surely anyone who knows the algorithm I'm using will
be able to easily find out whether the key is valid, by getting the data?
(Or are you saying that invalid keys should produce random-looking
data, but no indication that the key is bad?)
If you use an All-or-Nothing-Tranform on the files, an attacker MUST go
through attempting to get information from the entire file, in order to
determine if the file contains information from that key (otherwise the data
is difficult to distinguish from random), it's just another way to slow down
the attacker. This also makes it more difficult for your application to leak
information, but will make it more difficult to edit files, you'll be forced
to remove then create them.
Joe
--
From: [EMAIL PROTECTED] (Early Minko)
Subject: Re: SCRAMdisk or PGPdisk?
Date: Tue, 11 Jul 2000 00:28:34 GMT
[EMAIL PROTECTED] (Simon Hogg) wrote:
Forgive me, but I can't find any information comparing these two (SCRAMdisk or
PGPdisk), so what's the consensus?
See Sarah Dean's page:
http://www.fortunecity.com/skyscraper/true/882/index.htm
--
"Early Minko" is actually 5680 714392 [EMAIL PROTECTED].
01234 56789 - Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
--
From: [EMAIL PROTECTED] (Terry Ritter)
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Random Numbers
Date: Tue, 11 Jul 2000 00:42:55 GMT
On Sun, 09 Jul 2000 10:33:37 -0700, in
[EMAIL PROTECTED], in sci.crypt Roger Schlafly
[EMAIL PROTECTED] wrote:
David Hyde wrote:
Does anyone know how to convert a random bit stream into random 16-bit
numbers with uniform distribution?
I assume that the original random bit stream is not uniform,
or the question is trivial.
The standard procedure is to run the numbers thru a crypto
hash function like MD5 or SHA-1.
A CRC should be just fine and faster.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
--
From: [EMAIL PROTECTED] (Terry Ritter)
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
applications
Date: Tue, 11 Jul 2000 00:43:14 GMT
On Sun, 09 Jul 2000 23:30:14 +0200, in
[EMAIL PROTECTED], in sci.crypt Mok-Kong Shen
[EMAIL PROTECTED] wrote:
Iain McClatchie wrote:
Why bother supporting cryptography in the CPU? I agree that general-
purpose substitution and diffusion operations might make software
encryption faster. But why do crytography in software, especially
if you have to hack the hardware ISA to do it?
One may want to use algorithms that don't have specific hardware
implementations. (Not everyone agrees which is THE best algorithm.)
One saves the cost of the hardware. A very personal reason is that I
have more confidence in software code that I can examine than in a
piece of hardware that I can't examine.
Another answer might be: Because it is difficult to impossible for
users to certify that hardware cryptography does nothing beyond what
we think it should.
---
Terry Ritter [EMAIL PROTEC
Cryptography-Digest Digest #197
Cryptography-Digest Digest #197, Volume #11 Fri, 25 Feb 00 03:13:01 EST
Contents:
I want to know the way of preparing C.A services... ("kim do han")
Re: How to Annoy the NSA ([EMAIL PROTECTED])
Re: Implementation of Crypto on DSP ("Douglas A. Gwyn")
QUESTION: Enigma Machine Plans, specification etc (Timothy Charles Holtom)
I had me an Idea (Dynamic Key Encription) ("Tim")
Re: Implementation of Crypto on DSP ("Joseph Ashwood")
Re: Passwords secure against dictionary attacks? (Rami Lehti)
i want to know the way of providing the C.A services... ("kim do han")
Re: Passwords secure against dictionary attacks? (Thomas Wu)
Re: - US "allows" encryption program online (wtshaw)
Re: FIRST TIME! (wtshaw)
Re: Passwords secure against dictionary attacks? ([EMAIL PROTECTED])
I had a .mil account until I told about it here on the USENET in 2000 or ("Markku
J. Saarelainen")
Re: Passwords secure against dictionary attacks? ($[EMAIL PROTECTED])
Re: Assistance needed (Nemo psj)
From: "kim do han" [EMAIL PROTECTED]
Subject: I want to know the way of preparing C.A services...
Date: Fri, 25 Feb 2000 04:36:08 GMT
hello...
i am working in the firewall company...
But our company doesn't have cryptographer...
Our company want to provide the C.A services and i wanna work
that job...
please tell me the way of providing the C.A services...
how can i prepare...?
(document,,,book,,,and programming skill .. )
--
From: [EMAIL PROTECTED]
Subject: Re: How to Annoy the NSA
Date: Fri, 25 Feb 2000 05:11:58 GMT
In article [EMAIL PROTECTED],
"Donald S. Crankshaw" [EMAIL PROTECTED]
wrote:
Jerry Coffin wrote:
In article 879tg8$q95$[EMAIL PROTECTED], [EMAIL PROTECTED]
says...
[ ... ]
The safety of RSA appears to depend on the
difficulty of factoring large numbers. This
factoring is considered very likely to be a
hard problem although it is not yet proven to
be so. It is also not proven that the safety
depends solely on the factoring. The main
point of Peter Shor's famous algorithm is that
it demonstrates that a quantum computer
could factor large numbers efficiently (i.e.
within polynomial time). For anyone who's
interested, a good intro to codes and their
vulnerability is Simon Singh's "The Code Book".
You're still ignoring reality: we already KNOW exactly what effect a
quantum computer has on the amount of time it takes to factor a number
of a particular size. We already have the technology to continue use
RSA, and be protected from an attach using a quantum computer. People
using 2048-bit keys with RSA are already safe, even though the threat
is still purely theoretical.
I know this is an old thread, but I'm new to this group and I came
specifically looking for views by Cryptologists on Quantum
Computation. I work on a Quantum Computation project, so I may be able
to contribute something to this discussion.
For the record, I am not an Algorithms person. My work is more
focused on the design of the qubit (the quantum system which stores
the bit) itself and on the means of rotating it. Thus, I tend to be
more focused on the physics and engineering than the algorithms, but I
know enough about the Shor algorithm to say that 2048 bits is
definitely not safe; at least not if the project I'm working on proves
successful.
It's important to say first that Quantum Computation is not like
Parallelism, where you simply throw more power at the problem. What
QC does is allow you to completely redefine how you approach the
problem.
IF QC works it will not only change the
approach to this problem but even basic
mathematics. Mathematical truth can be held
true regardless of our knowledge of nature or
physics. However, QC could be able to do new
mathematical proofs or calculations that
would take much too long to independently
verify via a non-QC method. Based on our
knowledge of the accuracy of QC (i.e. its
physics) we will have to assume that its new
results are valid. You might want to read
Science Magazine vol. 287, pages 441 463 to
see a further clarification of the basic phsical
requirements for QC. Do you know if anyone at
MIT (e.g. Lloyd, Ketterle, etc.) is intersested in
actually developing the Bose condensate
approach referred to in message 1 of this
thread?
In the case of the Shor algorithm, let's say
you have b bit
product of 2 primes. A quantum computer can solve the problem in
O(b^2) quantum operations. A classical computer requires
O(exp(cb^(1/3)). This is the number field sieve algorithm, the best
known classical one. (It's much better than the slowest one, which is
O(exp(b/2), and would take longer than the lifespan of the universe to
factor a 2048 bit number.) I must admit that I know next to
Cryptography-Digest Digest #197
Cryptography-Digest Digest #197, Volume #10 Wed, 8 Sep 99 03:13:06 EDT
Contents:
Totally off topic ("rosi")
Confused about public key encryption (Timur Tabi)
Re: Win Crypto libs, was: Help with CryptoAPI: can not do the simplest
(SCOTT19U.ZIP_GUY)
Random and pseudo-random numbers (Eric Lee Green)
Re: GnuPG 1.0 released (SCOTT19U.ZIP_GUY)
Re: simple key dependent encryption (SCOTT19U.ZIP_GUY)
Re: Random and pseudo-random numbers (David A Molnar)
Re: Plaintext block size ("Kwong Chan")
Re: THE NSAKEY (fungus)
Re: GnuPG 1.0 released
Re: _NSAKey (Teonanacatl)
Re: Random and pseudo-random numbers
Re: Ways to steal cookies in HTTP and HTTPS (John Pliam)
From: "rosi" [EMAIL PROTECTED]
Subject: Totally off topic
Date: Tue, 7 Sep 1999 22:20:36 -0400
rosi wrote in message 7r1uei$hnt$[EMAIL PROTECTED]...
[snip]
Overheard (coming from land that went through some kind of fanatic
worshiping): Absolute truth is right-wherever-you-put-it nonsense. :)
I think I can safely guarantee that the utterer is absolutely no
mathmatician.
--
From: Timur Tabi [EMAIL PROTECTED]
Subject: Confused about public key encryption
Date: Wed, 08 Sep 1999 02:54:13 GMT
Hi,
I've been reading all sorts of web pages and
newsgroup posts, and I've even been reading the book
"Applied Cryptography", but I just cannot find what
I'm looking for. I know it can't be that difficult,
so I know I'm doing something incredibly stupid.
I am looking for source code for patent-free public
key encryption and decryption. The only two I know
of are RSA and Diffie-Hellman, and I can't seem to
find any source code for Diffie-Hellman.
What I need to do is encrypt and digitally sign a
short plaintext (about 100 bytes), and then decrypt
and verify the plaintext. So I need source code for
the encryption part, and source code for the
decryption part. Some people have pointed me to
pgpi.com or openssl.org, but I can't find anything
there that I can use. The whole thing is very
confusing, and I have some questions:
1. What patent-free algorithms are there besides
Diffie-Hellman?
2. It appears to me that (maybe) public key
encryption algorithms use symmetric key algorithms as
their basis. This doesn't make any sense to me. What
does DES have to do with PGP?
3. Apparently, PGP is not an algorithm per se, but a
way to implement encryption algorithms in such a way
to get public-key encryption. Again, I can't
understand how.
I have a dream. In this dream, I check my email, and
the email contains the source code to two functions:
void encrypt(char *plaintext, char *privatekey, char
*ciphertext);
Takes plaintext and privatekey as input, output is
ciphertext.
int decrypt(char *ciphertext, char *publickey, char
*plaintext);
Takes ciphertext and publickey as input, outputs
plaintext. Returns a 1 if the ciphertext is valid
(hasn't been tampered with), or a 0 otherwise.
Can anyone make my dream into reality?
--
Remove "nospam_" from my email address when replying
Timur "too sexy for my code" Tabi, [EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To:
microsoft.public.win32.programmer.networks,microsoft.public.win32.programmer,comp.os.ms-windows.programmer.win32
Subject: Re: Win Crypto libs, was: Help with CryptoAPI: can not do the simplest
Date: Wed, 08 Sep 1999 04:56:44 GMT
In article [EMAIL PROTECTED], Taavo Raykoff [EMAIL PROTECTED] wrote:
Okay, given that, does anyone have any suggestions for a library of
basic crypto routines that will run on windows? I need DES, RC2, SHA,
and HMAC.
Thanks!!
tr
John Savard wrote:
Taavo Raykoff [EMAIL PROTECTED] wrote, in part:
How hard is it to allow importing the raw keys into CryptoAPI?
The CryptoAPI is designed to prevent unauthorized use of its
functions, so that, for example, a foreign customer permitted to use
56-bit encryption won't be able to use the provided DES function to
perform 112-bit or 168-bit Triple DES encryption.
Hence, the CryptoAPI should be avoided unless you have a specific
export compliance requirement.
John Savard ( teneerf- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
Well if you follow the threads on the NSA key you can replace it with
one of your choice and then use the CryptoAPI to allow any module of
your choice. This way you don't have to be subject to US export laws.
And if Bertsein is right at his site once you buy windows and mode it. Its
yours regardless of what there license says.
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 addres
Cryptography-Digest Digest #197
Cryptography-Digest Digest #197, Volume #9Sun, 7 Mar 99 05:13:06 EST
Contents:
Re: British Crypto Fascists (wtshaw)
Re: Doing It Right: The Next Chip Controversy (wtshaw)
Re: Scramdisk - paranoia ("Dr G.C.Braddock")
Re: Entropy and Crypto-Grade Randomness (Michael Sierchio)
Re: British Crypto Fascists ("hapticz")
Re: Random Generator ("Douglas A. Gwyn")
Yarrow ("David Barton")
Scramdisk lockups, more test data (Jeff Millar)
Re: What's so-called random oracle model? (D. J. Bernstein)
Re: Quantum Computation and Cryptography (Henry Lewsal)
ElGamal vs RSA ("F. Arndt")
Re: ElGamal vs RSA (DJohn37050)
Re: AES and Intellectual Property issues ([EMAIL PROTECTED])
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
Client-server encryption key negotiation...? (Paul Pedriana)
Re: Think you're good at cracking code? Crack This! (Paul Pedriana)
Re: Think you're good at cracking code? Crack This! ("Douglas A. Gwyn")
checksum algorithm ? (Alex)
Re: XOR (Medical Electronics Lab)
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: British Crypto Fascists
Date: Sat, 06 Mar 1999 14:28:01 -0600
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote:
THE Government was accused yesterday of rushing
through legislation that could allow it unprecedented
powers to access and decrypt any person's private e-mail,
inspect digital communications, and investigate data
stored on their computers.
To do something obscurely is a means of extending privacy to the action;
to do something semiprivately that should done in full view and honor,
like pass laws, in circumventomg honest debate show themselves for who
they really are through their own dishonesty and demeaning methods.
Those who want to railroad sneaky legislation should be reminded of the
ultimate fates of many who have undone whole societies to their tragic
end, which is always predictable.
--
Truth is whole in the least of its parts.
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Doing It Right: The Next Chip Controversy
Date: Sat, 06 Mar 1999 14:45:32 -0600
In article [EMAIL PROTECTED], "John Enright"
[EMAIL PROTECTED] wrote:
You've overlooked one very important detail. Let me give you this scenario:
I'm an upright computer user who pays for all of my software (like most
people). Now I decide that I need to upgrade my machine. Under your
scheme, I can't simply reinstall all of my software on the new computer.
And don't tell me about a long, painful reinstall process in order to move
the software. I don't think the public is going to stand for this. Tying
software to a particular machine is a *VERY BAD* idea, IMO.
A computer system, the technical equipment that allows you to do various
things, is made of many machines, parts, cpu's, displays, wire, etc. In
that all of them are linked, at least occasionally, they are all part of
your one system, usually found at one place, but not always, and usually
commanded by one person, or family, or group of friends.
Third party restictions on what you do with your equipment, the parts of
your system, simply are not apt to be welcomed, or functionally valid.
But, if you are a formal manufacturer, better not remanufacture and
transfer goods to points outside of your own system; everything else is
private.
It is in the best interests of everyone to get software from as original a
source as possible, like the original manufacturer. When you commercially
buy something, you have bought that vital link. You probably did not have
to specify a specific target platform and combination of parts attached
therewith before you purchased the software, so who's business is it how
you use it for yourself if you need to repair or replace one of the parts
to your system?
Still, the flipside is how to make sure that the software companies aren't
pirated out of business? I think that if it's difficult enough for most
people, then business will remain good, and prices won't be too bloated to
compensate for piracy.
Just as I'm sure you're not a big fan of the government controlling what you
can can't encrypt, the public will only swallow so much in the control of
the software they purchase. Too much control is always rejected by the
public.
--
Truth is whole in the least of its parts.
--
From: "Dr G.C.Braddock" [EMAIL PROTECTED]
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: Scramdisk - paranoia
Date: Sat, 6 Mar 1999 23:41:57 -
Oohh that should be good!
Regards Dave,
Dr Braddock - sp00ky!
,
/\
(oo)
/__\
00
Dave Howe wrote in message [EMAIL PROTECTED]...
:In our last episode (alt.security.pgp[Fri, 5 Mar 1999 09:27:48
:-]), "sp00ky" [EMAIL PROTECT
