Cryptography-Digest Digest #696, Volume #10 Tue, 7 Dec 99 06:13:01 EST
Contents:
Re: Encrypting numbers? (wtshaw)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (wtshaw)
Re: Quantum Computers and Weather Forecasting (Joseph Bartlo)
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Rick Braddam")
Re: Noise Encryption (Guy Macon)
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: Paradise shills?? (Daniel Hutchings)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Encrypting numbers?
Date: Mon, 06 Dec 1999 23:45:37 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Michael Groh) wrote:
> I have a question that may seem rather obvious to some people, but I
> haven't found a simple answer yet. While reading Singh's book ("The Code
> Book") I noticed that none of the simpler encryption techniques
> specifically address encrypting numeric values. Consider something as
> simple as "$14.37". How can that value be encrypted using a Vigenere or
> substitution cipher? Even the Enigma machine doesn't include a numeric
> row on its keyboard. How did the German military transmit numeric values
> (persumably including + and - signs, decimal points, etc.) using the
> Enigma machine?
>
> TIA for an enlightenment!
>
> - Mike
Other than spelling them out, use an alphabetic *code* for replacement,
even as simple as a=1, b=2, decimal point=x, z as $. Make up your own list
and be generations late. You could use the keyboard as offset q=1, w=2,
etc.
--
Adequate security means causing an attacker to give up and spend his time attacking
someone else.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.privacy
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Mon, 06 Dec 1999 23:40:12 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Orwellian Nightmare Down Under? by Stewart Taggart
>
> 3:00 a.m. 4.Dec.1999 PST
> SYDNEY, Australia -- Any data seem different on your computer today?
>
Such tactics are too much to be tried at present in the USA. When some
bright and devious fellow wants to field test a tactic, pick a country as
a guniea pig, one not too important, Australia, New Zealand,
England....those that are already trained to be kicked around, and not
afraid to treat their citizens as dummies.
If it can be made to work there, surely it can be used here, even if it
has to done in the dark of secret courts, secret orders, holding those who
do not go along without charges calling it national security.
Now if the Constitution can be *handled* through *emergency* measures, and
even politicians are coerced into not talking, we can have a dandy
dictatorship.
--
Adequate security means causing an attacker to give up and spend his time attacking
someone else.
------------------------------
From: Joseph Bartlo <[EMAIL PROTECTED]>
Crossposted-To: sci.physics,sci.geo.meteorology
Subject: Re: Quantum Computers and Weather Forecasting
Date: Tue, 07 Dec 1999 01:21:33 -0500
Trevor Jackson, III wrote:
> Try Alfred Bester's "The Demolished Man" for usage of this technique.
Please explain - I don't know what you are referring to, though I do know
how to demolish things quite well.
Joseph
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Tue, 07 Dec 1999 07:04:35 GMT
karl malbrain wrote:
> That's exactly the SAME point. Why don't they use COTS
> specifications from the airlines?
I didn't know the airlines were using B-1Bs.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Tue, 07 Dec 1999 07:19:18 GMT
"SCOTT19U.ZIP_GUY" wrote:
> No this is based on the fact that if one looks at a binary file.
> One can quickly determine if it is one that could have resulted
> from the compression in use. Most compression schemes
> are such that Decompress(Compress(X))=X for all X
> But so far only the ones I've written (in open lititature) have
> the addtional property that Compress(Decompress(X))=X
> for any X. This is something the average user can check on his
> own. Takes files are random and try to decompress them and
> then compress them back. The problem is far more than just
> the headers. It is so bad that for many encrypted messages
> you may be guaranteeing the fact that the only Key that can
> lead to a valid solution is the one the user used. Which means
> the attacker may have enough info to break your message on a
> cipher only type of attack.
What I'm still trying to figure out is how the lack of the
property Compress(Decompress(X))==X is supposed to help the
cryptanalyst. Given the relative complexity of LZW-style
compression schemes (dynamic dictionary for example), in
order to exploit algebraic properties of the compression
itself, one pretty much has to have duplicated the internal
compressor state (dictionary etc.), which means having
already cracked the outer encryption.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Tue, 07 Dec 1999 07:21:02 GMT
Tim Tyler wrote:
> You don't think 56-bits is a slightly small figure? Even for its day?
It obviously wasn't. DES far outlived its design life.
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Tue, 7 Dec 1999 04:17:32 -0600
Volker Hetzer <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Rick Braddam wrote:
> >
> > Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
> > > The chaining modes are not *meant* to evenly disperse PT
> > > information throughout a message; to do so would require the
> > > entire message to be available at one time, which is often not
> > > the case for real encrypted communication channels.
> >
> > I've read this several times, on different threads. Each time I wonder *how*
>often it is not the case that the entire message
is
> > available at one time.
> Whenever encryption is not performed at the uppermost application layer.
Sounds like the difference between using PGP for email and SSL for purchases. I
*almost* never use SSL, but might use it more often
if I had more disposable income. I have more opportuntiy to use PGP in email -- but
most of what I send could go out by postcard.
Things could change drastically in the future, though. The way things are going in the
U.S. government I may find it a necessity to
become politically active and to prevent some who seem bent on destroying my country
from knowing what I do. If that comes to pass,
even PGP might be inadequate.
> > I know that there are streaming audio & video for computer users, tv, telephone,
>and maybe even telegraph (for all I know), and
that
> > the best type of encryption for me might not be the best type for those uses.
> You forget link-level encryption.
> And remote logins.
I forgot ftp file transfers, too. I've downloaded dozens of files without using
encryption, but I can see the possibility of a need
for extremly strong encryption for file transfers.
> > I don't mean to belittle applications where the complete message is not available
>before transmission
> > starts. I'm just pointing out that they may not be applicable to the majority of
>users of the Internet.
> > So I'm asking: what type of data are the largest number of users concerned with?
> - http requests. they might be encrypted on one block, but is it worth
> the bother?
Well, if I wanted to prevent someone from analyzing my customer's buying habits, I
might want the portions of their requests
identifying the function/cgi script and the parameters encrypted. BTW, I don't
understand the reference to encrypting in one block,
unless you are referring to Scott's "all or nothing" encryption.
> - html pages. If a server has to keep the whole page in memory twice I
> think that would create problems
> because for servers under heavy load this leads to higher memory
> usage. As to "next year", yes, memory
> might be cheaper then, but the number of internet users will have
> increased too.
Oh. I was thinking along the lines of the server assembling the page into a buffer,
then passing a pointer to the buffer to its
sockets interface. If that were the case, it would be just as easy to pass the pointer
to an encryption engine. Then pre/append the
necessary headers and trailers to the ciphertext in the buffer and pass the (adjusted)
pointer to the sockets interface. I didn't
think about sending each item of info immediately as soon as it was developed.
> - Sound and video. This is NOT only commercial. There are many
> non-commercial videos and sounds out there.
Sure, available both for real-time play/display and for downloading and storage. The
former case is not suitable for "all or
nothing" encryption, and the latter _may_ be. A real-time conference of corporate
executives, or co-developers of a high-dollar
project, might be a case where the highest degree of security would be desired *and*
all or nothing encryption would not be useable.
A lecture-type situation with no interactivity might concern information just as (or
more) critical or sensitive and be a situation
where all or nothing would be useable. The receiver would have to download the whole
presentation and decrypt it before playing it.
I think we could come up with hundreds of situations where all or nothing encryption
would not be useable, and perhaps variations on
each of them where it would be.
IIRC, Douglas Gwyn's post was in reference to David Scott's WPCBC chaining method
requiring the whole message or file to be present
to be encrypted before transmitting, as opposed to the way CBC, CFB, and OFB work a
block at a time, allowing messages to be
transmitted (and possibly analyzed) in shorter parcels. At any rate, my question
remains.
Does anyone have, or can anyone make a good estimate of, the percentage of Internet
traffic which is short-message based, where the
entire message would be present for encryption before transmission, and the percentage
of traffic which is long-message based or
real-time continous data where the entire message could not be present before
transmission had to be started? Note that I'm asking
in terms of the entire message not being present before transmission must start to
differentiate between short and long messages.
--
Rick
============================
Spam bait (With credit to E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Noise Encryption
Date: 07 Dec 1999 05:32:27 EST
In article <82go65$1rd$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Wood) wrote:
>
>
>Guy Macon wrote in message <82gn4e$[EMAIL PROTECTED]>...
>>
>>Question: Is there a method of sending encrypted messages that does
>>not at some point require passing secret data (usually a key) between
>>the sender and the reciever?
>
>Yes. Public key cryptography enables this, RSA being a popular algorithm.
>PGP uses public key encryption (in some combination), as do many other
>messaging systems.
>
Hmmm. I misunderstood what I read about public key cryptography.
Thanks for helping me to realize my error. This helps me to learn.
Here is an explaination that cleared up the concept for me, once
I realized that my thinking was wrong:
from http://www.cs.wcu.edu/~russkiy/texts/misc/cryptfaq.txt
1.3 What is public-key cryptography?
Traditional cryptography is based on the sender and receiver of a message
knowing and using the same secret key: the sender uses the secret key to
encrypt the message, and the receiver uses the same secret key to decrypt
the message. This method is known as secret-key cryptography. The main
problem is getting the sender and receiver to agree on the secret key
without anyone else finding out. If they are in separate physical locations,
they must trust a courier, or a phone system, or some other transmission
system to not disclose the secret key being communicated. Anyone who
overhears or intercepts the key in transit can later read all messages
encrypted using that key. The generation, transmission and storage of keys
is called key management; all cryptosystems must deal with key management
issues. Secret-key cryptography often has difficulty providing secure key
management.
Public-key cryptography was invented in 1976 by Whitfield Diffie and
Martin Hellman [29] in order to solve the key management problem. In the
new system, each person gets a pair of keys, called the public key and
the private key. Each person's public key is published while the private
key is kept secret. The need for sender and receiver to share secret
information is eliminated: all communications involve only public keys,
and no private key is ever transmitted or shared. No longer is it necessary
to trust some communications channel to be secure against eavesdropping
or betrayal. Anyone can send a confidential message just using public
information, but it can only be decrypted with a private key that is in
the sole possession of the intended recipient. Furthermore, public-key
cryptography can be used for authentication (digital signatures) as well as
for privacy (encryption).
Here's how it works for encryption: when Alice wishes to send a message to
Bob, she looks up Bob's public key in a directory, uses it to encrypt the
message and sends it off. Bob then uses his private key to decrypt the
message and read it. No one listening in can decrypt the message. Anyone
can send an encrypted message to Bob but only Bob can read it. Clearly, one
requirement is that no one can figure out the private key from the
corresponding public key.
Here's how it works for authentication: Alice, to sign a message, does
a computation involving both her private key and the message itself; the
output is called the digital signature and is attached to the message,
which is then sent. Bob, to verify the signature, does some computation
involving the message, the purported signature, and Alice's public key. If
the results properly hold in a simple mathematical relation, the signature
is verified as genuine; otherwise, the signature may be fraudulent or the
message altered, and they are discarded.
A good history of public-key cryptography, by one of its inventors, is
given by Diffie [27].
1.4 What are the advantages and disadvantages of public-key cryptography
over secret-key cryptography?}
The primary advantage of public-key cryptography is increased security:
the private keys do not ever need to be transmitted or revealed to anyone.
In a secret-key system, by contrast, there is always a chance that an
enemy could discover the secret key while it is being transmitted.
Another major advantage of public-key systems is that they can provide
a method for digital signatures. Authentication via secret-key systems
requires the sharing of some secret and sometimes requires trust of a
third party as well. A sender can then repudiate a previously signed message
by claiming that the shared secret was somehow compromised by one of the
parties sharing the secret. For example, the Kerberos secret-key
authentication system [79] involves a central database that keeps copies
of the secret keys of all users; a Kerberos-authenticated message would
most likely not be held legally binding, since an attack on the database
would allow widespread forgery. Public-key authentication, on the other
hand, prevents this type of repudiation; each user has sole responsibility
for protecting his or her private key. This property of public-key
authentication is often called non-repudiation.
Furthermore, digitally signed messages can be proved authentic to a third
party, such as a judge, thus allowing such messages to be legally binding.
Secret-key authentication systems such as Kerberos were designed to
authenticate access to network resources, rather than to authenticate
documents, a task which is better achieved via digital signatures.
A disadvantage of using public-key cryptography for encryption is speed:
there are popular secret-key encryption methods which are significantly
faster than any currently available public-key encryption method. But
public-key cryptography can share the burden with secret-key cryptography
to get the best of both worlds.
For encryption, the best solution is to combine public- and secret-key
systems in order to get both the security advantages of public-key systems
and the speed advantages of secret-key systems. The public-key system can
be used to encrypt a secret key which is then used to encrypt the bulk
of a file or message. This is explained in more detail in Question 2.12
in the case of RSA. Public-key cryptography is not meant to replace
secret-key cryptography, but rather to supplement it, to make it more
secure. The first use of public-key techniques was for secure key exchange
in an otherwise secret-key system [29]; this is still one of its primary
functions.
Secret-key cryptography remains extremely important and is the subject of
much ongoing study and research. Some secret-key encryption systems are
discussed in Questions 5.1 and 5.5.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: 07 Dec 1999 05:38:34 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Tyler) wrote:
>
>Hmm. I'd have to say that I firmly agree with Douglas's comment along the
>lines that you *really* should not employ schemes where knowledge of the
>plaintext leads directly to the key.
>
>A system where a known-plaintext attack leads directly to the ability to
>send a faked message is really not good.
>
>Even if you are only ever sending a message to a single recipient,
>this property should immediately set loud alarm bells ringing in the
>heads of security-conscious people.
>
>Signing the message helps, of course.
>
>However with such a huge key available, you ought to be able to do
>something that is pretty secure and not vulnerable to
>known-partial-plaintext attacks in the first place.
This is good info. I am seeing the possible security and conveniance
problems clearly. Thanks for being patient and explaining it to me.
------------------------------
From: [EMAIL PROTECTED] (Daniel Hutchings)
Crossposted-To: rec.gambling.poker
Subject: Re: Paradise shills??
Date: Tue, 07 Dec 1999 10:44:23 GMT
What I don't understand is, why use a pseudo-random number generator
at all? You can buy physical devices that use quantum effects to
generate random numbers, and baby it just doesn't get any more random
than that. Comments?
- Dan "ZZ" Hutchings
------------------------------
** 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
******************************
