Cryptography-Digest Digest #776, Volume #11 Mon, 15 May 00 08:13:00 EDT
Contents:
Re: S-BOX Construction Tutorial? (Mok-Kong Shen)
Re: Definition of "Broken" Cipher (Mok-Kong Shen)
Re: S-BOX Construction Tutorial? (Terry Ritter)
Re: Notes on the "Vortex" block cipher (Terry Ritter)
Re: How does one test an encryption algorithm? (Runu Knips)
Re: Using TEA in one-way hash function ("adam pridmore")
Re: Notes on the "Vortex" block cipher (Tom St Denis)
Re: S-BOX Construction Tutorial? (Tom St Denis)
Re: Encryption of graphics by transposition (Tom St Denis)
Q: Searching for multiparty authentication protocols (=?iso-8859-1?Q?Tom=E1s?=
Perlines Hormann)
Re: Unbreakable encryption. (Paul Waserbrot)
Re: Unbreakable encryption. (Runu Knips)
Re: AES Comment: the Hitachi patent (Runu Knips)
Re: Q: Searching for multiparty authentication protocols (Tom St Denis)
Re: Unbreakable encryption. (Mok-Kong Shen)
Re: Notes on the "Vortex" block cipher (Runu Knips)
Re: Unbreakable encryption. (Mok-Kong Shen)
Re: Unbreakable encryption. (Tom St Denis)
Re: Unbreakable encryption. (Tom St Denis)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: S-BOX Construction Tutorial?
Date: Mon, 15 May 2000 08:07:31 +0200
Scott Fluhrer wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Another cost of having key dependant sboxes is key agility. If you either
> are using a different key to encrypt each different message, or if you use
> so many different keys that it is impractical to save the expanded key
> schedules, then how long it takes to set up for a particular key is
> important. And, having to compute what the S-boxes look like each time is a
> serious hit.
>
> Although, I must say that Twofish took an interesting approach. Perhaps
> other cipher designers should examine it.
Computing the random S-boxes can certainly be a substantial cost
that is to be counted on the negative side of that approach. On the
other hand, if one chooses to use fixed S-boxes, then I am of the
humble opinion that one should have different ones in different rounds.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Definition of "Broken" Cipher
Date: Mon, 15 May 2000 08:29:46 +0200
Tom St Denis wrote:
> It's quite simple. You don't say your car is broken because of a dent
> in the fender right?
It depends. Gates might change his car. On the other hand, there is a
good business in Europe buying cars that nobody wants to have and
selling these to some developing countries. Whether a cipher is good
to use depends on the application and your (more or less subjective)
judgement, I believe. Single DES is e.g. yet good enough for a fairly
wide range of applications.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: S-BOX Construction Tutorial?
Date: Mon, 15 May 2000 06:31:38 GMT
On Mon, 15 May 2000 04:31:57 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (John Savard) wrote:
>On Mon, 15 May 2000 02:09:39 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
>in part:
>
>>What are you talking about?
>
>>Every enciphering has some key. Any opponent might just try that key
>>at random. Does that make the cipher weak? Does that make the
>>keyspace non-flat?
>
>>Similarly, if we construct S-boxes such that they are a "random"
>>selection from among the universe of such S-boxes, does the fact that
>>one of these is the "identity transformation," others are close, and
>>many are somewhat linear make any difference at all (assuming the
>>universe of possible S-boxes is "large enough")?
>
>Actually, the fact that some S-boxes are close to being linear, while
>others are not, does mean that some keys are "better" than others in a
>way that is not applicable to a cipher like DES. (Although DES does
>have weak keys for another reason.)
Sure. And if we consider opponents who always start brute force
keysearching with the same key, then our use of that key will be weak.
But we don't know which key the opponents will start with, and we are
forced to use *some* key. Nevertheless, one of the keys in the
universe of all possible keys -- in fact whole groups that the
opponents will search -- will be "weak." In that sense cipher
keyspaces are *always* non-flat, and we accept that.
I think it would make sense to object to a probabilistic design if
provably secure designs existed. But since they do not, I think we
find that any alternative to a probabilistic design is worse.
>This has been used as a reason - or as an excuse - for not using
>key-dependent S-boxes in ciphers.
>
>Given a reasonable amount of known plaintext, if a cipher is designed
>so that its security depends on having S-boxes that are random, but it
>happens that the key being used has produced nearly linear S-boxes,
>then in that case there will likely be a detectable pattern. This is a
>danger, a source of unpredictability. It would be better to have a
>cipher that was equally secure whatever the key - of course, any key
>might still happen to be the one the opponent will try first, but that
>involves a much smaller number of cases.
Not at all: When the opponents brute force keys, they can try as many
keys as they want, or have time or equipment for. But to make use of
a possible linearity in the system, they must wait for a user to
create that linear system. The opponent cannot improve that
probability, it is built into the design. And if we can get the
opponents to make that check -- which almost never works -- we force
them to waste effort on each and every message. And if -- against all
odds -- they do find such a system, they get one message.
>There are, of course, two easy remedies. One is to make the
>probability of S-box failure vanishingly small,
Which happens automatically in "8-bit" tables.
>and the other is to
>have other elements in the cipher that maintain its security even in
>that case.
Which happens if we depend upon multiple independent tables.
>Another possibility is to choose a method of S-box
>generation that avoids "bad" S-boxes; the problem there is that often
>methods to do this are chosen that are too simplistic.
Far worse is the reality that we *can* not know every possible problem
with an s-box; we can only test for problems we know. That means
unknown problems will not be tested out, so this method simply *can*
not be relied upon. That algorithm is faulty.
Now, do we "improve" the table-space by removing tables we know to be
weak (in the context of our particular cipher)? Maybe, but all
ciphering is a tradeoff between time and computation. We can always
make a cipher stronger by adding more layers, but at some point we
will decide to not add another layer because the most usable ciphers
are fast. If we have to check each table for all possible weaknesses,
we can probably make 4 times as many tables in the same amount of time
by not checking. And if the probability of weakness is very, very
small -- as it is -- it makes more sense to use multiple independent
tables than to check each one. We "just" (!!!) arrange things such
that multiple unbelievably rare events must occur simultaneously for
linearity weakness to occur.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Notes on the "Vortex" block cipher
Date: Mon, 15 May 2000 06:41:59 GMT
On Mon, 15 May 2000 02:38:56 GMT, in <8fnnvu$s29$[EMAIL PROTECTED]>, in
sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Terry Ritter) wrote:
>>
>> On Sun, 14 May 2000 21:14:48 GMT, in <8fn500$82o$[EMAIL PROTECTED]>, in
>> sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>>
>> >In article <[EMAIL PROTECTED]>,
>> > [EMAIL PROTECTED] (Terry Ritter) wrote:
>> >>
>> >> On Sun, 14 May 2000 15:45:04 GMT, in <8fmhlt$k30
>$[EMAIL PROTECTED]>, in
>> >> sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>> >>
>> >> >[...]
>> >> >Yeah but in blowfish all of the input goes thru the sboxes. So
>you
>> >> >can't just say "Blowfish is similar so my cipher must be secure
>too".
>> >>
>> >> ...especially since there is no way to know that Blowfish is
>secure in
>> >> the first place.
>> >
>> >There has been some scrutiny of blowfish. I would trust it.
>>
>> You can wish and hope and believe what you want, but there still is no
>> scientific basis for such trust.
>
>By that same token, never drive a car, ride a bus, fly a plane, get in
>an elevator, etc.. because you would have to trust those engineers too.
Nonsense. That is *not* the same at all:
In all normal fields of engineering design (and I am a professional
engineer), engineers can test their work. Most designs will have
specifications, and the resulting equipment can be tested to see if it
meets those specifications. In most areas of life, we can detect
design bugs simply because the machine (including software) does not
do what we want it to: it does not meet specs.
But in cryptography -- alone out of all fields as far as I know -- we
cannot *know* whether a cipher will keep our information from our
opponents. Indeed, we do not even know who our opponents are, nor can
we know their capabilities. We thus *cannot* test that a cipher does
what we use a cipher to do. We can only test things like "can it
encipher any possible thing," "can it decipher every possible
enciphering," and measure "how fast does it work." But that is not
what we use a cipher to do. We use a cipher to keep our information
secret, yet we can't know whether or not it does.
We can trust other systems in our lives because we can see that they
do what we want them to do. We cannot know that about cryptography.
And neither can the "experts." So we are ill-advised to trust.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Date: Mon, 15 May 2000 11:11:12 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: How does one test an encryption algorithm?
Mark Wooding wrote:
> Richard Heathfield <[EMAIL PROTECTED]> wrote:
> > > Or use one of those well-tested algorithms already available, such
> > > as Blowfish, or Rijndael, Serpent, Twofish, or others.
> >
> > Yeh yeh yeh, and how much fun is /that/ for a programmer? :-)
>
> Actually, I found both Rijndael and Twofish to be rather interesting to
> implement. They took me about a day's work each, from blank source
> files to an implementation which passed the AES test vectors, and lots
> of the hair-tearing and head-slapping which I find tends to accompany
> debugging of crypto primitives.[1]
Hmm I needed weeks until my Twofish implementation passed all tests on
all architectures in my reach, fulfilled my ideas about performance,
and well my ideas about readability are still not fulfilled by it ;-)
------------------------------
From: "adam pridmore" <[EMAIL PROTECTED]>
Subject: Re: Using TEA in one-way hash function
Date: Mon, 15 May 2000 10:57:06 +0100
>
> or can i use the "modified Davies-Meyer" that bruce schneider say in 18.11
> of applied crypto, but using TEA instead of IDEA???
>
Or you could use Tandem and Abrest Davies-Meyer with XTea, with a larger
output of 128-bit.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Notes on the "Vortex" block cipher
Date: Mon, 15 May 2000 09:49:22 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
> Nonsense. That is *not* the same at all:
>
> In all normal fields of engineering design (and I am a professional
> engineer), engineers can test their work. Most designs will have
> specifications, and the resulting equipment can be tested to see if it
> meets those specifications. In most areas of life, we can detect
> design bugs simply because the machine (including software) does not
> do what we want it to: it does not meet specs.
Hindenburg. Nuff said.
You are trying to tell me everything engineers do is flawless? Shaw-
right.
There is some science behind cryptography whether you want to believe
it or not.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: S-BOX Construction Tutorial?
Date: Mon, 15 May 2000 09:51:13 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> On Mon, 15 May 2000 02:37:52 GMT, Tom St Denis <[EMAIL PROTECTED]>
> wrote, in part:
>
> >Replace the sboxes with ones from CAST and you have a 'more' secure
> >block cipher.
>
> Well, you eliminate one attack, but with known S-boxes, surely you are
> now admitting many others.
Not really. CAST and Blowfish are remarkedbly similar. CAST AFAIK has
yet to be even nudged in the ways of cryptanalysis.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Encryption of graphics by transposition
Date: Mon, 15 May 2000 09:53:42 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> In article <8fmnji$qht$[EMAIL PROTECTED]>, Tom St Denis
> <[EMAIL PROTECTED]> wrote:
> >
> > This makes no sense whatsoever. Try encrypting a two-color image
with
> > Blowfish and tell me when you see the Mona Lisa.
> >
> Something simple like a large black circle in the middle of a white
field
> illustrates what I am talking about; a rough pattern of the blocks
will
> tend to include the same ciphertext for all white areas, a different
> characteristic ciphertext for all black areas, and mixed results for
> blocks on the boundaries.
Oh ic....Then just use a chaining mode.
tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: =?iso-8859-1?Q?Tom=E1s?= Perlines Hormann <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Q: Searching for multiparty authentication protocols
Date: Mon, 15 May 2000 12:45:13 +0200
Hi!
I am searching for any information on DH-key exchange improved for
multiparty usage. I want to have a secured multiparty session encrypted
with a symmetric algorithm and need therefore a protocol to exchange the
session key between the user and authenticate themselves as well.
I guess DH may well be suited for my application, but I need further
information on papers and other stuff to be sure to choose the best
solution available.
Do you consider Kerberos authentication framework to be setup in such a
way?
Thanks in advance for your help!
--
Quick answering: mailto:[EMAIL PROTECTED]
Check it out: http://www.weh.rwth-aachen.de/~tomas
Do it Now!
:o) Tomás Perlines (o:
------------------------------
From: Paul Waserbrot <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
Date: 15 May 2000 11:05:50 GMT
[EMAIL PROTECTED] wrote:
> 1) You don't know the algorithm used (its dynamic), so you
> don't have a starting point.
Hm, and where is the source? I haven't seen anything that states
that this is the solution to all our crypto problems...
// Paul
--
------------------------------
Date: Mon, 15 May 2000 13:26:04 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
[EMAIL PROTECTED] wrote:
> [...]
The only unbreakable encryption is OTP.
------------------------------
Date: Mon, 15 May 2000 13:35:10 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: AES Comment: the Hitachi patent
Bruce Schneier wrote:
> The concept of rotation in encryption was clearly neither novel nor
> unobvious at time these patents were filed. The fact is that EVERY
> microprocessor opcode has been considered for use in encryption, with
> rotation being just one example.
I have heared about the Hitachi "patents" before, but I didn't knowed
that they have tried to patent the addition !
> This particular example is a counter to the "IP attack" argument
> espoused by some as a reason to select multiple AES algorithms instead
> of a single one. It is most likely that IP attacks, if any, will be
> based on very broad and ambiguous claims (like those of Hitachi) that
> the patent holder attempts to apply to all encryption systems.
*Sigh* I really hate patents. Only rich people can get them and keep
them, and they really don't use it for what patents where introduced.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Q: Searching for multiparty authentication protocols
Date: Mon, 15 May 2000 11:32:06 GMT
In article <[EMAIL PROTECTED]>,
=?iso-8859-1?Q?Tom=E1s?= Perlines Hormann <[EMAIL PROTECTED]>
wrote:
> Hi!
>
> I am searching for any information on DH-key exchange improved for
> multiparty usage. I want to have a secured multiparty session
encrypted
> with a symmetric algorithm and need therefore a protocol to exchange
the
> session key between the user and authenticate themselves as well.
> I guess DH may well be suited for my application, but I need further
> information on papers and other stuff to be sure to choose the best
> solution available.
>
> Do you consider Kerberos authentication framework to be setup in such
a
> way?
>
> Thanks in advance for your help!
Unless your private DH portion is fixed (and thus your public as well)
you can't authenticate yourself with plain vanilla DH.
In applied crypto there is a description of multi-party DH, it requires
alot of inter communication though..
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
Date: Mon, 15 May 2000 13:50:15 +0200
[EMAIL PROTECTED] wrote:
> Here is more...
>
> A New language...
Are we in a group comp.lang.xxx ?????
M. K. Shen
------------------------------
Date: Mon, 15 May 2000 13:39:08 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Notes on the "Vortex" block cipher
Tom St Denis wrote:
> There is some science behind cryptography whether you want to believe
> it or not.
And I think his dislike of Blowfish is only instinctive. I would trust
Blowfish, too. It only requires a little bit too much resources for
some applications.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
Date: Mon, 15 May 2000 13:53:34 +0200
[EMAIL PROTECTED] wrote:
> I mentioned that in Chinese languages (which is like a pictograph
> language), there are over 50 thousand characters compared to
> ascii (less than 255). If you take a Chinese language newspaper
> and think of it as an encryption algorithm, you would have a
> hard time decrypting it because there is no direct mapping between
> chinese characters and multiple ascii texts unless you get a dictionary.
It follows that any Chinese capable of reading newspapers is an
excellent cryptanalyst.
M. K. Shen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
Date: Mon, 15 May 2000 11:54:01 GMT
In article <8fnto5$1nc$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> My post must have been unclear to you. Let me explain in another
> way.
>
> You need not use 16=F, you can remap 17=F, or 104=F or 222=F
> or anything for that matter. This is called symbol remapping.
> Its supported in the calc if you are interested in testing it.
Actually it's called substitution, not symbol remapping.
> Also, you seem to have missed the major point... Fixed keylength
> cyphers and fixed symbols table cyphers can be brute force searched.
> the keys decryption and encryption are symmetric. Whereas, using
> base encryption, you don't even have something to brute force search
> through.
>
> 1) You don't know the algorithm used (its dynamic), so you
> don't have a starting point.
Technically I can just try all valid encryption algorithms. So your
method can be brute forced too. Also you can get into the notion that
some keys make bad algorithms. Also this method is very bad for
embeded software or hardware.
> 2) You don't know the base, so you also don't have a starting point.
I can guess.
> Lets say I give you this...
>
> oisdd9823oieoisdg08eojiweljf##@98oefji23#@2jf
>
> In or whatever, what you would do is start permutating the
> keys (lets say 56 bit) starting at
>
> 0000000000 0000000000 0000000000 0000000000 0000000000 000000
>
> and end at
>
> 1111111111 1111111111 1111111111 1111111111 1111111111 111111
>
> You pipe this through the fixkeylengh cypherblock, and eventually
> you will get your decoded message.
>
> Well, lets say I gave you the same message encrypted using
> BASE encryption.
>
> Where do you start? You don't know whether
> oisdd9823oieoisdg08eojiweljf##@98oefji23#@2jf
>
> is base 100 or base 200 or any base for that matter. Remember,
> just one increase in the base (symbol space) changes the answer in the
> cyphertext. This involves not just standard mappings, (like you are
> used to 16=f). You can remap the input and output characters.
> But then you also forgot about the algorithms that are applied to it.
But I can just try different bases... you seem to forget that. And
simple substitutions hardly make for 'secure' algorithms.
> It can be considered an encryption algorithm because
> 1) It does symbol substitution for remapping (which is the most basic
> form of encryption. I think Ceasar used it)
> 2) It uses base conversion (or any algorithm you can think of) for
> basic base conversion (symbol conversion)
> 3) It uses any combination of operatiors as the actual heavy duty
> encryption. (you can use rotation, shift, add, subtract, invert,
> a compression algorithm, ANYTHING).
But base conversion is NOT a substitution of value. You are
converting 'x' to 'x'. Just changing the way you show it. Technically
they are the same freaking value!!!
Also how do you make 'dynamic' algorithms that are secure? Is it
automated from the user supplied key?
> Which means what? It is more secure than DES or Blowfish without
> even the different symbols space (base). That is because
> the Base encryption algorithm used is dynamic, it can be changed on
the
> fly. Whereas all the other cypherblock encryptions use standard
> routines (rotate, xor, etc) in a fixed sequence.
Use standard routines.... designed to be secure!!!
You have yet to show that is a weakness. Remember it's one of those
laws of cryptography that security by obscurity doesn't work.
> Remember, dynamic algorithm is more secure than static algorithms.
You have yet to prove that. Also you have yet to state how
your 'dynamic' algorithms are made.
> You seem to misunderstand the major point....
> ALL the algorithms and ALL the keylengths of ALL the encryption
> systems are static. This is the most unsecure
> part. It is the weak link for brute force searches.
But so is your method. It's on a computer it's *finite*.
> And to answer your n-bits input and n-bits output. Think of it
> this way... it will clearify my point.
>
> What is the symbol set used before the compression to n-bits?
> What is the symbol set used to decompress the n-bits back to regular
> text?
>
> They are the same aren't they?
>
> And they are both N bits right?
No I could pack 100 bits of ascii into that n bit block. The 'symbol'
set of the input/output of the cipher is just any n-bit number. Not
the proper subset of ASCII values.
> And you have to break up the message into n-bit size to feed
> it into the cypher block right?
>
> So in essense the compression algorithm is basically taking the
> same symbol base and compacting it.
>
> Well, you can do the same thing before feeding it into BASE
> encryption (it will make it even more secure).
> Base encryption can be augmentative, and go on top of or below
> existing algorithms if you think universally about it.
Augmentative? That makes no sense. If you are talking about multiple
encryptions you are way behind the game. two-key tripple DES has been
out for quite some time now.
> Also. BASE encryption is not n-bits, its not fixed. You can FEED
> THE WHOLE MESSAGE INTO IT AT ONCE. It is DYNAMIC bits.
> The bit size is variable, affected by BASE (symbol set), algorithm
> used before and after base conversion (or any other conversion).
So you are telling me I give you a 2^24 bit message your method is more
secure and faster then blowfish? Shaw right... Try making a 2^21 byte
number and dividing it in a fast mannor. You will have to break the
message up to encrypt in a realistic fashion.
> So let me repeat...
> given...
> oisdd9823oieoisdg08eojiweljf##@98oefji23#@2jf
>
> How do you start decrypting it using Base encryption?
I guess your base and algorithm. There is a finite number of both.
> You can't right? You have to guess
> 1) The Base of this message (now did he use base 26? or standard
> ASCII, or some large base with duplicates? or a chinese unicode?)
> (And is this the result of base 26 or some other base?)
Yeah but the number of usefull bases is not unlimited. You can't use
base 10^100 and get a different output.
> 2) What is the conversion algorithm used to remap between the above?
> 3) What is the actual algorithm used. (shift, rotate, add, 1/x)
> and was it before base conversion or after?
>
> In essense, you CANT start anywhere. Because the algorithm is
> dynamic (its exponential, even more so than the standard key
remapping)
Again, I can guess your algorithms, there is a finite amount.
> So let me repeat...
>
> given...
> oisdd9823oieoisdg08eojiweljf##@98oefji23#@2jf
>
> how do you decrypt it?
Again I repeat, guess the base and algorithm.
Let me ask you something: How are you making these 'dynamic'
algortihms anyways? If you answer 'recompile the software' you are
dead freaking wrong. If you answer 'from the user supplied key' that
is more practical. If you answer the latter though.... there is a key
space.
I mean how do I pass it the secret information to your cipher? I have
to give it a base 'x' and an algorithm 'A'. There is a finite number
of both, which means I can search both. Or I can search the seed you
use to make either.
Also remember that just converting from one base to another doesn't
change the value of the text. 0x0F = 15 = 1111b, etc... They are all
the same value. if I give you '1e' there is only so many bases you can
try before you get the same mappings...
I think your method is the biggest load of @@!! I have seen in the
longest time. You don't even have the faintest notion of what a cipher
is supposed todo, let alone look like, I mean, where is your key
schedule? What is the actual encryption algorithm? Oh that's right
you magically come up with the same info on both sides to
encrypt/decrypt.
Bah, stop posting this nonsense.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
Date: Mon, 15 May 2000 11:54:58 GMT
In article <[EMAIL PROTECTED]>,
Runu Knips <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > [...]
>
> The only unbreakable encryption is OTP.
>
No but base conversion is the magic solution we have all been looking
for.
I can hardly believe the original poster was serious....
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
