Cryptography-Digest Digest #878, Volume #13 Tue, 13 Mar 01 02:13:01 EST
Contents:
Re: GPS and cryptography (David Schwartz)
Re: Text of Applied Cryptography .. do not feed the trolls ("Tom St Denis")
Re: Really simple stream cipher ("Scott Fluhrer")
Re: GPS and cryptography (those who know me have no need of my name)
Re: Super strong crypto (Bryan Olson)
Re: GPS and cryptography (Darren New)
Re: Super strong crypto (Bryan Olson)
Re: Really simple stream cipher (David Wagner)
Re: Really simple stream cipher (David Wagner)
Re: Text of Applied Cryptography .. do not feed the trolls ("Douglas A. Gwyn")
Re: PGP (David Schwartz)
Re: Text of Applied Cryptography .. do not feed the trolls (Paul Rubin)
Re: Super strong crypto ("John A. Malley")
Re: Super strong crypto ("Douglas A. Gwyn")
Re: Super strong crypto ("Douglas A. Gwyn")
Re: Noninvertible encryption (Paul Crowley)
Re: Text of Applied Cryptography .. do not feed the trolls ("Douglas A. Gwyn")
Re: Super strong crypto ("Douglas A. Gwyn")
Re: Text of Applied Cryptography .. do not feed the trolls (Paul Rubin)
Re: Popularity of AES (Dan Hargrove)
Re: Noninvertible encryption ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: GPS and cryptography
Date: Mon, 12 Mar 2001 19:09:04 -0800
br wrote:
> What do you think about using Global Positionning System (GPS) as key to
> encryption?
If you really mean a "key" then you know that a key works because
attackers don't know what it is. So if I know where you are, I know the
key.
> You can read a message only if your computer is a pre-defined area or
> point in the earth.
How would you implement that? Just using the position as a key doesn't
do that. I may not be in Spain but I can still decode a message if the
key is "Spain" and I _know_ that the key is "Spain" whether I'm actually
in Spain or not.
> I'm waiting for comments
Propose an actual scheme istead of just misusing the word "key".
DS
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Date: Tue, 13 Mar 2001 03:17:11 GMT
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> writes:
> > > I can take most of my library with me on a laptop; I have to go
> > > home to read the dead tree version.
> >
> > Don't give me that dead tree crap. most of it is recycled paper and
computer
> > parts account for quite abit of commercial waste as well.
>
> Huh? He's just saying a digital version is more portable. He's right
> about that.
Books are fairly portable as well :-)
Ya ya... I get your points... in fact I have about 3500 papers on my comp (I
downloaded all of them off the counterpane.com list and I have eurocrypt
from 81 to 97).... but I still think paper is simpler...
Tom
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Mon, 12 Mar 2001 19:46:34 -0800
David Wagner <[EMAIL PROTECTED]> wrote in message
news:98jta5$3hf$[EMAIL PROTECTED]...
> Henrick Hellstr�m wrote:
> >1. I am not sure I understand what you mean by "implicit". Yes, the check
> >might be intertwined with other processes the application would do
anyway.
>
> Here's what I mean by "implicit". If the ciphertext was inauthentic,
> the crypto layer will pass up garbled plaintext, and hope that the app
> will discard this when some sanity check fails (e.g., that some reserved
> bits which should be zero aren't zero, or somesuch).
>
> I don't believe, even for a second, that "implicit authentication" might
> have a significant performance advantage over "explicit authentication".
> The cost of a conditional branch is orders of magnitudes less than the
> cost of decryption. Have you benchmarked the difference? I strongly
> doubt that you'll be able to find any non-negligible performance
difference
> between the two approaches.
There really is one place: when you have a problem space where ciphertext
expansion is absolutely prohibited, or at least extremely expensive. One
such problem arises when you consider how to encrypt a disk drive on a
per-sector basis -- the OS expects 512 byte sectors, the harddisk provides
512 byte sectors. You can certainly encrypt/decrypts as the go on to/come
off of the hard disk, but there's no space left within the sector to store
any sort of MAC, and storing the MAC on another part of the disk may require
an unacceptable performance penalty. In cases like this, sometimes you do
need to bite the bullet, cross your fingers, and hope the application
notices...
>
> >2. As I already mentioned, your approach introduces failure modes (some
> >extra "crypto engine" compatibility issues) not present in my approach.
>
> I must've missed it this failure mode present in "explicit authentication"
> that's not present in "implicit authentication". Would you mind
repeating?
>
> As for issues of getting the wrong DLL, the fault there lies with a broken
> OS, not with the use of "explicit authentication". If the OS can't
prevent
> your code from being replaced with malicious bits, you've lost the game,
> no matter what you do: whether you use implicit or explicit
authentication,
> the attacker can win. The only answer is to use an OS that prevents code
> substitution. Fortunately, this is not rocket science.
>
> >3. The failure modes are known and might ultimately be dealt with, at
least
> >by the application. Otherwise the underlying cipher (or hash or whatever
> >kind of diffusion method is used) has some weakness that would be present
in
> >other modes as well.
>
> Which would you rather rely on?
> (a) hoping that every single application developer gets it right
> (b) hoping that the single implementor of the crypto library gets it
right
> I think it's pretty obvious the smart money is on (b).
>
> It's much easier to review crypto-library code to make sure the check is
> there (you only have to look in one place) than it is to review app code
> (you have to check every app). And the programmer of the crypto code is
> more aware of the security issues than any app programmer is likely to be.
Indeed. Howver, to be fair to Mr. Hellstr�m, he did appear to suggest
having the error propogating encryption transform encrypt a fixed padding at
the end of the message, and have the decrypting system verify that fixed
padding before accept the message. If you do that, you effectively do have
a transform that attempts to do explicit authentication within the
"crypto-library", and so doesn't fall under the "implicit authentication"
Wagner and I are railing against. Just be certain that your form of
authentication has gone through as much peer review as explicit MACs has
gone through -- plausible looking possibilities for such combined transforms
have turned out to have security problems.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: GPS and cryptography
Date: Tue, 13 Mar 2001 04:03:35 -0000
<[EMAIL PROTECTED]> divulged:
>What do you think about using Global Positionning System (GPS) as key to
>encryption?
not much. anyone that managed to get a copy of the message could decode it
merely by feeding the location into the decryption routine -- without ever
having to actually go there.
a token might gain functionality with an embedded gps receiver, but the
power requirements are probably prohibitive.
--
okay, have a sig then
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Mon, 12 Mar 2001 20:23:34 -0800
Douglas A. Gwyn wrote:
>
> Bryan Olson wrote:
> > If you have some result showing Rijndael is flawed, or
> > showing your scheme is strong, that would be significant.
> > Hypothesizing Rijndael is weak and conjecturing that your
> > scheme would fix the weakness is not even in the direction
> > you stated this thread seemed to be about.
>
> That isn't what I was doing.
I'm commenting based on what you wrote; apart from that I
cannot tell what you were doing. You have no proof of
insecurity of the block cipher you start with and no
proof of security for the scheme you produce. You had
said this was about provable security.
--Bryan
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: GPS and cryptography
Date: Tue, 13 Mar 2001 04:31:03 GMT
Ben Cantrick wrote:
> Keyspace is too small. GPS isn't hideously exact. Even combining
> lat, long and elevation you're not going to get a lot of bits to work
> with. Brute-force sweeping of the key space looks like a very likely
> possibility.
I read an article a while back about people using a database of wild
mushroom locations (truffles, maybe?). The intent was that mushroom
gatherers would enter into their computers the location they had gathered
mushrooms from, and save the competition the effort of going to look there.
(Apparently, the mushrooms of interest tend to sprout in the same place
every year.) But you didn't want to tell the competition where the mushrooms
are if they didn't know, so they tried hashing it. Apparently, it was easy
enough to brute-force all possible locations and find the locations where
others had found the mushrooms and get there first the next year.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Mon, 12 Mar 2001 20:53:02 -0800
Douglas A. Gwyn wrote:
> I am concerned with taking some
> standard symmetric encryption algorithm, which is not
> proven to be secure against all possible cryptanalysis,
> and enhancing the way it is used to provide more security,
> to the point that I can have *confidence* that not even
> the best feasible cryptanalysis is going to be able to
> break it (more likely than some acceptable threshold).
The operative step is the lowering the standard, not the
changing of the key.
--Bryan
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Really simple stream cipher
Date: 13 Mar 2001 05:04:42 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Scott Fluhrer wrote:
>Indeed. Howver, to be fair to Mr. Hellstr�m, he did appear to suggest
>having the error propogating encryption transform encrypt a fixed padding at
>the end of the message, and have the decrypting system verify that fixed
>padding before accept the message.
Yes. I consider this roughly equivalent (for the discussion
at hand) to using a MAC and having the decrypting system verify
it before accepting the message. The question is not whether
you use a MAC field or whether you use an all-zeros field; the
real question is: Who checks this field?
If it is the crypto layer who checks the field ("explicit"
authentication), fantastic. Whether it's an all-or-nothing mode
with zero padding or a MAC, if it's "explicit", my objections
don't apply.
The problem comes when you use "implicit" authentication, where
the crypto layer doesn't check it explicitly and instead leaves
it up to the application to notice somehow (hopefully). This is
the case that worries me.
If you can deploy all-or-nothing modes without falling for the
temptation of "implicit" authentication, then I don't have any
objections. My objections are with the "implicit" authentication.
>If you do that, you effectively do have
>a transform that attempts to do explicit authentication within the
>"crypto-library", and so doesn't fall under the "implicit authentication"
>Wagner and I are railing against. Just be certain that your form of
>authentication has gone through as much peer review as explicit MACs has
>gone through -- plausible looking possibilities for such combined transforms
>have turned out to have security problems.
Yes, I agree 100%.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Really simple stream cipher
Date: 13 Mar 2001 05:07:27 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Henrick Hellstr�m wrote:
>"Explicit" PCFB mode decryption and authentication algorithm as it might be
>implemented in a "crypto engine".
>
>Input: Cipher text C, a stateful pcfb mode decryption function D, a format
>specifier string F.
>Output: Parsed plain text structure P, a value true or false.
>
>1. T := D(C)
>2. P := Parse(F,T)
>3. If P is not empty, return(True), otherwise return(False).
Is the format specifier F supplied by the application?
If so, I'm not very happy with this design. Such a design
provides no assurance that the format will contain sufficient
redundancy to prevent forgery attacks. In practice, it might,
or it might not. When security is at stake, the system should
rest on a firmer foundation than this.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Date: Tue, 13 Mar 2001 06:08:20 GMT
Tom St Denis wrote:
> Don't give me that dead tree crap.
Not only are trees renewable resources, and paper printing
technology much more highly developed and easier on the eyes
than computer-based documents, but also it takes quite a
lot of *non*renewable resources to make a computer.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: PGP
Date: Mon, 12 Mar 2001 22:10:47 -0800
"John T. Kennedy" wrote:
>
> Phil Schneier <[EMAIL PROTECTED]> ventured:
>
> >Does anyone keep an unencrypted copy of a file in a very secure place and
> >use the PGP file on their regular computer? What happens to you if your pgp
> >file gets corrupted?
>
> If your encrypted file gets corrupted and can't be repaired then won't
> be able to decrypt it.
>
> Keeping multiple copies of the file on different machines might be
> safer than keeping an unencrypted copy.
Print out the encrypted file and put it up on your wall. Pay to have it
published in the classified section of the New York Times. Put copies of
it on every floppy and hard disk you have. One good think about having
an encryption scheme you trust is that you don't have to worry about
trading off security against loss for secrecy against interception.
DS
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Date: 12 Mar 2001 22:19:07 -0800
"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
> Tom St Denis wrote:
> > Don't give me that dead tree crap.
>
> Not only are trees renewable resources, and paper printing
> technology much more highly developed and easier on the eyes
> than computer-based documents, but also it takes quite a
> lot of *non*renewable resources to make a computer.
Yeah, but I already have a computer. Are you saying it's going to use
more resources for me to download a few megabytes of electrons than to
print several pounds of paper and get someone put the printout on a
fossil-fuel-burning airplane and have it delivered to me?
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Mon, 12 Mar 2001 22:20:56 -0800
"Douglas A. Gwyn" wrote:
> Such a demonstration
> would have to rigorously connect minimum work factor for
> cryptanalysis with the structure of the encryption algorithm.
> I am sure there often are such connections, but absent the
> general theory one can only *guess* what the relation might
> be; a wrong guess could be catastrophic. *** This area is
> so central to "strong crypto" that for years I have urged
> people to work on developing the theory. *** The end product
> would most likely allow a lower bound to be placed on the work
> that *must* be done for any successful attack (meaning to
> exceed some specified likelihood threshold for solution).
Here's an idea I've looked at on and off for a while -
Why not use topology to relate the structure of the encryption algorithm
(or the plaintext, ciphertext and key) to the work factor required to
produce the key from known plaintext and ciphertext, or the key from
known plaintext?
A class (or set) T of subsets of a set X is a topology on X iff the
subsets satisfy certain constraints (won't bore people with the details
yet.) A topological space is (T, X). A topological space (T,X) can
have properties (like continuity, area, length, boundedness.)
Every cipher takes plaintext and transforms it into ciphertext. The
particular transformation chosen out of a set of transformations is
determined by the key (going by Shannon's definition.)
The plaintext consists of a sequence of symbols from a set of symbols we
call the plaintext alphabet, A_p. We may define topologies on A_p. The
sequence of symbols occupy positions in the plaintext. Let's call these
position pos_1, pos_2, pos_3 ... pos_L where L is the length in symbol
count of the plaintext. Call the set of plaintext symbol positions
Pos_p. We may define topologies on Pos_p.
The topology of the plaintext could be described with a product topology
A_p X Pos_p where X is the cartesian product.
The ciphertext consists of a sequence of symbols from a set of symbols
we call the ciphertext alphabet, A_c. We may define topologies on A_c.
The sequence of symbols occupy positions in the ciphertext. Let's call
these position pos_1, pos_2, pos_3 ... pos_M where M is the length in
symbol count of the ciphertext. Call the set of ciphertext symbol
positions Pos_c. We may define topologies on Pos_c.
The topology of the ciphertext could be described with a product
topology A_c X Pos_c where X is the cartesian product.
The key k selects T_k, a transformation taking plaintext P to ciphertext
C, as C = T_k(P). Let T be the set of all possible transformations T_k
for all k in the set of keys K. We may define topologies on T.
Ciphers can preserve none, some or all of the topological "features" or
invariants of the plaintext in the ciphertext. How many and which of the
topological invariants carry over to the ciphertext is a function of the
cipher's structure and its key. Whether or not a cipher does or does
not preserver certain topological properties of the plaintext in the
ciphertext may itself depend upon (or be described by) the topology of
T.
Cryptanalysis can be viewed as recognizing which topological invariants
from the plaintext carry over to the ciphertext and using them in
conjunction with the cipher's structure (and topology) to determine part
or all of the key.
A cipher that preserves all of the topological properties of the
plaintext in the ciphertext would seen to be "easier" to crack than a
cipher that preserves only some of the topological properties of the
plaintext in the ciphertext, and a cipher that preserves none of the
topological properties of the plaintext in the ciphertext would seem to
be very "hard" to crack.
Like a simple substitution cipher: the position sets Pos_p and Pos_c are
identical. One could imagine topologies on the plaintext and ciphertext
alphabets that are identical. The cipher preserves every topological
property in Pos_c found in Pos_p and every topological property in A_c
found in A_p.
Or take a transposition cipher: the position set Pos_p and Pos_c are
different. Topological properties of Pos_p are not preserved in Pos_c -
i.e. neighborhoods about a particular position are different in Pos_c
verses Pos_p. However, the alphabets are the same - A_p and A_c.
Which neighborhoods are preserved and which are changed may depend on a
topology of the transpositions as selected by keys - so perhaps the
topology of the ciphertext (transposed plaintext) could be expressed as
a product topology of the transformation& key's topology and the
plaintext's topology.
Perhaps the work factor is proportional or related to the topological
properties preserved by the cipher structure & key and the topology of
the cipher (the set of T_k's) itself.
This is only a rough outline of some recent thoughts on the subject,
it's very sketchy. Shoot, I've not done anything yet to figure out which
topologies on plaintexts and ciphertexts and transformations/keyspaces
would matter and why. But it seems like an interesting approach to
quantifying the effectiveness of ciphers with respect to work factor and
with respect to each other - topological descriptions of ciphers could
lend themselves to comparative cipher algorithm analysis - relative
strength (in terms of work factor) for one cipher type verses another.
Is there any published research along these lines? I've not run across
it anywhere, but as a neophyte there are sure to be sources of
information (journals, books) unknown to me.
Thanks for any info,
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Tue, 13 Mar 2001 06:31:07 GMT
Bryan Olson wrote:
> ... You have no proof of insecurity of the block cipher
> you start with ...
I didn't specify the basic block function! However,
*any* cipher with finite key is in principle crackable
with enough resources and CT; the only question is the
minimum necessary resources for a specified success
rate against that system using a given key size. I took
that obvious fact as my *starting place*, and it is a
pity that you are so hung up on it.
> ... and no proof of security for the scheme you
> produce.
There are reasons why I'm not presenting you with a nice
package with a ribbon tied around it, but not because
the general concept has no merit. I'm only obliged to
find you an argument, not an understanding. Several
other people have evidently understood what I was getting
at, and why. Maybe if you proceeded for a while on the
"benefit of the doubt" principle you might join them.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Tue, 13 Mar 2001 06:33:04 GMT
Bryan Olson wrote:
> Douglas A. Gwyn wrote:
> > I am concerned with taking some
> > standard symmetric encryption algorithm, which is not
> > proven to be secure against all possible cryptanalysis,
> > and enhancing the way it is used to provide more security,
> > to the point that I can have *confidence* that not even
> > the best feasible cryptanalysis is going to be able to
> > break it (more likely than some acceptable threshold).
> The operative step is the lowering the standard, not the
> changing of the key.
I can't even parse that, and my attempts at degarbling
all produced incomprehensible gibberish. Surely you
cannot mean that I should let the enemy read my traffic!
------------------------------
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Tue, 13 Mar 2001 06:33:15 GMT
"Paul Lutus" <[EMAIL PROTECTED]> writes:
> "SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > I think compression with encryption following is a greatly over
> > looked topic. Compression should help before encryption. But many
> > compression methods actually add information to a file so that it
> > can in theory make it weaker.
>
> You mean the encryption becomes weaker? No. This would suggest that
> compression partially decodes an encrypted file. The only purpose of
> compression is to compress. It has no effect on the encryption.
David A Scott is one of sci.crypt's resident kooks. It's well
understood in the field that compression before encryption is
desirable because it makes content shorter and so speeds encryption.
Modern crypto algorithm are designed to resist attacks based on known
and even chosen plaintext.
hope this helps,
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
Temporary address (due to email problems): [EMAIL PROTECTED]
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Date: Tue, 13 Mar 2001 06:36:03 GMT
Paul Rubin wrote:
> more resources for me to download a few megabytes of electrons than
> to print several pounds of paper and get someone put the printout
> on a fossil-fuel-burning airplane and have it delivered to me?
The exact trade-off computation could be made, but it's more complex
than even that. You replace your computer every so often, and it
required electricity to operate, etc. but then you *might* use
electricity when reading a book, and so it goes. My point was that
it is not so simple as just thinking "book => dead tree".
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Tue, 13 Mar 2001 06:48:13 GMT
"John A. Malley" wrote:
> Why not use topology ...
Thanks for an interesting contribution.
It will take me some time to assimilate it;
my topological intuition, such as it is,
doesn't apply very well to discrete spaces.
The main things I see right off the bat are
that PT "topological invariants" might be
pretty complicated for natural-language PT,
and the approach doesn't make use of the
available statistical information about the
source. It might be worth considering the
"input" topology as being defined over the
system structure with the PT acting as the
mapping, instead of the other way around..
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Date: 12 Mar 2001 22:51:51 -0800
"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
> > more resources for me to download a few megabytes of electrons than
> > to print several pounds of paper and get someone put the printout
> > on a fossil-fuel-burning airplane and have it delivered to me?
>
> The exact trade-off computation could be made, but it's more complex
> than even that. You replace your computer every so often, and it
> required electricity to operate, etc. but then you *might* use
> electricity when reading a book, and so it goes. My point was that
> it is not so simple as just thinking "book => dead tree".
I replace my computer so often whether or not I download a particular file.
My computer (IBM laptop) is about 7 pounds of metal, plastic, silicon,
etc and is on all the time (it uses maybe 20 watts of power). The
books currently in my room are maybe 1000 pounds of paper and I don't
have as many as I once did. If digitized, the books would be a pound
or two of cd-roms or something similar.
I can sure believe that the computer uses more energy *per pound* to
produce than the books, but there's orders of magnitude less pounds.
A lot of the rent I'm currently paying is basically to have space for
the books. A fair amount of energy is used to heat that space in the
winter. I value the data in them enough to not want to throw them in
the trash, but if I could have them in digital form, I'd be a lot more
mobile, would need less living space, lower energy consumption, etc.
Tom mentioned having 20 years of Eurocrypt in digital form; probably
that means the IACR proceedings CD-rom that also has 20 years of
Crypto. The CD-rom is 0.5 ounces of plastic with gunk sprayed on it.
On paper that would be 40 volumes, probably about 100 pounds. Can you
seriously think the energy trade-off favors paper?
------------------------------
From: [EMAIL PROTECTED] (Dan Hargrove)
Subject: Re: Popularity of AES
Date: 13 Mar 2001 06:53:50 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On 12 Mar 2001 18:06:28 GMT, [EMAIL PROTECTED] (Dan Hargrove)
>wrote, in part:
>
>>AES is included with the new version of PGP. There must be some
>>specifications for it.
>
>The Rijndael algorithm, which is publicly known, has been selected.
>But the final official standard is not yet ready, so it isn't really
>legitimate to term a Rijndael implementation an AES implementation,
>that's all.
So is the PGPFree AES Rijndael? I assumed that it was.
Regards;
Dan
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
Date: Tue, 13 Mar 2001 06:59:41 GMT
Paul Crowley wrote:
> David A Scott is one of sci.crypt's resident kooks. It's well
> understood in the field that compression before encryption is
> desirable because it makes content shorter and so speeds encryption.
Precompression does (at least) *two* things: it reduces the
expected CT size (trades off the cost of extra computation
for effective throughput), and it reduces redundancy, which
makes methods of C/A that rely on statistics less effective.
D.Scott is concerned primarily with security, not throughput,
and his concern about standard compression methods, as I
understand it, is that they often concentrate some of the
redundancy at the start of the CT instead of spreading it
evenly throughout the entire CT. That is worth worrying
about if security is your prime concern, although my own
opinion is that it is not a big enough flaw to be exploited
by practical C/A for most likely systems.
> Modern crypto algorithm are designed to resist attacks based
> on known and even chosen plaintext.
But not, generally speaking, to resist *all* such attacks,
just certain specific kinds that the algorithm designer
already knows about.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
