Cryptography-Digest Digest #784, Volume #11 Mon, 15 May 00 17:13:00 EDT
Contents:
Counter-intelligence, fax encryptors and hidden chips (Markku J. Saarelainen)
Re: Unbreakable encryption. ([EMAIL PROTECTED])
Re: Is OTP unbreakable? ("Axel Lindholm")
Re: S-BOX Construction Tutorial? (Simon Johnson)
Re: Definition of "Broken" Cipher (Tom St Denis)
Re: AES on the AVR-RISC cpus? (Tom St Denis)
Re: Yet another sci.crypt cipher (Tom St Denis)
Re: Unbreakable encryption. (Tom St Denis)
Fradulent "Cyberscrub" statements regarding Evidence Eliminator Software (EE Support)
What is a good Encryption program?? (Lee Herfel)
Re: Snappy Block Cipher (key schedule) (Tom St Denis)
Re: Notes on the "Vortex" block cipher (Tom St Denis)
Re: What is a good Encryption program?? (S. T. L.)
Re: Encryption of graphics by transposition (wtshaw)
Re: Unbreakable encryption. (Paul Waserbrot)
security ([EMAIL PROTECTED])
Re: Unbreakable encryption. ([EMAIL PROTECTED])
Re: Unbreakable encryption. (wtshaw)
Re: Unbreakable encryption. (wtshaw)
Re: AES Comment: the Hitachi patent (wtshaw)
----------------------------------------------------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Crossposted-To: alt.security,comp.security
Subject: Counter-intelligence, fax encryptors and hidden chips
Date: Mon, 15 May 2000 18:57:21 GMT
Few interesting facts ...
1. The U.S. government is involved in counter-intelligence activities
and feeding results from these counter-intelligence activities to
private enterprises and individuals. These results are not limited to
the information of specific corporate intelligence systems, methods and
sources (including intelligence assets and resources), but specific
technologies and R&D activities in which specific companies that are
targeted by the U.S. government are involved.
2. Prices of fax encryptors are very high ( and all that I have
researched since 1997 use DES or other easily breakable algorithms
controlled by the NSA) and it is feasible to implement software
applications in all platforms to provide secure fax transmissions.
Again, the strongest security is necessary to prevent the U.S.
government's and particularly the NSA's eavesdropping and espionage
activities. The NSA is actively involved in controlling R&D activities
of fax encryptors. It is recommended to implement in all levels of your
business organization, the strong fax encryptor devices to secure your
communications.
3. Some of the smallest chips in the market in their size are just the
size of the point of my pen I am using every day. This makes it very
easy to hide these chips in cloths and other personal items for
tracking, information collection and other purposes. In fact, somebody
could plant one of these chips to you and/or your personal properties
you never knowing it.
Just few interesting facts .. I'll write more later, but now I have to
work ...
Yours,
Markku
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Unbreakable encryption.
Date: Mon, 15 May 2000 19:07:42 GMT
I think I will have to explain more for you to understand.
There are some basic things that you are either not
familiar with, or I have to be more detailed in my
explaination.
In math there are problem domains called NP and NP Hard.
I think most people are used to everything being linear.
Like this...
_______________________________________
This is linear: x+1=5
This is a little harder: x*x
This is exponential: x^y
Given the above, they seem to be simply dandy mixing of variables right?
Now, there is a concept of tractable and intractable problem domains.
Tractable problems are problems you can solve using brute force.
(like permutating through the keys)
Intractable problems are problems that it DOESN'T matter
how fast or how many computers you use, it is just not
solvable, because it is RECURSIVELY NP HARD.
I like to use the term Exponential instead.
Recursively NP Hard problems involve exponential relationships.
As an example... A fixed keyspace you can permutate through because
there is a linear relationship between one value and the next,
and there is a beginning and ending value for you to permutate through.
In exponential RECURSIVELY NP HARD PROBLEMS, it is not tractable
because to go from one value to the next it is exponential. In
addition, there is an exponential beginning to end relationship
(in essense, it is can on to infinity).
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.
What does this mean? You can use billions and billions of
computers, and it is still not tractable.
To illustrate: how many games are out there? infinite (more
are being created every day)
what order can you play two games? infinite (because you can replay
one then go to game two and come back to game one, and keep playing
until december, or maybe stop playing until next year, or maybe
after ten years)
What order can you play all the games? NP HARD (you are
combining the two exponential problems. Going from one game to
the next is already exponential (to infinity).
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. In the example above if you fix
the number of games, you still have infinite number of
order of playing them (there is no maximum number of time of playing
and no guarantee when you will stop).
If you fix the number of times playing (lets say maximum 5 games),
it is also infinite because there is no end to number of games.
When you put them together, it becomes simply intractable.
Now map this analogy with the order of operators, number of operators,
the base (to infinity), the conversion algorithm used between
base, the symbol set of the original base to the destination base,
you have an intractable problem. It is NP hard, and no number
of computers in the world could break it. Even the one-time
pad relied on just one symbol space.
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.
...
In reading the post you seem to also not understand what I
meant by base conversion. Base conversion involves two
things... symbol substitution and an algorithm (similar
to a few steps in a cypherblock).
Now, it happens that to do base conversion, you need
exponent operator, add operator, multiple operator, mod
operator, and divide (leaving whole number) operators.
There is a perdefined number of steps used to convert a
number from base x to base y. (very similar to steps
located in a cypherblock). It gets exponentially hard
when you get into floating points. Because doing floating
point conversion sometimes involves dividing numbers that
are infinite (for example 6.666666666666..... into 4.333333...)
in one representation (base) but not another.
The Virtual Calc 2000 supports infinite precision for floating
points of ANY base you choose. So 3.333333333333... may be
a number in one base, but after you convert it, it will be
totally different (especially using floating point arithmetic).
It might go into infinity, it might not (if it isn't representable
as a finite number of digits).
Now this just happens to use base conversion to map between one
base and another. The starting and ending base symbols could be
different. Also, there is no direct mapping between the beginning
base and ending base (EVEN IF THE SYMBOLS ARE SAME FOR FIRST X DIGITS).
I think you are missing out on this part.
If you have symbols 012345
and symbols 0123456789
(the first 5 symbols are same)
a number like 9 for the second number has no direct mapping to
the symbols to the first. It has to use a base conversion algorithm.
(and you can you any, base conversion is just one of the methods
to map between one symbol space and another).
And what about floating point representation? What if you input
2.3 for the first number and convert it to the second base?
The representation might go to infinity or not depending on
the base.
And note that in this example you had to know the beginning base
and ending base, and the correct order of the symbols within
each to even begin the known base conversion algorithm.
It is like trying to find the meaning of life when there
could be infinite number of them from infinite number of
people's subjective interpretations.
Like here...
http://www.edepot.com/life.html
There is just so many that guessing the algorithm used for the
real heavy duty operators used is just not possible (because
you can't permutate through the guesses).
So in conclusion get the main point... ALL the algorithms and
ALL the keylenghts of ALL the encryption algorithms used these
days have a weak link in that they are static, which mean
they can be brute force searched. Base encryption with variable
dynamic operators, symbol space, base conversion, etc is the
way to go. You can even make dynamic
base conversion routines if you want(and not base it on numerical
conversion), and switch it on the fly.
People scream about how this encryption is broken, and that
encryption is broken. Make it an intractable NP hard problem,
like BASE encryption, and RSA won't be giving out 10,000 for
winners anymore (there wont be any).
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Axel Lindholm" <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?
Date: Mon, 15 May 2000 21:32:59 +0200
OTP is as unbreakable as it gets! To class a cipher as OTP the cipher key
must have the same length as the message, random key and the key may only be
used once. Now if you were a cryptanalyst and i gave you the ciphertext
...DQ9vP... then, based on the above definition, using a simple xor alg.,
the original message could be ...hello..., ...mouse..., ...modem..., etc.
Any one of these are just as possible as anything else, that means that the
original message can actually be anything that have the same length as the
encrypted data since the key is compleatly random! No cryptoanalysis is
possible due to the facts that (1) there's only one block to analyse and (2)
the key is only used once, you'll never see a message that is encrypted the
same way again!
Axel Lindholm
<[EMAIL PROTECTED]> wrote in message
news:8forim$1h4$[EMAIL PROTECTED]...
> Is it possible to prove theoretically that OTP using a truely random key
> is unbreakable? I have not seen such a proof anywhere...just lots of
> statements that OTP is unbreakable....If there is a mathematical proof
> then I would be interested to know it...
>
> I know that Ritter distinguishes between a theoretical OTP and a
> practically realisable OTP....if OTP is that secure...why is it not used
> in practice ..or is it?. Does secure diplomatic traffic still use OTP?
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: S-BOX Construction Tutorial?
Date: Mon, 15 May 2000 19:33:47 GMT
Now i would have thought that having pesudo-random s-boxes would be a
good idea, simply because the attacker has no idea of the strength of
them, they could be strong they could be weak the attacker know no
different. Is this a safe assumtion to make?
=======
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Definition of "Broken" Cipher
Date: Mon, 15 May 2000 19:46:21 GMT
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
> > It's quite simple. You don't say your car is broken because of a
dent
> > in the fender right?
> >
> > Well if I can attack a cipher X, in 2^100 steps is it really broken?
> > Let's see, does it secure information? Yes. How is that broken?
> >
> > I think the definition of "broken" for a cipher is when finding the
key
> > and/or plaintext from ciphertext only is easier then brute forcing
the
> > key.
>
> Absolutely not. That's a dangerously weak standard.
>
> Chosen plaintext attacks are clearly feasible in practice in
> many cases. Known plaintext attacks have been used for centuries.
>
> > Let's be realistic, getting 2^50 pairs of plaintext/ciphertext is
not
> > possible for two reasons. a) Bandwidth, b) smart people re-key
their
> > ciphers.
>
> That may be true. Or maybe not. Remember how quickly the
> total throughput of the Internet is increasing.
However most sane protocals will re-key to avoid using the same key for
any long period of time. Say every 2^20 blocks....
> I think the reasoning goes like this: attacks only get better over
> time. Therefore, *any* weakness is an opportunity for ever more
> efficient attacks. Therefore, the prudent standard is "there exists
> no known attack better than brute force search of the keyspace".
True, but if you look at attacks on DESX, which require about 2^60 or
so plaintexts (or about 2^80 or so key trials, who wrote that paper on
analysis of DESX? I can't seem to find my copy), the attack while
already feasible (given extreme conditions) is not feasible in
practice, despite the attack(s) being in the open for quite some time.
Just like there is a 5-round differential on Twofish, so we shouldn't
use it?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: AES on the AVR-RISC cpus?
Date: Mon, 15 May 2000 19:47:17 GMT
In article <[EMAIL PROTECTED]>,
Runu Knips <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > Do any of the AES ciphers work with only say 64 bytes of sram?
>
> Twofish requires 64 bytes of ram PLUS some local variables of
> the algorithm. Thats even stated in the paper itself. One needs
> 32 byte for the up to 256 bit long key, plus 16 byte for the
> vector S of the paper, and another 16 byte (128 bit) for the
> company key.
>
Oh cool, will have to look into it.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Yet another sci.crypt cipher
Date: Mon, 15 May 2000 19:49:21 GMT
In article <[EMAIL PROTECTED]>,
Runu Knips <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > I sincerely with all my being hate the keyschedule I put into that
> > cipher.
>
> Whow. So much hate on a little innocent expression... which is IMHO
> really nifty.
Well the F function is nifty, but the original 'x + y + j mod 16'
sucked the big time. It didn't use the key bytes evenly...
>
> > [...] I am kinda scrapping the bottom of the barallel for a good key
> > schedule. Basically I want some permutation of 0..15 that is
algebraic
> > and takes three inputs (x, y, j) where (x, j) belong to 0..7 and (j)
> > belongs to 0..15.
>
> The thing I don't like about your kF() is that x doesn't influence
> bit 4 and y doesn't influence bit 1.
That's impossible todo evenly since x/y are 3 bits each. I could do
some through mixing (i.e use a 10x4 sbox) but I find this method uses
the key bytes very quickly and not in the same order over and over.
I am still looking for better kF() functions... (smaller and possibly
without sboxes...)
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 19:54:14 GMT
Yadadadadadad,
It's on a computer? Yes.
You have a limit of memory? Yes.
You have a limit of time? Yes.
Your problem is at best exponentional.
Wow modern symmetric ciphers are exponentional as the keysize increases.
You have yet to prove your method is secure... why not drum up some
source code to how I can use it, with a function like
Encrypt(ct, pt, key)
Where ct[1..n] and pt[1..n] is the output/input and key[1..x] is the 'x-
byte' key.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: EE Support <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security.pgp,comp.security.firewalls
Subject: Fradulent "Cyberscrub" statements regarding Evidence Eliminator Software
Date: Mon, 15 May 2000 21:08:11 +0100
Reply-To: [EMAIL PROTECTED]
A new USA company named "Cyberscrub" attempts to re-sell an old
Romanian secure-delete program named East-Tec Erasor from a new
Atlanta, Georgia Website.
Cyberscrub's web site uses a fraudulent comparison chart, claiming
falsely that our Evidence Eliminator software lacks many of it's
features, which it does in fact provide in full.
These false statements have been archived on our web site and are
available for public viewing with our options on the motives of the
Cyberscrub operation.
Full details and factual proofs are available via:
http://www.evidence-eliminator.com/forensic.shtml
Cheers,
--
Regards,
EE Support
[EMAIL PROTECTED] (remove NO_SP_AM for e-mail)
http://www.evidence-eliminator.com/
------------------------------
From: Lee Herfel <[EMAIL PROTECTED]>
Subject: What is a good Encryption program??
Date: Mon, 15 May 2000 20:09:34 GMT
I just want to encrypt a text file and un encrypt it readily and have it
be secure. What public programs are available that would do this? I
have dl'ed one from CNET.com that has DES encryption, I thought I had
read that that was breakable....
Any help would be appreciated, my email is [EMAIL PROTECTED]
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Snappy Block Cipher (key schedule)
Date: Mon, 15 May 2000 19:59:42 GMT
In article <8fns3v$c3$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> I posted an update to my Snappy Block Cipher to use what I think is an
> improved key schedule. You can get the mini-paper from
>
> http://www.tomstdenis.com/snappy.txt
>
> Tom
Did I mention this cipher takes 16 bytes of ram and uses only byte
operations? So if this cipher is strong, then it's quite usefull for
smart cards...
Hehehe... common I would like analysis of this cipher (or poking...).
Thanks,
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Notes on the "Vortex" block cipher
Date: Mon, 15 May 2000 19:57:09 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
>
> On Mon, 15 May 2000 13:39:08 +0200, in
> <[EMAIL PROTECTED]>, in sci.crypt Runu Knips
> <[EMAIL PROTECTED]> wrote:
>
> >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.
>
> That particular answer of mine would have been the same for any other
> cipher. The problem is not a particular cipher, the problem is in
> trusting something which cannot be tested to see how closely it comes
> to doing what we want it to do.
But that's true of *any* finite state machine. So therefore trust
nothing? I think that's a bit bitter. Realistic or not.
We need to send secure digital info, this is the best we can do. If
cipher X stops %99.999999 of all messages from being read then Iwill
be happy with it.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: What is a good Encryption program??
Date: 15 May 2000 20:13:31 GMT
PGP can.
-*---*-------
S.T. "andard Mode" L. ***137***
STL's Wickedly Nifty Quotation Collection: http://quote.cjb.net
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Encryption of graphics by transposition
Date: Mon, 15 May 2000 13:39:45 -0600
In article <8fohf3$n2e$[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (wtshaw) wrote:
> > ...; 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.
>
No, you don't. Block chaining is a patch, which means the underlying
algorithm has a hole in it. I suppose you could refer to the resuolt as
an angorithm, which makes supporting structures into mere primatives, like
as in APS, Advanced Primative Standard.
--
Secrets that are told or available are not secrets anymore, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
------------------------------
From: Paul Waserbrot <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
Date: 15 May 2000 20:39:47 GMT
[EMAIL PROTECTED] wrote:
Please, read +->Cryptography FAQ (02/10: Net Etiquette) and see how
to submit a cryptosystem or an algorithm to this newsgroup.
I won't even bother to try to read your postings again if you don't
cut the crap and give us something to read.
// Paul
--
------------------------------
Date: 15 May 2000 20:41:00 -0000
From: [EMAIL PROTECTED]
Subject: security
=====BEGIN PGP SIGNED MESSAGE=====
On Sat, 13 May 2000 17:41:17 GMT, [EMAIL PROTECTED] wrote:
>I have recently come to figure that I really need to have my data out
>of the hands of people who do not need to see my stuff.
>
>There seems to be two products. PGP and Blowfish. Can anybody tell me
>the difference between the two, which oneprovides more security as far
>as some one being able to break the code and read my stuff, I mean real
>smart people.
Others have explained the difference between blowfish and PGP.
A good program for encrypting files is Scramdisk:
http://www.scramdisk.clara.net/
If you'd like to try out PGP, check out www.pgpi.com
An alternative is GnuPG: www.gnupg.org - though last I checked they warn
against using this on windows.
If you're concerned with email privacy, use PGP. If you wish to keep your
mail anonymous, check out the products at www.skuz.net/potatoware. These
are clients for anonymous remailers and nym servers.
Katt
=====BEGIN PGP SIGNATURE=====
Version: N/A
iQEVAwUBOSBfr0hgZ0qbzxhRAQHjTwf/WPOhF98f4ZTn6dzBgYJIMWcdmsxJf1Hj
RAeu+1YK/j8k9+kINbAzK19zuAcWfMhgppU+UDL+/w1mxtem+IF7XYrtEghp08jq
dknpXmLdmNUZjbKJNIkOYBxMLVmeagNk0ar1+qWka1Ez3OG6QHGyOhJiOKy3l+NK
7IhBygdsd5Bo6LL55b08SLqLfEvvuC6SnfXKqRAVnNkLUbWVoJmQVxyfInaHpJjM
DOOaKDl2hbyU18f2Z9kxk7hTNVITrP4tnLVBCqR82/ny5+ofoxk6rXHHEiAdpV4i
FtmDpR/Idra6+g4YB8j2f2TRCtDjQdqwSw/SqEX/T+QybF9vj4zUuw==
=f7Sc
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Unbreakable encryption.
Date: Mon, 15 May 2000 22:26:31 GMT
In article <8fphtg$ro6$[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
> Now, there is a concept of tractable and intractable problem domains.
>
> Tractable problems are problems you can solve using brute force.
> (like permutating through the keys)
>
> Intractable problems are problems that it DOESN'T matter
> how fast or how many computers you use, it is just not
> solvable, because it is RECURSIVELY NP HARD.
>
> I like to use the term Exponential instead.
>
> Recursively NP Hard problems involve exponential relationships.
I do not believe it is the case that "intractable" is equivalent to
"RECURSIVELY NP HARD"
An algorithm's behavior in the limit has no necessary correlation with
its behavior for any finite problem size.
I do not believe it is the case that "RECURSIVELY NP HARD" is equivalent
to "exponential".
n^log(log(n)), for instance, is larger than any polynomial but smaller
than any exponential in the appropriate limit. A problem with this
complexity would be "RECURSIVELY NP HARD" but would not be "exponential".
Such a problem would probably -- though not certainly -- be tractable.
John Briggs [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Unbreakable encryption.
Date: Mon, 15 May 2000 13:59:05 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> [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
At least a sufferer of his own culture....we find other ways to accomplish
this in ours.
--
Secrets that are told or available are not secrets anymore, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Unbreakable encryption.
Date: Mon, 15 May 2000 13:53:33 -0600
In article <8fnto5$1nc$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> 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.
>
I understand that not all algorithms are symmetric in a traditional sense,
which is there are some that do have one ciphertext to one plaintext for a
given key.
> 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?
>
> And you have to break up the message into n-bit size to feed
> it into the cypher block right?
Bits may haveing nothing to do with it.
>
> So in essense the compression algorithm is basically taking the
> same symbol base and compacting it.
A trit compression scheme in the morse tradition is infinitely assignable.
>
...
> How do you start decrypting it using Base encryption?
> 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?)
> 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)
>
> So let me repeat...
>
>
> given...
> oisdd9823oieoisdg08eojiweljf##@98oefji23#@2jf
>
> how do you decrypt it?
>
Obviously this is all worth discussing to get at the basic principles you
are using. Pardon me for questioning some of your assumptions in your
explanation, but there is much to discuss.
--
Secrets that are told or available are not secrets anymore, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES Comment: the Hitachi patent
Date: Mon, 15 May 2000 14:16:19 -0600
In article <[EMAIL PROTECTED]>, Runu Knips
<[EMAIL PROTECTED]> wrote:
> I have heared about the Hitachi "patents" before, but I didn't knowed
> that they have tried to patent the addition !
>
Hatachi has a way of messing with other people's patents; it only stands
to reason that they might try to claim any territory that there is
unprotected. I remember...year's ago....many year's ago.....atleast read
about those events...well, more recently then that...a suit with Motorola
that Hitachi lost; I was rather invoved with some of those parts not too
many years ago, 68K programables. It is best for them to learn from their
mistaken mascho assumptions, not try to repeat them. NIST should best
kick these contemptable opportunists to the curb, so to speak.
--
Secrets that are told or available are not secrets anymore, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
------------------------------
** 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
******************************
