Cryptography-Digest Digest #800, Volume #11 Wed, 17 May 00 12:13:01 EDT
Contents:
Re: Chosen plaintext attack, isn't it absurd? (Peter Trei)
Re: Unbreakable encryption. (Bo Dömstedt)
UBS keylinkweb (Thomas Kellar)
Re: Is OTP unbreakable? (Paul Koning)
Re: Is OTP unbreakable? (Paul Koning)
Re: Is NovaStar DataSafe using Blowfish encryption any good? (Paul Koning)
Re: Crypto & UNICODE??? ("Kenneth Cascio")
Re: Chosen plaintext attack, isn't it absurd? (Runu Knips)
Re: QUESTIONS About ALGOS !! (Runu Knips)
Re: What is the advantage of undeniable signature? (Roger Schlafly)
Re: Is OTP unbreakable? (Xcott Craver)
Re: Crypto & UNICODE??? ("Kenneth Cascio")
----------------------------------------------------------------------------
From: Peter Trei <[EMAIL PROTECTED]>
Subject: Re: Chosen plaintext attack, isn't it absurd?
Date: Wed, 17 May 2000 14:32:32 GMT
Manuel Pancorbo wrote:
> I mean, if the attacker is able to access the encipher machinery (but not
> the actual key) and then test the ciphertexts she wants, what stops her to
> access the DEcipher machinery?
[...]
> Manuel Pancorbo
> [EMAIL PROTECTED]
You need to differentiate between different types of plaintext attack. In
attacking classical ciphers in actual use, it's often possible to create
situations
in which a chosen plaintext is enciphered - for example, if the State Department
sent a message to the Ruritanian ambassador outlining a trade proposal, it's a
good bet that the message would soon be sent by the Ruritanian embassy back
home, encrypted. Thus, you have created a chosen plaintext/ciphertext pair,
which is a great help in fuguring out the cipher.
There is another class of attacks which involves creating a large database
of chosen plaintext/ciphertext pairs, and using differential analysis to find
the
key. DES can be attacked this way with 2^47 pairs. See Schneier.
I agree that this is usually an impractical attack.
Peter Trei
------------------------------
From: [EMAIL PROTECTED] (Bo Dömstedt)
Subject: Re: Unbreakable encryption.
Reply-To: [EMAIL PROTECTED]
Date: Wed, 17 May 2000 13:53:17 GMT
[EMAIL PROTECTED] wrote:
>A while back I posted some messages describing new encryption
>algorithms that are not breakable. It used the Virtual Calc 2000
>to demonstrate it, and even provided sample plaintext and cyphertext.
Dear Pohanl.
There are plenty of unbroken messages. Please explain why
the generated cipher will be difficult to break, using your method
of encryption.
>Well, I never realized that what I invented on the spur of the
>moment really is unbreakable.
Are you confident that it has not been published before?
>Well, if you look at most cells in your body, you notice that they have
>a cell wall, and inside contains the DNA and other goodies. Things are
>passed to the cell through the cell wall. This is very similar to
>passing variables to a component through an interface/function.
>
>This new language would have components with no constraints on values
>passed to it. as for the values, instead of being dedicated to a method in a
>component/class/function, it would be placed on a bloodstream/"bus".
>cells/components would grab it when they have appropriate functions
>that can use it.
A language with no constraints imposed on it, a language in which
any computation can be implemented, has a special name ... ...
The comparison between computational processes and living things
are unusual and interesting. J. von Neumann wrote in
von Neumann, J. "Theory of Self-Reproducing Automata"
Burks, A. (Ed), University of Illinois Press, Urbana, Illinois 1966
(quote from above reference)
>"The conclusion one should draw from this is that
> complication is degenerative below a certain minimum
> level. This conclusion is quite in harmony with other
> results in formal logics, to which I have referred a few
> times during these lectures...
> There is thus this completely decisive property of
> complexity, that there exists a critical size below which
> the process of synthesis is degenerative, but above which
> the phenomenon of synthesis, if properly arranged, can
> become explosive, in other words, where the synthesis of
> automata can proceed in such a manner that each
> automaton will produce other automata which are more
> complex and of higher potentialities than itself."
That is why a living cell can reproduce, but your money won't.
Do you make use of this in your encryption ? How ?
Do the size of your system affect the complexity of the codes
generated ?
[EMAIL PROTECTED] wrote:
>Well, (I need to repeat redundantly, so I can get to the point),
>this alorithm is unbreakable, because:
>1) It is exponentially expensive to search the keyspace.
>Unlike the garage door opener where you can permutate the bits
>until you find a match... THERE IS NO KEYSPACE YOU CAN SEARCH
>BECAUSE YOU DON'T KNOW WHEN THE KEYSPACE ENDS!
>THIS IS EXPONENTIALLY EXPENSIVE, and is secure from brute force
>keysearch.
You mess up your argument by setting Exponential Work != Brute Force.
Brute force is exponentially expensive. Your system will be secure
if you can should show that the best attack is equivalent to a brute
force search, on a sufficiently large keyspace.
>2) Base encryption algorithm is dynamic. Meaning? It can change
> on the fly. Most standard cracking alorithms relies on a fixed
> algorithm (DES, RSA, IDEA, etc ALL have fixed algorithms).
> Well, changing the algorithm in Base encryption is as simple
> as changing the operators.
>3) Base encryption is useful for streaming cyphers that are
> unbreakable. Because you can change algorithms on the fly,
> you can have the first segment use algorithm 1, base x, second
> algorithm use algorithm 2, base y, etc.
You don't have to "change the operators" to accomplish an encryption
system that evolve during an encryption operation. (Why?)
Explain how the "encryption algorithm" may "change on the fly".
Using a system where the encryption algorithm may be changed on
the fly is not new, see US-A-5742686 to Finley, Phillip Scott.
>When you mention you can try to use computers to try to permutate
>through dynamic algorithms and bases, you are not understanding
>the intractability of this problem.
>
>There are infinite combinations of operators (its dynamic, and
>there is not fixed number of them, and there is no fixed maximum
>number of operations you can use), which are within
>the exponential domains of symbol remapping and different bases.
Here, you complicate your system unnecessarily. You may achieve
your results using simpler means.
>Its intractable because you have an NP HARD problem.
>The two domains are each exponential and their relationship to
>each other is even more so.
>
>When you have infinite with infinite, no number of computers
>in the world can solve it.
Infiniteness do not add like ordinary numbers. Suppose that you have
an n-dimensional vector of Real numbers. An interesting fact is that
it is possible to make an unique and invertible mapping between the
n dimensional set of numbers {x0,x1,x2,x2,..xn} (n finite) onto a
single real 0<=z<=1. ("I see it, but I don't believe it", Georg Cantor
in letter to Dedekind June 29, 1877. (This works only for point
sets.)
A construction with the same effect using integers is a
File System, where a single integer (the file system or hard disk)
may contain a number of other files of different sizes. Based on
this, your two sets of countable entities (i.e. infinite) may be
equal in power to a single countable set.
>This is very similar to the eisenburg uncertainty principle and
>the quantum mechanic duality problem. The more you know one
>value, the less you know the other. The more you can pinpoint
>the location, the less you know about the speed. And vice versa.
"eisenburg"... Well I guess that you mean
Heisenberg, W. "The Perceptible content of the Quantum
Theoretical Kinematics and Mechanics"
"Uber den anschaulichen Inhalt der quantentheoretischen
Kinematik und Mechanik" Zeitschrift fur Physik 43, 172-198 1927.
(Heisenberg was somewhat disturbed by his discovery that
simultaneous observations of complementary quantities cannot be
both infinitely accurate, and went to Copenhagen to discuss this
with Niels Bohr, who argued Heisenberg to publish.)
See also Heisenberg, W.
"Die Rolle der Unbestimmtheitsrelationen in der mordernen Physik"
Monatshefte fur Mathematik und Physik 38, 365-372, 1931.
* * * * * * * * *
May 17, 2000
Bo Dömstedt
Chief Cryptographer
Protego Information AB
IDEON,Lund,Sweden
http://www.protego.se
------------------------------
From: Thomas Kellar <[EMAIL PROTECTED]>
Subject: UBS keylinkweb
Date: Wed, 17 May 2000 10:51:31 -0400
Is anyone on this news group familiar with UBS keylinkweb? I
have been asked to open two holes in our firewall pointing
to two servers to allow "payments" to be transfered. I am
not at all happy with opening holes, much less for possibly
proprietary protocols that transfer money. There is not
much on the UBS web sites:
http://www.ubs.com
http://www.ubs.ch
http://www.tradepac.ch
They mention SSL somewhere but if they are doing SSL why do
they need special TCP ports opened??
They mention EntrustDirectSSL, but that might just be a mention.
Actually, the security information on their web pages is
totally missing. Lack of trust. Lack of trust. Am I too
paranoid?
Thanks for any advise or help.
Thomas
--
w8twk Freelance System Programming http://www.fsp.com
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?
Date: Wed, 17 May 2000 10:49:37 -0400
[EMAIL PROTECTED] wrote:
>
> I am pretty convinced that some of the non random pattern of the
> plaintext shows up in the ciphertext...If that is the case, then XORing
> non-random data with a random key does not necessarily produce a random
> output.
You may feel free to be convinced, but you would be mistaken.
Go read Shannon...
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?
Date: Wed, 17 May 2000 10:48:56 -0400
William Rowden wrote:
> ...
> > As Bryan Olson pointed out, the mathematical explanation goes back
> > at least to Shannon's 1949 paper
>
> It seems Kahn's _The Codebreakers_ puts the invention of the OTP at
> 1917.
OTP was invented back then by Gilbert Vernam, but he didn't give
the proof. Shannon did that, in 1949; his paper specifically
mentions Vernam and quotes a paper by him from 1926.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Is NovaStar DataSafe using Blowfish encryption any good?
Date: Wed, 17 May 2000 10:56:23 -0400
Lorraine wrote:
>
> Is NovaStar DataSafe using Blowfish encryption any good?
>
> I need a program that is legal overseas,fairly easy to use for non-literate
> computer users and is not easy to break.
I don't know the program you mentioned, but Scramdisk (for
volume encryption) or PGP (for file encryption) should
meet your requirements.
paul
------------------------------
Reply-To: "Kenneth Cascio" <[EMAIL PROTECTED]>
From: "Kenneth Cascio" <[EMAIL PROTECTED]>
Subject: Re: Crypto & UNICODE???
Date: Wed, 17 May 2000 11:20:08 -0400
I appreciate the responce.
I think the UNICODE memory model I described comes from Charles Petzoldi
book Programming Windows 5th Edition... I will verify this. The
"little-end-first" representation of the multi-byte variables (i.e. least
significant byte first) was information I found in a Winsock 2.0 Programming
book. It described the methods of Intel based processors versus some others
for storing multi-byte variables. Can you refer me to a FAQ or book that
explains the method you are describing?
Thanks,
Kenneth CAscio
"Runu Knips" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Kenneth Cascio wrote:
> > I'm lost....
>
> If you're using ciphers which can't withstand plaintext attacks you're
> truely lost no matter what you do. The attacker ALWAYS can guess SOME
> parts of your plaintext. Thats why modern ciphers have to withstand
> them !
>
> By the way, one normally doesn't store unicode the way you've described
> it. Basically, one sets the msb of the first byte if the character is
> larger than 7 bit, saving the rest of the bits in the next character
> where again a flag is set if that character is still not enough. This
> way every unicode character is stored in 1 to 3 bytes on disk.
------------------------------
Date: Wed, 17 May 2000 17:22:23 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Chosen plaintext attack, isn't it absurd?
Manuel Pancorbo wrote:
> I mean, if the attacker is able to access the encipher machinery (but not
> the actual key) and then test the ciphertexts she wants, what stops her to
> access the DEcipher machinery?
Nobody said you're able to access that machinery ? The people specifying
messages and the people sending them are not necessarily the same ones.
So why can't you modify the message on the way from the ones to the
other ?
If chosen plaintext attacks are absurd, why are plaintext attacks okay ?
They are as 'absurd' in a way, aren't they ? Normally at the very start
you only have a ciphertext and maybe even no idea which algorithm was
used to encrypt it !
------------------------------
Date: Wed, 17 May 2000 17:25:33 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: QUESTIONS About ALGOS !!
Karim A wrote:
> But I have to make a choice between efficiency and speed !
No, you don't.
> Well I'd like to know if the DES / 3DES is a very fast algo ?
Its old and slow.
> I've been told that Blowfish algorithm was very fast and secure.
Blowfish is very fast in Software. Its key schedule is slow
which might be a problem under some circumstances.
> What do you think about it ?
Good ciphers are Rijndael, Serpent and Twofish. Might work
well in hardware, too. I'm personally fan of Twofish ;-)
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: What is the advantage of undeniable signature?
Date: Wed, 17 May 2000 08:35:09 -0700
David A Molnar wrote:
> B.T. <[EMAIL PROTECTED]> wrote:
> > Compare wtih the RSA or ElGamal digital signature,
> > what is the advantage of the undeniable signature?
> > The undeniable signature needs the signer's help to
> > prove the validity of the signature. Contrarily, RSA
> > or ElGamal doesn't need the signer's help. Anyone
> > gives some comments?
>
> ISTR that one example is a publisher of virus protection
> software which signs its updates with undeniable signatures. Then it
> validates the signature only for registered users. Unregistered users
> thereby have no way of telling whether a "new update" is genuine or a
> spoof, therefore they have an incentive to pay $$$ to the publisher.
One of those poorly-named concepts. Perhaps it should have
been called a "deniable signature" since it differs from
a regular signature in that the signer can deny it to most
parties.
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: Is OTP unbreakable?
Date: 17 May 2000 15:39:45 GMT
Simon Johnson <[EMAIL PROTECTED]> wrote:
>
>Now that is intresting, i wouldn't think random data had the maxmium
>possible information density, though it seems logical come to think of
>it.
Not just random, but equiprobable.
In fact, the rule for a one-time-pad is not merely that the
key must be "as long" as the plaintext, as the plaintext can
be compressed (or conversely, someone may foolishly choose
a key-file with redundancy in it.) Rather, the information
content of the key must be at least as much as the
information content of the plaintext source.
>Lets consider compression, the amount of data is reduced, but it
>contains more information, and the 'Surprise'factor, of course,
>increases.
No: the data is reduced (i.e., length of the file,) but
it contains as much "information" as when you started, if
the compression is lossless.
This is called the "Data Processing Inequality:"
you can never increase the information content of data
by processing it in such a way.
-Scott
------------------------------
Reply-To: "Kenneth Cascio" <[EMAIL PROTECTED]>
From: "Kenneth Cascio" <[EMAIL PROTECTED]>
Subject: Re: Crypto & UNICODE???
Date: Wed, 17 May 2000 11:58:24 -0400
It seems that many of you agree that algorithms like DES and 3DES are not
vulnerable to "Known Plaintext Attacks". Since I am very new to
cryptography, I can't argue that point - possibly someone else has another
positions. It will be at least the weekend before I can spend the time to
try an attack against this - I will try using DES and post a more detailed
example. The books I have started to read both explain that you must assume
that an eavesdropper knows you algorithm. A strong algorithm will withstand
a brute force attack but you can increase your chances of decrypting the
cyphertext by adding specific knowledge about the plaintext and/or key.
In my mind, an eavesdropper should be able to make the following assumptions
or acquire the following information:
(1) The system is using UNICODE and therefore, he can infer 1/2 of the
plaintext. (baring compression, I'm sure there are ways around that)
(2) The processor being used - where are the 0s or known bytes.
(3) The algorithm being used (i.e. DES, 3DES).
(4) He has access to the cyphertext.
(5) Key Size based on algorithm
Yes the 0s are insignificant to the message but I think you should be able
to determine the key using a simple cause and effect scenario. You know the
algorithm, many bytes of plaintext and their corresponding bytes of cypher
text; can't you determine the key used to create cyphertext with all of this
information or at least gain a significant edge? If it is not as easy as it
seems to me, than I am even more intrigued with the whole science of
cryptography..
Thanks to all for the dialog. I am on a quest for knowledge - nothing more!
Kenneth Cascio
"Kenneth Cascio" <[EMAIL PROTECTED]> wrote in message
news:q0kU4.26017$[EMAIL PROTECTED]...> ALL:
>
> I have been pondering a crypto issue that I can't grasp. If this is not
an
> issue, I would appreciate an explanation. Thanks in advance! Below is a
> detailed example of my problem:
>
> If I have a plaintext Message "ABCDEFG" (Represented in memory by 7-Bytes
> (HEX): 41, 42, 43, 44, 45, 46, 47) that I want to keep a secret (i.e.
> encrypt) and my application is using standard ASCII character strings (1
> byte per character), than an eavesdropper, unless he has other methods,
can
> not infer anything about my original message from the ciphertext.
>
> On the other hand, if my application is using UNICODE instead of ASCII,
the
> same message "ABCDEFG", now occupies 14-Bytes of memory (UNICODE is a
> multi-byte character) and is represented in memory (on an Intel based
> machine) as: 41, 0, 42, 0, 43, 0, 44, 0, 45, 0, 46, 0, 47, 0. Any
algorithm
> acting on this block of memory (now 14 bytes) will be encrypting the 0s
> which are now part of the message.
>
> The eavesdropper could now infer (if he knows anything about my system)
> parts of the original plaintext message. He/she could assume that the
> original message looked something like this: ?, 0, ?, 0, ?, 0, ?, 0, ?,
0,
> ?, 0. The "?" represents an unknown BYTE and the 0s are the known BYTES
> (zeros). Now, he/she knows half of my original message! With this
> information, I would think that a "Known Plaintext Attack" could be used
in
> an attempt to decrypt the ciphertext.
>
> I will be the first to admit that I am not a cryptography expert! I have
> asked everyone I could think of short of the NSA but keep getting
> non-answers, I don't knows, or blank stares. I did have one individual
tell
> me that it shouldn't be a problem but with NO explanation... I'm lost....
>
> Thanks,
>
> Kenneth Cascio
>
>
>
>
------------------------------
** 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
******************************
