Cryptography-Digest Digest #930, Volume #13 Sun, 18 Mar 01 03:13:00 EST
Contents:
Re: Security of IAPM, alone. (David Eppstein)
Newbie encryption ("nex")
Is this a decent style of plain text encryption? ("ruckc")
Re: How to eliminate redondancy? ("Douglas A. Gwyn")
Re: One-time Pad really unbreakable? ("Douglas A. Gwyn")
Re: Cesar principle ("Douglas A. Gwyn")
Re: Newbie encryption ("Douglas A. Gwyn")
Re: Is this a decent style of plain text encryption? (SCOTT19U.ZIP_GUY)
Re: How to eliminate redondancy? (SCOTT19U.ZIP_GUY)
Re: Newbie encryption (Terry Ritter)
Re: qrpff-New DVD decryption code (Paul Crowley)
Re: How to eliminate redondancy? ("Douglas A. Gwyn")
Re: What do we mean when we say a cipher is broken? (Was Art of ("John A. Malley")
----------------------------------------------------------------------------
From: David Eppstein <[EMAIL PROTECTED]>
Subject: Re: Security of IAPM, alone.
Date: Sat, 17 Mar 2001 18:04:34 -0800
In article <9913ec$iol$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> Paul Crowley wrote:
> >If I ever get the leisure, I'd love to set up a service offering home
> >pages for crypto academics which took all the hard work out of putting
> >your papers online...
>
> Do you know about citeseer? It's a database of online papers in CS
> (not quite the same thing, I know, but awfully useful nonetheless).
> http://citeseer.nj.nec.com/cs
Closer to what Paul suggested, a service for academics which takes some of
the hard work out of putting papers online (you still have to do the
formatting, preferably in LaTeX) is available at http://arxiv.org/
They have a "Cryptography and Security" section
(http://arxiv.org/list/cs.CR/recent) but it doesn't seem to get much use.
--
David Eppstein UC Irvine Dept. of Information & Computer Science
[EMAIL PROTECTED] http://www.ics.uci.edu/~eppstein/
------------------------------
From: "nex" <[EMAIL PROTECTED]>
Subject: Newbie encryption
Date: Sun, 18 Mar 2001 11:18:05 +0800
I would like someone kind enought here to enlighten me on the topic of
encryption.
I surf across may site that mentions encryption. A familar word is bit.
Wat does it means if the encryption is 128 bit, or 64 bit encryption ?
If i write my own encryption algorithm, how do i determin how many bit is
it?
What's the highest number of bit an encryption can go up to??
In the case of hybris .. how are antivirus experts able to determin how many
bit of encryption it's using? Or even what type of encrytion it's using??Is
it possible to crack the hybrid encryption and from there create a plu-in to
auto clean hybris ?
I'll apprecite if anyone can answer my questions or provide some links for
me.
Thanks so much
------------------------------
From: "ruckc" <[EMAIL PROTECTED]>
Subject: Is this a decent style of plain text encryption?
Date: Sat, 17 Mar 2001 21:31:15 -0600
Here is my idea, take a string, which could be of any length, ie a document
or a short message of some kind.
First this is single a single key algorithm and the key is a simple
password, as long as the password is safe so is the data.
But here is my idea, take a string and transform it into a char array, then
take the char array and transform it into a byte array. Take that byte
array and turn it into a Big Integer (ie long long number) of some form.
Then take the password and do the same with, multiply the password with the
data, and convert the result back to a string. Store the string, and for
retrieval convert the string back down to a byte array, then to the large
number, then divide by whatever the user enters, and convert the resulting
Big Integer back down to a byte array then to a String and return the
string.
Would this not be a simple idea of how to encrypt plain text. As long as
the length of the password and the password is not in websters or a proper
noun, it would take a while to decrypt the message by brute force, and a
user would have to look to see if the decrypted message is the proper
message, since it doesnt tell the user weither or not the password is
invalid.
Just an idea,
Curtis Ruck
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How to eliminate redondancy?
Date: Sun, 18 Mar 2001 04:19:33 GMT
"Trevor L. Jackson, III" wrote:
> There is no sensible purpose to further teminology dispute.
It wasn't a terminology dispute. Compression does reduce
redundancy; "masking" with a PRNG has relatively little
effect on redundancy. This is a key issue for cryptology.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Sun, 18 Mar 2001 04:22:28 GMT
Tim Tyler wrote:
> If you are not willing and able to doubt some things, you are
> likely to never discover where you are wrong.
The trick is to know where to focus one's doubts. You've chosen
to doubt the *best* established knowledge and put faith in humbuggery.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cesar principle
Date: Sun, 18 Mar 2001 04:33:04 GMT
br wrote:
> But new ideas, everyone may try.
The problem is, without substantial understanding and experience,
it is most unlikely that your "new" idea is both new *and*
worthwhile. In order to maintain some decent level of quality
here, it is best for ideas presented for discussion to have some
merit. And newsgroup discussion is not the best way to learn a
subject; see the textbooks suggested in the sci.crypt FAQ for that.
> How cryptanalist know that for any key k' that the deciphered text (
> using DES i.e, not RSA)is english or spanish etc...?
Once you crack the system, it is easy to identify the language.
Apart from that, essentially all natural languages have statistical
properties that differ from uniform randomness in similar ways, so
that difference can be often exploited without much concern for the
details. For example, in a simple substitution ciphertext for most
languages, letters can be categorized as standing for consonants and
vowels without knowing what language is involved.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Newbie encryption
Date: Sun, 18 Mar 2001 05:03:45 GMT
nex wrote:
> Wat does it means if the encryption is 128 bit, or 64 bit encryption ?
What is usually mean by that is the number of bits in the key.
> If i write my own encryption algorithm, how do i ...
Don't. If you are asking such simple questions, it is virtually
certain that your encryption algorithm will not be nearly as good
as any of the standard ones you can already find source code for.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Is this a decent style of plain text encryption?
Date: 18 Mar 2001 05:21:04 GMT
[EMAIL PROTECTED] (ruckc) wrote in <[EMAIL PROTECTED]>:
>Here is my idea, take a string, which could be of any length, ie a
>document or a short message of some kind.
>
>First this is single a single key algorithm and the key is a simple
>password, as long as the password is safe so is the data.
>
>But here is my idea, take a string and transform it into a char array,
>then take the char array and transform it into a byte array. Take that
>byte array and turn it into a Big Integer (ie long long number) of some
>form. Then take the password and do the same with, multiply the password
>with the data, and convert the result back to a string. Store the
>string, and for retrieval convert the string back down to a byte array,
>then to the large number, then divide by whatever the user enters, and
>convert the resulting Big Integer back down to a byte array then to a
>String and return the string.
>
>Would this not be a simple idea of how to encrypt plain text. As long
>as the length of the password and the password is not in websters or a
>proper noun, it would take a while to decrypt the message by brute
>force, and a user would have to look to see if the decrypted message is
>the proper message, since it doesnt tell the user weither or not the
>password is invalid.
>
>Just an idea,
>Curtis Ruck
>
What you are saying sounds simple but there are lots of lttle details
that you have not thought about.
1) Is weak keys. One normally wants any key to greatly modify
the code.
2) is the string in hex 0000 0001 diferent from 0001.
You have to make sure you method of converting string to integer
and back is a bijection.
3) It would be weak in that when you multiply 2 integers together
the lower part dose not care about the high part. Example
1003 * 1002 = 1005006
2003 * 4002 = 8016006
the high and low bits don't affect each other very much so that
a use a cipher text only attack of a few messages the attacker could
find the key very easily.
4) having acces to just one plaintext and ciphertext the enemy
could get you key imediately.
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: How to eliminate redondancy?
Date: 18 Mar 2001 05:45:15 GMT
[EMAIL PROTECTED] (Douglas A. Gwyn) wrote in <[EMAIL PROTECTED]>:
>"Trevor L. Jackson, III" wrote:
>> There is no sensible purpose to further teminology dispute.
>
>It wasn't a terminology dispute. Compression does reduce
>redundancy; "masking" with a PRNG has relatively little
>effect on redundancy. This is a key issue for cryptology.
Still compression should reduce redundancy but consider
the latest wizbang RKxx compression that compress an exectable
file to 25% of the size of the original. Take that file and
expand it by 2 so that it is 50% smaller that the orginal.
for odd bits use the higly compressed file. For the even bits
use "1". Know tell me which file would be easier for an attacker
to check a key on the long original file. Or the file compressed
tp 50% the size of the original.
As stated in the online book. Ideal encryption is where you
take a message from your sets of MESSAGES and use a key form
your set of KEYS so that it maps into ciphertext from the
set of CIPHERTEXTS. Each mapping should be BIJECTIVE. An attacker
looking at a single message could not know which key was used.
since each key would allow for different bijective mappings.
This is common sense if you look at encryption
as for example RIJNDEAL. If you look at a single block then
this fact still holds. The problem with using a block cipher
with real world files is one wants to still have this bijective
relationship where any input block can take any value for given
block size and any output block can be mapped to any possible
input block depending on proper choice of input key.
Compression goes along why towards solving the problem if it allows
for any possible input block. And if you use bijective compression
and proper padding then this bijective relationship that is necessary
for proper encryption can be maintained. If you use poor compression
as part of the encryption this bijective nature is lost and you
have made it easier to attack the cipher.
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] (Terry Ritter)
Subject: Re: Newbie encryption
Date: Sun, 18 Mar 2001 06:26:09 GMT
On Sun, 18 Mar 2001 11:18:05 +0800, in
<9919eh$8es$[EMAIL PROTECTED]>, in sci.crypt "nex"
<[EMAIL PROTECTED]> wrote:
>[...]
>I surf across may site that mentions encryption. A familar word is bit.
>Wat does it means if the encryption is 128 bit, or 64 bit encryption ?
http://www.io.com/~ritter/LEARNING.HTM
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Subject: Re: qrpff-New DVD decryption code
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Sun, 18 Mar 2001 06:32:59 GMT
[EMAIL PROTECTED] (Joe H. Acker) writes:
> > How do you define moral or ethics? If it is what most people do,
> > than copying of music is probably not theft.
>
> My God! It is *of course NOT* what most people do! As a German like you,
> I hate to bring this example, but do you believe that in the 3rd Reich
> in Nazi German what most people did was moral or ethical behavior?
http://www.tuxedo.org/~esr/jargon/html/entry/Godwin's-Law.html
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How to eliminate redondancy?
Date: Sun, 18 Mar 2001 07:14:01 GMT
"SCOTT19U.ZIP_GUY" wrote:
> Still compression should reduce redundancy but consider
> the latest wizbang RKxx compression that compress an exectable
> file to 25% of the size of the original. Take that file and
> expand it by 2 so that it is 50% smaller that the orginal.
> for odd bits use the higly compressed file. For the even bits
> use "1". Know tell me which file would be easier for an attacker
> to check a key on the long original file. Or the file compressed
> tp 50% the size of the original.
They'd be about equally easy to check; a small computation with
high reliability. Not that any reasonable attack involves
checking keys like that.
> Compression goes along why towards solving the problem if it
> allows for any possible input block.
All commonly used compression schemes work for any input.
> And if you use bijective compression and proper padding then this
> bijective relationship that is necessary for proper encryption
> can be maintained.
The problem I have with this emphasis on "bijection" is that of
all the possible uncompressions only one will have a priori high
likelihood (in most cases), so it doesn't really disguise the PT.
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: What do we mean when we say a cipher is broken? (Was Art of
Date: Sat, 17 Mar 2001 23:52:36 -0800
wtshaw wrote:
>
> In article <[EMAIL PROTECTED]>, "John A. Malley"
> <[EMAIL PROTECTED]> wrote:
>
> ...
> >
> > Unicity distance is a relationship between the uncertainty of the key
> > and the redundancy of the plaintext. Under the random cipher model the
> > expected unicity distance U of a cipher is
> >
> > U = H(K) / D
> >
> > where U is the number of characters of plaintext, H(K) is the
oops, U should be the number of characters of _ciphertext_
> > uncertainty of the key and D is the plaintext's redundancy expressed in
> > bits/symbol (or D in this equation is the difference between the log of
> > the number of characters and the average amount of information carried
> > per character as actually used.)
> This uncertainty value seems to be an out. What range do you suggest it can be?
There's an interesting question. The formula above tells us that with at
least U characters of ciphertext a cryptanalyst can establish the unique
key value used to encrypt the ciphertext. With more than U characters of
ciphertext the uncertainty in the key given the ciphertext goes to zero.
With less than U characters of ciphertext the cryptanalyst cannot be
100% sure of the exact key used to encrypt the ciphertext - even if
every key is checked! That's an amazing fact we hardly ever mention
when talking about brute-force attacks on ciphers. Brute force is not
guaranteed to reveal *the* secret key when the amount of ciphertext is
less than the unicity distance of ciphertext.
We can increase the unicity distance by holding the uncertainty of the
key constant, by fixing the bit size of the key, and reducing the
redundancy in the plaintext with compression prior to encryption. The
more redundancy we squeeze out, the larger we make the unicity distance.
Or we can increase the unicity distance by holding the redundancy of the
plaintext constant (no compression) and increasing the uncertainty of
the key (by increasing the key bit length.)
Or we can do both, increase the key length and compress to remove
plaintext redundancy :-)
Say the key length is 56 bits for a DES-like block cipher. U = 56/D, and
for English, D is around 3.2 bits, so U is about 18 characters of
english text. If each character is encoded as an 8 bit byte in
plaintext, that's 144 bits of plaintext, and after encryption, two 64
bit blocks of ciphertext to reach U.
Take the key length to 128 bits for an AES-like block cipher. U =
128/3.2 = 40 characters, encoded as 8 bit bytes that's 320 bits or 3
blocks of 128 bit ciphertext to reach U.
Say we reduce the redundancy in the plaintext to 1 bit per character.
Then for the DES-like cipher with a 56 bit key, U = 56/1 = 56 characters
of English text. Again, encoded as 8 bit bytes in plaintext, that's 448
bits of plaintext and thus 7 blocks of 64 bit ciphertext to reach U. For
the AES-like cipher with a 128 bit key, U = 128/1 = 128 characters of
English text. Encoded as 8 bit bytes in plaintext, that's 1,024 bits of
plaintext and thus 8 blocks of 128 bit ciphertext to reach U.
But what we didn't consider in these trade-offs is the work
characteristic of the cipher, W(n), the average amount of work (in some
unit of measure like man-hours or computation-time & computation-space)
required to determine a key for ciphertext n characters long. (See
Shannon's "Communication Theory of Secrecy Systems.")
Say we choose a cipher and we know its work characteristic W(n). Assume
W(n) peaks before n reaches the unicity distance U, at some value n = w,
w < U. What's more efficient for changing the unicity distance?
Changing the key size or changing the redundancy in the plaintext? And
what's the relative efficiency of one over the other?
What happens to the work characteristic W(n) of a given cipher type as
the unicity distance U increases and/or the key size increases?
I don't exactly know :-(
But, here's a swag at a model -
The work characteristic is (probably) directly proportional to the key
size in bits, double the key size, double the work. So I assume W(n) is
proportional to H(K).
The work characteristic is (probably) directly proportional to the
unicity distance U.
Combine these two assumptions together as W(n) is proportional to U *
H(K), or
W(n) is proportional to H(K)^2 / D.
Since H(K) is the bit length of the key, b bits, and D is already in
units of bits (per character), we can rewrite this as
W(n) is proportional to b^2 / D
or
W(n) = a * b^2 / D, where a is some (unknown) direct proportionality
constant.
Then dW(n)/db = 2a * b / D . This means a one bit increment in key
size results in 2a * b/D increase in the work characteristic.
And dW(n)/dD = - a * b^2 / D^2 . This means a one bit decrement in
redundancy per character (a negative value) results in a * b^2/ D^2
increase in work characteristic.
The magnitude of work characteristic increase for a single bit decrement
in redundancy per character is always greater than the magnitude of work
characteristic increase for a single bit increment in key size as long
as
b / D > 1, or b > D.
So this swag of a model tells me compression increases the work
characteristic "better" than expanding the key size and is the
preferable way to go.
Caution: these results are only as valid as the model :-)
John A. Malley
[EMAIL PROTECTED]
------------------------------
** 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
******************************
