Cryptography-Digest Digest #75, Volume #13 Thu, 2 Nov 00 14:13:01 EST
Contents:
Re: BENNY AND THE MTB? ("Matt Timmermans")
Re: Calculating the redudancy of english? ("David C. Barber")
Re: Give it up? (SCOTT19U.ZIP_GUY)
Re: BENNY AND THE MTB? (SCOTT19U.ZIP_GUY)
Re: Newbie about Rijndael (SCOTT19U.ZIP_GUY)
Re: End to end encryption in GSM (David Wagner)
Re: BENNY AND THE MTB? ("Brian Gladman")
RSAREF and RSADSI (James Muir)
Re: Open Request to Dr. Kaliski, Jr. at RSA Research - looking for your (David
Wagner)
Certicom's ECC Implementation ([EMAIL PROTECTED])
Re: testing -- Deja says no discussions here ([EMAIL PROTECTED])
Re: Give it up? (Richard Heathfield)
Re: 3-dimensional Playfair? (Daniel)
Re: 3-dimensional Playfair? (Daniel)
Re: ECC choice of field and basis (Mike Rosing)
Re: Crypto Export Restrictions (Darren New)
Re: Give it up? (Mok-Kong Shen)
Re: Really Strong Cipher Idea? (Mok-Kong Shen)
Re: Give it up? (Mok-Kong Shen)
Re: Is RSA provably secure under some conditions? (Mok-Kong Shen)
----------------------------------------------------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
Date: Thu, 02 Nov 2000 17:15:19 GMT
I've stayed out of these threads, because I'm not actually a proponent of
bijective compression as a means to increase the security of your ciphers.
It makes me feel a little guilty, though, letting others try to defend this
use of bicom by themselves.
So: Accepting, for now, the premise that you can't really trust your
cipher, and that any bias in the plaintext is an advantage to attackers,
allow me to describe bicom's encryption:
If a file has <= 128 significant bits (significant bits is kind of like file
length), the 128 most significant bits are encrypted with rijndael. This
will typically result in a file with 127 significant bits (certainly <=128,
so this mapping is reversible).
Otherwise:
1) The first 16K or so of the file is whitened with rijndael. The last
significant block is untouched, so the position of the last significant bit
is unchanged.
2) The last significant bit is always a 1, so we leave this out of the
plaintext for encryption. Lets say that leaves us with 128m+n significant
bits to encrypt, where 128<=n<256. The first 128m bits are encrypted in CBC
mode. The current IV is then stored, and used to encrypt the 128bits at
128m, and then used again to encrypt the 128 bits at 128m+n-128. This
operation does not change the position of last significant bit, and so does
not change the size of the output file.
For the encrypt-then-compress folks, we have these properties:
If your file is really small (<=16 bytes), we sacrifice some compression to
get a secure encryption, using full rijndael.
Otherwise, we ensure that every bit that is subject to encryption is
actually a significant output from the compressor, and Step (2) ensures that
any bias in the lengths of your compressed files does not turn up a bias in
the plaintext bits.
The quick among you will have noticed that the 16K whitening is, of course,
an attempt to make up for the fact that we use a constant IV for the
CBC-mode encryption. This is necessary to preserve the bijective property.
This attempt fails if you encode multiple messages that have identical
headers >16K in size.
It would certainly have done no harm to invent a unique IV, and attach that
to the start of the file after encryption, but that would ruin the
bijection, and for me, the bijection is the fun part. If your messages
aren't typically unique by the first 16K, and you really want to preserve
the properties of CBC-mode using bicom, I suggest transmitting a little salt
through another channel, that both the sender and the recipient will add to
the passphrase. Bicom's key handling will effectively mix this with the key
to give you the same benefits as a unique IV.
Or, of course, you can change the bicom source to do IV generation and
prepending. (please also change the name of the executable!)
------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Re: Calculating the redudancy of english?
Date: Thu, 2 Nov 2000 10:17:31 -0700
"Bill Unruh" <[EMAIL PROTECTED]> wrote in message
news:8tq2bf$2dt$[EMAIL PROTECTED]...
> In <8tkosd$84d$[EMAIL PROTECTED]> Simon Johnson <[EMAIL PROTECTED]>
writes:
>
> > How does one calculate the redudancy of english?
>
> Then you have to decide, are you going to take a typical passage (in
> which many words occur far far far more frequently than others) or a
> dictionary ( where all words occur equally-- once).
What about a Dictionary with definitions (e.g. the Webster available at
Project Gutenberg)? Would analysis there yield useful data?
*David Barber*
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Give it up?
Date: 2 Nov 2000 17:30:12 GMT
[EMAIL PROTECTED] (Richard Heathfield) wrote in
<[EMAIL PROTECTED]>:
snip
>I was not advocating RLE as a compression algorithm. It has other
>problems apart from cryptographic ones. I was simply pointing out that
>it would not necessarily be susceptible to the attack under discussion.
>
>
><snip>
>
>
But the point is that even in your simple example most RLE
do lend them selves to this kind of attack. I thought you would
appreicate that fact. BUt I gess not.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BENNY AND THE MTB?
Date: 2 Nov 2000 17:27:30 GMT
[EMAIL PROTECTED] (Brian Gladman) wrote in
<Z4gM5.5485$zO3.201819@stones>:
><[EMAIL PROTECTED]> wrote in message
>news:8tqatk$slb$[EMAIL PROTECTED]...
>>
>>
>> "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]...
>> > Richard Heathfield <[EMAIL PROTECTED]> wrote:
>> > : Tim Tyler wrote:
>> [snip]
>> > Matt's code takes a message, compresses it, maps the result to
>> > a 128-bit granular file, encrypts it, and maps the result to
>> > an 8-bit granular file.
>>
>> Actually that clarified the issue. Correct me if I'm wrong, but what
>> matt has done is taken a file, compressed it, encrypted it, and (de)
>> compressed it (I'm a little hazy on whether the last step should be
>> considered compression or decompression).
>
>It really isn't either of these. In basic terms the last two 16 byte
>blocks are handled in a particular way. The first of these is encrypted
>with a CBC from the previous block to give a ciphertext block. If the
>second (i.e. the last block in the file) has N valid bytes then N bytes
>of this ciphetext are output and another 16 byte block is formed by
>appending the last N bytes of the file to the remaining 16 - N bytes of
>this ciphertext. This block is then encrypted (using the same CBC value)
>and output.
>
>In fact, this is an over simplified description since the method also
>deals with a last byte that contains less than 8 valid bits so that the
>transformation never operates on any 'non message' bits.
>
I agree you can call it s over simplification of what is happening.
So we do agree on somethings,
>Whether this way of treating the file ending is significantly better in
>security terms than other ways (such as various forms of padding) is
>subject to debate. If you believe Mr Scott the answer is 'yes'; if you
>believe others in the professional cryptographic community the answer is
>'no'.
>
>Brian Gladman
>
The truth is if you ask "real professionals in the cryptographic
communtiry" is it wise to add some sort of systematic information to
a encryption. They would answer its best to avoid additional
information that an attacker could use. However if you ask if one
should use the standard padding methods that add information they
we most likely say yes. The facts are that most professional
are unaware that the padding can be done in this slick way that
matt has used.
They tend to be a closed group of people not open to new ideas
or thoughts, Since this is not the kind of issure they give much
thought to. Ih short they are short sighted and that is why the
crap they design gets broken in real wars. Also the NSA has a vested
interest in keeping this simple kind of info from the public. They
don't want the little man to have safe crypto.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Newbie about Rijndael
Date: 2 Nov 2000 17:32:01 GMT
[EMAIL PROTECTED] (Bob Deblier) wrote in
<[EMAIL PROTECTED]>:
>mac wrote:
>
>> Hello!
>>
>> I'm a newbie with Rijndael, block ciphers and cryptology in general.
>> I've downloaded Mike Scott's C implementation from Rijndael's home
>> site. I'm trying to figure out how it works and I have one question.
>> When I want to encrypt a string of, say three characters(bytes), what
>> do I have to fill up the rest of the array(another 14 bytes). I had
>> problems when passing just a null terminated string that is much
>> shorter that 16 bytes to encrypt/decrypt block functions. It works
>> fine when I pass a 16-byte long null terminated array. I know this
>> seems pretty dumb question to you, but I don't understand everything
>> what's happening in encryption/decryption functions and it's killing
>> me.
>>
>> Thank you very much for any explanations, thoughts or code.
>
>On http://www.rsalabs,com, find the document describing PKCS#5; it offer
>a method for padding and unpadding data blocks. If I recall correctly,
>the document describes this method for a blockcipher with a block length
>of 8 bytes, but the method can easily be extended to 16 byte blocks:
>
Actually those padding methods suck. It might be better to
do padding in a way that does not add information to the file
being encrypted see Matt code I have a pointer at mysite.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: alt.cellular.gsm
Subject: Re: End to end encryption in GSM
Date: 2 Nov 2000 17:46:35 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Big Jase wrote:
>How do you know any algorithm/mechanism/protocol is secure? You don't. You
>of all people should know this.
Wrong. You tell that an algorithm (like 3DES) is likely to be secure
because it has been scrutinized for many man-years by the world's best
cryptographers.
On the other hand, you can tell that a secret, homebrew, proprietary
cipher (like DVD's CSS) is likely to be insecure, because cipher design
is incredibly subtle, and because the algorithm has not received the
intense scrutiny it shoul have.
Let's face it. In the crypto world, saying "my homebrew cipher is good;
just trust me" simply doesn't cut it anymore.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
Date: Thu, 2 Nov 2000 17:48:58 -0000
"Matt Timmermans" <[EMAIL PROTECTED]> wrote in message
news:HihM5.97916$[EMAIL PROTECTED]...
> I've stayed out of these threads, because I'm not actually a proponent of
> bijective compression as a means to increase the security of your ciphers.
> It makes me feel a little guilty, though, letting others try to defend
this
> use of bicom by themselves.
Hi Matt,
I can hardly blame you for staying out of a debate that misses the serious
value of your efforts in bringing together arithmetic coding and
encryption - a nice piece of work - well done.
I looked at your code quickly to find what you had done about end treatment
but I did not have time to look at your statistical model for the coder -
what do you use?
I did some work on this a few years ago and I recall that the model can have
quite an impact on the removal of exploitable statistics in the ciphertext.
This was at a time when keyspace search was a serious possibility but I am
still interested even though its not a significant issue now.
Brian Gladman
------------------------------
From: James Muir <[EMAIL PROTECTED]>
Subject: RSAREF and RSADSI
Date: Thu, 02 Nov 2000 17:41:39 GMT
I've gathered that RSADSI no longer distributes their reference crypto
toolkit RSAREF. I'm sure this is old news ( 5 years maybe ) but I can't
seem to find any information about why this happened. Did RSADSI sell
their rights to RSAREF to someone? or was it just too much trouble for
them to bother with anymore?
-James
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Open Request to Dr. Kaliski, Jr. at RSA Research - looking for your
Date: 2 Nov 2000 17:55:52 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Oh. You mean that that the prng sequence is s, p(s), p(p(s)), ...,
where s in G is a random seed and p : G -> G is a group homomorphism.
Then you take a cipher c : G -> G (also a group homomorphism), and
apply it to the current item in the prng sequence; thus, the output
of the enciphered-prng-sequence is c(s), c(p(s)), c(p(p(s)), etc.
Did I get that right? Is that what you meant? Seems like an
interesting question.
(Note, by the way, that the composition c o p of homomorphisms c,p
is itself a homomorphism. This might be useful.)
------------------------------
From: [EMAIL PROTECTED]
Subject: Certicom's ECC Implementation
Date: Thu, 02 Nov 2000 17:47:00 GMT
Certicom states that their ECC implementation is somehow improved over
others, due to some patented curves.
Can anyone expand on this?
-jeff
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: testing -- Deja says no discussions here
Date: Thu, 02 Nov 2000 17:52:10 GMT
In article <[EMAIL PROTECTED]>,
"John A. Malley" <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> > Deja said that there are no discussions here.
> >
> > Zulu time: 2000a11l02d04h24m
> >
>
> Seen it too, several times. That message seems to appear at the end of
> the every month. Maybe it has something to do with their archiving
> routines.
>
> John A. Malley
> [EMAIL PROTECTED]
Did you see that date I wrote? Maybe it's a beginning-of-the-month
thing.
>
--
| || \ __/__ / \ _/_ | || /
| _|_ ,--, / \ /_ | -+- / ,-. | /
| V T_) | | | \ | | | / _
\_/ + / `' ' __/ \ / `-' \_/ L/ \
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Thu, 02 Nov 2000 18:09:32 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Give it up?
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (Richard Heathfield) wrote in
> <[EMAIL PROTECTED]>:
> snip
>
> >I was not advocating RLE as a compression algorithm. It has other
> >problems apart from cryptographic ones. I was simply pointing out that
> >it would not necessarily be susceptible to the attack under discussion.
>
> But the point is that even in your simple example most RLE
> do lend them selves to this kind of attack. I thought you would
> appreicate that fact. BUt I gess not.
Nope, I guess not. Fear not - I'm not going to contradict you here. Like
I said upthread, I'm no cryptographer. I suspect you're talking about
the fact that the actual RLE decoding scheme must be assumed to be known
to Eve, and she can look for valid RLE encodings as potential
plaintexts. If that's what you mean, then (although I don't /quite/ see
how it would work in practice) I do at least have half a clue as to what
you're talking about.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: [EMAIL PROTECTED] (Daniel)
Subject: Re: 3-dimensional Playfair?
Date: Thu, 02 Nov 2000 18:16:00 GMT
On Wed, 01 Nov 2000 07:25:56 -0700, Sundial Services
<[EMAIL PROTECTED]> wrote:
>For a very fascinating take on this topic and more, by someone who knew
>all too well what was at stake, I heartily recommend "Between Silk and
>Cyanide," now available in paperback.
>
Indeed, the book by Leo Marks was very intriguing to read. It was
common practice to use Playfair to encrypt addresses and dropping
places. Poem code indeed was too vulnerable, but even when WOKs came
in the play, the Poem code was used as a "backup code"!
Daniel
------------------------------
From: [EMAIL PROTECTED] (Daniel)
Subject: Re: 3-dimensional Playfair?
Date: Thu, 02 Nov 2000 18:16:00 GMT
On Wed, 01 Nov 2000 18:08:16 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
>
>Daniel wrote:
>> 1) Choose an appropriate key.
>>
>> 2) The PlainText must have an equal number of bytes.
>>
>
>You oversaw my '(in modern times)' which was intended to
>mean implicitly that one has computer aid and the Playfair
>is understood to be a very compact scheme of a 16-bit to
>16-bit substitution (a specific substitution) that would
>otherwise (in case of a general substitution) take up too
>much storage space. Hence one can e.g. use a PRNG with a
>short seed to generate the matrix. As to your second
>point, what do you do when you have a classical case
>of Playfair with the small matrix and you have an odd
>number of Englich characters? You have to devise a way out
>anyway or else exclude the application of the method. My
>original question was intended to simply know whether
>anybody has thought of employing a large Playfair matrix
>(16*16) at all in cases where it could be conveniently used.
>
>M. K. Shen
1) Sorry, but I was only thinking in "strict Playfair". The PRNG
might be a solution to generate the matrix, though.
2) In a typical Playfair, if there is an odd number of characters in
the PT, an X (or some other char) is added at the end of the PT. For a
human eye 'GO OD BY EX EN DX' is easy to recongnize. For a computer,
it will take some extra programming to keep in line with these rules
when using a 16*16 matrix. I was also wondering what to do with this
eventual last "extra byte", the NULL byte, the ESC-Z byte and so
on...
Programming a large Playfair square will be a lot of fun, but will
have to use some other rules to overcome the above mentioned problems.
The largest problem to overcome will be the size of the CT (= 2 times
the length of the PT - this is the case for a typical Playfair).
Daniel
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: ECC choice of field and basis
Date: Thu, 02 Nov 2000 12:22:02 -0600
[EMAIL PROTECTED] wrote:
> 2) What are the advantages and disadvantages of choosing polynomial
> basis or optimal normal basis? Where can I find a good description of
> optimal nornmal basis?
>
> Any references?
You can find a description of ONB in this book:
http://www.manning.com/rosing
In an FPGA, ONB will be quicker than polynomial, in a standard processor,
polynomial basis may be faster. Security wise there is no difference.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Crypto Export Restrictions
Date: Thu, 02 Nov 2000 18:33:27 GMT
Richard Heathfield wrote:
> c) Source code in /printed/ form is also widely available, and my
> understanding is that the USA's First Amendment was (rightly)
> instrumental in allowing American cryptographic techniques to be
> disseminated in this way. Does the US Government think that terrorists
> are incapable of typing, or of hiring (or coercing) a programmer to type
> for them? The books are on the shelves, all over the world. But even if
> this were false:
Not only this, but the US government will gladly mail you a copy of the
patent protecting unexportable crypto, from which you're supposedly able to
reconstruct the invention.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
The tragedy of the commons applies to monitizing eyeballs, too.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Give it up?
Date: Thu, 02 Nov 2000 19:38:37 +0100
Tom St Denis wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> > Tom St Denis wrote:
> > >
> > > The word "codec" is used quite often in compression groups because
> it
> > > refers to "COmpression DECompression engine". Somies to "COding
> > > DECoding" as well...
> >
> > However you should consider that not everybody subscribes
> > to the other groups and the same shorthand may have different
> > meaning in different disciplines. (I saw e.g. DES with
> > an entirely different meaning elsewhere.)
>
> Well if you want to talk about crypto/compression you have to know the
> lingo.
Mmh, if such do not even appear in standard textbooks on
data compression!
> > >
> > > I don't see how compressing a message can make it any more random
> (i.e
> > > less redundant) then it already is.
> >
> > Compression does concentrates the entropy and so is useful
> > in crypto. It lets the encryption be done on a shorter
> > string and hence is at least more efficient. I don't know,
> > because of poor knowledge, how to properly describe the
> > benefits of compression. But let's take a contrived example
> > where one inserts a zero byte between every pair of bytes of
> > a given sequence. That 'expanded' sequence would certainly
> > be considered undesirable for encryption purposes, I suppose.
>
> A good test for a block cipher is given a ciphertext block C and (let's
> say this is an AES cipher) and 127 bits of P (the plaintext) you cannot
> guess the last bit faster then brute force without the key.
>
> If your block cipher cannot stand upto this test it's not secure. If
> it does then your original point is moot. Sure a good codec will
> increase the efficiency of the system, but if your message is not known
> to the attacker, compression will not make it any easier/harder.
But known-plaintext attack (the zero bytes mean that
part of the plaintext is known) is one of the commonly
considered attacks, isn't it? Note also that my contrived
example was meant only to give some intuitive feeling to
conceive why a compressed sequence with reduced redundancy
is better for crypto processing.
> > > Unless their attacks break the cipher when the input is redundant
> ASCII
> > > there is no security advantage to using contrived inefficient codecs
> > > instead of something good like bzip or deflate.
> >
> > As far as I understand, proponents of 1-1 claim that
> > certain bit sequences (because of the ending bits) could
> > be shown to be impossible to be the result of compression
> > of any given plaintext, since doing decompression to get
> > the presumed plaintexts and doing compression aginn would
> > not lead to the same sequences. Hence this could be utilized
> > to check whether a key is correct (after processing the
> > whole file and doing the decompression and compression).
> > I have currently no intention to further discuss with people
> > on the benefit of 1-1 or the method of obtaining 1-1 or
> > possibility of avoiding requiring 1-1 but you may like to
> > do so.
>
> That arguement (and my spelling sometimes) is laughable. So what if
> you can tell the right key from the wrong one? A program that could
> have upto 2^128 steps (i.e searching the keyspace) is infeasible
> anyways. And not only that I can break a 1-1 scheme with brute force
> anyways (it's the nature of finite information coding).
This is in my view not the right type of argument against
1-1. If you have an extremely secure block cipher, then
by definition you don't have to care about anything else
in the processing, whether you use compression or not. But
that's not the point. The proponents of 1-1 claim (if I
understand correctly) that, if you use compression followed
by a cipher that is susceptible to brute force, then 1-1
helps.
Please note that I don't consider myself on the side of
proponents of 1-1 but rather on the opposite side. So
I am not defending their position, nor, for reasons
already mentioned, countering their position here.
(To be honest, I got sort of fed up with discussions
on the issue and haven't yet recovered from that.) I
suggest that you, if you really want to discuss 1-1 in
depth, create a new thread with a clear and explicit
title line about 1-1 to attract the attention of those
discussion partners that are properly interested in the
issue. Good luck!
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Really Strong Cipher Idea?
Date: Thu, 02 Nov 2000 19:38:30 +0100
John Savard wrote:
>
> A One-Time-Pad is not considered terribly practical, since one has to
> exchange a large key beforehand, its use is strictly limited, and the
> key must be kept secure for a long time.
>
> I tend to agree with this, even if it is the ideal case of
> information-theoretic security.
[snip]
I like to take this opportunity to elicit some discussions
about security. If I have 256 truly random bits, I can use
it as OTP to process 256 bits of plaintext and obtain
perfect security as defined by Shannon. If I use the same
256 truly random bits as key to AES to process a few million
blocks of plaintext, how much diminution in security do I
have? Since there is yet no rigorous quantitative measure
of security, one can't exactly answer that question. But
at least intuitively there is essential diminution.
Conversely, if I do multiple encryption with a few other
comparable block ciphers and corresponding number of sets
of 256-bit keys, how much enhancement in security do I have?
I have the feeling that that could be increasing sort of
exponentially with the number of ciphers involved.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Give it up?
Date: Thu, 02 Nov 2000 19:38:44 +0100
CiPHER wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > Tom St Denis wrote:
> > > The word "codec" is used quite often in compression groups because
> > > refers to "COmpression DECompression engine". Somies to "COding
> > > DECoding" as well...
>
> > However you should consider that not everybody subscribes
> > to the other groups and the same shorthand may have different
> > meaning in different disciplines. (I saw e.g. DES with
> > an entirely different meaning elsewhere.)
>
> Well, _I_ know what codec means and I ain't no fancy-dancy
> crypto/compression god. You mean to tell me you've never used a media
> playing program? Their set-up menus, help files and text files are
> filled with mentions of codecs.
Your guess is excellent. My PC has never had anything to do
with media playing. Currently I don't even have a compiler
for a programming language on my PC (consequence of a virus
attack). The only apparatus that I have and that produces
some music is a portable radio (without cassette).
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is RSA provably secure under some conditions?
Date: Thu, 02 Nov 2000 19:38:49 +0100
"SCOTT19U.ZIP_GUY" wrote:
>
> Having had the unfortunate experince to take a class in LISP
> and to use it for a while. It seemed to be a very poor language
> for anything. It was very very slow. I thought the AI folks got
> wise and there using somthing such as C or C++ or something like PROLOG
> or something like that I am not sure there is good crypto in
> LISP. I wonder if they can even get a version of Rijndael to run
> under LISP.
One of the very nice feature of LISP is that you can easily
run codes that you construct at runtime. LISP is a universal
programming language and hence can do any computation
that any program in another language does. For certain
computing purposes, including AI, one is ready to trade
speed for versatility.
M. K. Shen
------------------------------
** 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
******************************
