Cryptography-Digest Digest #662, Volume #11 Sat, 29 Apr 00 14:13:01 EDT
Contents:
Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (Tom St Denis)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Tim Tyler)
Re: How would a 15 year old start? (Tom St Denis)
Re: As long as we are asking naive questions... (wtshaw)
Re: A naive question (Mok-Kong Shen)
Re: sci.crypt think will be AES? (Vernon Schryver)
Re: Intel drops serial number (Vernon Schryver)
Programs needed to start? ("Monolo")
Re: factor large composite ([EMAIL PROTECTED])
Re: Programs needed to start? (Tom St Denis)
Re: factor large composite (Tom St Denis)
Re: How would a 15 year old start? (David A Molnar)
Re: How would a 15 year old start? (David A Molnar)
Re: sboxes for the bored... (Tim Tyler)
Of Mountains and Molehills (wtshaw)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Janet and John learn about bits (was Re: Problems with OAP-L3)
Date: Sat, 29 Apr 2000 16:43:52 GMT
Richard Heathfield wrote:
>
> Anthony Stephen Szopa wrote:
> >
> > "Douglas A. Gwyn" wrote:
> > >
> > > Tom St Denis wrote:
> > > > 3) Why perms of 0-9? You waste alot of space that way, why not 0-16 or
> > > > 0-255?
> > >
> > > Yes, that is an obvious question that deserves an answer.
> > > I have my own theory as to the *real* answer to that,
> > > but let's use this question as a "litmus test" to see
> > > whether OAP-L3's author sincerely wants us to understand
> > > his system.
> >
> <snip>
> >
> > I am not sure if it is in the Help Files but it is in the patent
> > application that there is no restriction on number base. Base 16
> > could be used. The problem with Base 16 is that there would then be
> > 16! possible unique permutations of the hex digits 0 - 15 and current
> > pc computers are too slow to take advantage of the greater security
> > Base 16 would provide. Also storage requirements may pose a problem,
> > etc.
> >
>
> [Disclaimer: I'm not a cryptologist.]
>
> I find it surprising that anyone can attempt to defend their
> cryptographic technique when they don't understand about
> security-in-the-key, or killfiles (Mr Szopa's killfile seems to work
> more as a slightly-woundedfile) - but when they don't even understand
> about storage requirements, surprise is no longer adequate and, like Mr
> Adams, I am forced to resort to astonishment.
>
> Let's deal with the "storage requirements problem" first. And it looks
> like we'll have to go back to first principles to do so.
>
> Most modern computers use lots and lots of bits, each of which can store
> one of two values, 0 or 1.
>
> A combination of four bits is required, therefore, to store the digits 0
> through 9.
>
> 0000 - 0 0001 - 1
> 0010 - 2 0011 - 3
> 0100 - 4 0101 - 5
> 0110 - 6 0111 - 7
> 1000 - 8 1001 - 9
>
> The numbers 0 through 99 can thus be represented in one 8-bit byte.
> (Bytes need not be 8 bits, but I see no need to go down that road right
> now.) To store a value such as 16304791, then, we need 4 bytes. This
> encoding system (or a slight modification of it) is sometimes known as
> binary coded decimal.
>
> If we extend our numbering sequence to encompass the hexits A, B, C, D,
> E, F to represent 10 through 15 decimal, we can extend our 4-bit table
> to include
>
> 1010 - A 1011 - B
> 1100 - C 1101 - D
> 1110 - E 1111 - F
>
> We can now store values 0 through 255 in one 8-bit byte. Much more
> efficient. We can now store 16304791 in hexadecimal as F8CA97, giving a
> storage requirement of only 3 bytes.
When you do something like
long a = 16304791;
You need not convert it to hex to store it. My complaint about the
waste of space is that a permutation is normally stored as
int perm[10] = { ... }
and you store them serially (even as 4 bits you are wasting space).
Also note that not all numbers between 0 and 2^24 - 1 (3 bytes) are
possible so again you are wasting space...
My point was why doesn't he use a permutation of a power of two and not
waste space? Like 0..7 or 0..15 ?
> It is therefore more efficient to store values in base 16 than in base
> 10. More values can be stored in fewer bytes, because no bits are
> wasted.
This is not true.
> If your algorithm is such that you need factorial(NUMBER_BASE) bytes or
> nybbles of storage, then your claim that you can use any number base is
> clearly false. Even using base 10, are you seriously telling me that you
> need (either 1.75 or) 3.5 Megabytes of memory or disk space (10! is
> actually 3628800), just to /encrypt/ stuff? What planet are you on? In
> the real world, we like our utility applications to use less memory than
> that. A lot less. Remember that encryption provides no benefits. It only
> stops other people reading your stuff. That's not a positive benefit,
> just a (perhaps vital) prevention mechanism. Important, but not
> something that adds value to an enterprise. So it should be as
> unobtrusive as possible. 3 megabytes is not unobtrusive.
This is true.
> Now let's address the other point, that of speed. I have several
> computers in my study. The most powerful is a Pentium II/400MHz machine.
> Admittedly, it runs Windows NT, but nevertheless it's still pretty
> quick.
>
> If we have two cryptography applications, one of which uses its memory
> efficiently, runs on my PII/400 at an acceptable speed, and offers me
> reliable security, and the other which doesn't use its memory
> efficiently, runs on my 400 MHz box at a speed which even its author
> says is far too slow, and is based on source code which has not been
> published and therefore has not had the chance to be validated by the
> cryptographic community - thus making its security untrustworthy - which
> application do you think anyone with a brain will buy?
Or just use. Why do you have to buy good crypto programs? If you have
enough time on your hands you can even write your own.
Mr Szopa has some thinking todo about making his algorithm(s) not only
public but efficient.
Tom
--
Want your academic website listed on a free websearch engine? Then
please check out http://tomstdenis.n3.net/search.html, it's entirely
free
and there are no advertisements.
------------------------------
Crossposted-To: talk.politics.crypto
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Reply-To: [EMAIL PROTECTED]
Date: Sat, 29 Apr 2000 16:35:32 GMT
In sci.crypt Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
: Taneli Huuskonen wrote:
:TH> No, I didn't. I was careful to distinguish between the pseudorandom
:TH> digit generator, which is part of OAP-L3, and the whole of OAP-L3.
:TH>The former is definitely insecure. [...]
: You are mistaken when you claim that "The former is definitely
: insecure."
: How can the random digit generator be insecure when its output is not
: used to encrypt messages? It is not exactly the same, but the
: ridiculousness of your position is just as ridiculous as someone
: claiming that a safe is not secure because of the combination: someone
: can get in the safe if they have the combination. You want the
: combination to the random digit generator once removed (the random digit
: output) then claim that it is insecure. Insecure from what? [...]
Your question appears to be rather basic.
Random number generators do /not/ need to be used for encrypting messages
to be insecure - they have numerous other uses.
A PRNG is generally considered broken if the seed can be determined from
a stretch of its output much more rapidly than through a brute-force
search of the seed-space - or if statistical predictions can be made
about unseen PRNG output before the period is reached.
If the break is such that it can be performed in practice by an attacker,
this results in insecurity of the generator.
http://www.counterpane.com/pseudorandom_number.html is a useful resource
for attacks on PRNGs.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: How would a 15 year old start?
Date: Sat, 29 Apr 2000 16:46:03 GMT
Monolo wrote:
>
> As I said, in my pervious post, I would love to learn, I read Tom's post
> back to me after I sent it, sorry for the duplication. I was wondering, what
> would be the best way to start? Are there any good online resources?
>
> JJ
Take a peek at Terry Ritters' stuff...
Learning Crypto
http://www.io.com/~ritter/LEARNING.HTM
Glossary
http://www.io.com/~ritter/GLOSSARY.HTM
He has put alot of time into them, and they are worth reading. If you
want some books check up "Handbook of Applied Cryptography" published by
CRC Press and/or "Applied Cryptography" by Bruce S.
Tom
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: As long as we are asking naive questions...
Date: Sat, 29 Apr 2000 09:53:15 -0600
In article <8eee3m$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Guy Macon) wrote:
> My extremely limited messing around with crypto has shown me that in
> some systems encrypting twice with the same algorithm and key turns
> the plaintext into itself. My first naive impression of multiple
> encryption with different algorithms and keys would make the attackers
> job much harder. But would it? Could it be that some common elements
> that I don't understand are undoing each other, making the result easier
> to crack rather than harder? I am very wary of deviations from normal
> practices when I am dealing with things that I don't fully understand.
> In many fields the real expert can break the rules because he knows the
> details, but a newbie needs to stich to the rules until he knows which
> ones can be broken under certain conditions.
An expert in one narrow area of cryptography can be naive in others; a
person with general training is apt to still know little about many
areas. Speaking of chances, you have as good a chance as any to logically
derive the information you desire. The key ingredient is determination
and time, and not trying to duplicate the skewed ambitions of someone
else.
Your observation about the danger of cyclic phenomena is fundamental,
missed by many. The espert may break the rules, only to find that they
ultimately apply, or encumber himself with rules that miss the point; too
many learned crytographers are rather cumpulsive in their letting own
dogma lead them astray, highly unscientific.
--
Laughter is often the most pleasing result of successful analysis.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A naive question
Date: Sat, 29 Apr 2000 19:05:34 +0200
John Savard wrote:
> Mok-Kong Shen wrote, in part:
>
> >Like mixing water into whisky,
> >the qualtity of each cup of the drink rapidly deteriorates as
> >more water is involved. Is this line of thought reasonable?
>
> Only one aspect of the quality deteriorates rapidly:
> information-theoretic security.
>
> With DES as the cipher, though, brute-force search is possible, and so
> the total quality is affected. With a larger key to begin with, and a
> good cipher, overall security doesn't deteriorate so rapidly, because
> there is the question of the work factor in breaking the message:
> Shannon's paper is where you should look.
>
I am afraid that the 'rapidity' must be considered a more or less
subjective
issue here. Anyway, it is difficult to assess, I believe, as long as the
strength
of a cipher evades rigorous measument in practice. However, I conjecture
that if a key is used to encrpt a long message, it will at least give the
opponent
a possiblity of massively parallelly applying his analyzing tools to the
various
blocks, in case his computing resources permit that.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: sci.crypt think will be AES?
Date: 29 Apr 2000 09:20:44 -0600
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> ...
>>Yes, but in the case of those examples, at least a couple were clearly
>>less than novel.
>
>Perhaps *you* have checked out the claims of those patents (in the
>context of their body), but *I* sure haven't. Absent that, I am
>unwilling to make the uninformed judgment you seem to want.
That's mighty convenient for someone who recently claimed:
] Since I already have patents, I don't have to *argue* that I *thought*
] I have something new and unique; that has been confirmed.
The two URL's I offered are damning evidence about Mr. Ritter's claim that
his idea has been confirmed new and unqiue. One URL is about finding the
head of a circular list in two of ways known to any programmer who has
ever read anything about garbage collection. The following is from the
"SUMMARRY OF THE INVENTION" of the other:
The main purpose of this device is:
1. To allow signals to travel great distances at many times the
speed of light.
2. To use considerably less power to travel the same distance,
compared to transmitters not using this device.
> ...
>>It would, in my opinion, be better if you could just mail your
>>application to a seperate section of the office and not even have it
>>reviewed unless someone tried to patent the same thing later.
>
>That sure would have simplified things for me. Everybody who thinks
>it is so easy to get a serious patent should have to actually do it.
No one here has claimed that it is easy or cheap to get a patent.
However, no one honest, sane, and with a clue would claim that the cost
or effort to get a whatever Mr. Ritter means by a "serious patent" differ
from what is required to get one of the other kinds or types.
Mr Ritter also wrote in <[EMAIL PROTECTED]>:
] The implication of the previous article was that I had to *argue* that
] my idea was new and unique. But that is what the patent *application*
] is about; we are past that argument with an issued patent. Now, you
] may not like that, but, again, that is *your* problem.
There Mr. Ritter once again claims that the existence of his patent proves
that his idea was new and unique. As demonstrated by the many obviously
bogus patents, that claim is utter nonsense. The existence of his patent
shows nothing about whether his idea was new or unique. He is not required
to argue his ideas's merits here, but no one need assume that his patent
would survive a challenge. Even even if Mr. Ritter's idea were new and
unique, whether it might be worth using is a separate question.
Shouting about a patent on a minor idea is a great way to keep the idea
from being used even after the patent expires. There have been examples
of that syndrome in the IETF. For example, people at DEC invented a way
to allow simutaneous 16 and 32 bit checksums for PPP packets. When the
DEC patent lawyers got greedy, the community yawned and blacklisted the
notion. It was a nice little idea, but not nice enough to to jump through
licensing hoops, and not to mention paying royalties. The messy histories
of Unisys's LZW patent and of many other compression patents are more
complicated but similar stories. (Never mind the compession patents with
well known prior art.) The Ethernet patents are examples the obverse,
of how patenting an idea and then giving it away can make it popular.
Even Stac Electronics finally figured out that tactic and profited by
applying it to PPP compression.
Mr. Ritter has for years complained that he has been wronged by NIST and
the industry in general. Perhaps his ideas are wonderful. I was been
underwhelmed when I've looked, but I've assumed that since I'm not skilled
in the art, I can't distingish good encryption ideas from the likes of
faster than light travel and programming techiques from textbooks that
were 20+ years old on the filing date. (See Waite's 1973 book).
My guess is that Mr. Ritter' idea is like many non-bogus patents, at best
barely the sort of innovation that the authors of the Constitution had in
mind. I suspect that by patenting it and then talking about getting rich
(e.g. his endless whining about the AES) he has ensured that for the next
20 years encryption experts will check his patents and do something else.
Mr. Ritter has made clear many times he thinks that his patents should
have given him wealth and respect. Sadly for some holders of really novel
and great ideas, those are not among even the nominal purposes of the
patent system. Perhaps Mr. Ritter's patent lawyers sold him a bill of
goods, but I do wish he would "Get Over It."
Vernon Schryver [EMAIL PROTECTED]
P.S. thanks to Mr. Gauthier for his list of bogus patents. I'd never
heard of some of them, and they might make the point better to people who
don't understand the silliness of patents on FTL travel or that marking
mechanisms known to everyone skilled in the art of linked lists.
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Crossposted-To: talk.politics.crypto
Subject: Re: Intel drops serial number
Date: 29 Apr 2000 10:23:37 -0600
In article <[EMAIL PROTECTED]>,
Andy Dingley <[EMAIL PROTECTED]> wrote:
>>Especially since the so called "light" was mostly silly noise from people
>>with far few clues than they think they have about their privacy.
>
>The clueless have one huge advantage over the clueful
> - there's far more of them.
aye, there's the rub.
> ...
>PS - Isn't there something a little "Spook"y about discussing privacy
>with someone from "rhyolite" ? I have this vision of "calcite" as a
>huge orbiting umbrella 8-)
The geologic and geographic meanings of the word that existed before
some spooks applied it to their efforts will endure long after the
spooky stuff is forgotten. For me, it's a place name, but proably
not the one you'd guess.
....
In article <[EMAIL PROTECTED]>,
Isaac <[EMAIL PROTECTED]> wrote:
> ...
>Assuming that it was silly, how can you claim that people who thought
>they saw privacy concerns were kooks, ignorant or had evil motives while
>admitting that Intel claimed that the PIII ID could and should be used
>exactly the way the evil, ignorant kooks feared?
The PIII ID would not have been used as the kooks feared. Anyone
violating privacy uses other techniques, because the PIII ID would
for many years be absent from most personal computers. If you're
tracking people, you use tactics that work all of the time instead
of those that work only if the targets happen to have PIII's.
When (not if) ID's like the PIII ID are no longer confined to slightly
more expensive personal computers, the ID's will only supplement and
slightly improve the existing system serial numbering mechanisms. For
example, UuidCreate() will simply mix the CPU hardware serial number
with its other sources. CPU ID's like the PIII register been nearly
universal in commercial UNIX boxes for decades, and the technical and
business reasons for them other than privacy violation will not be denied
forever in cheap PC's. Ethernet MAC addresses and 128-bit random numbers
are more than good enough for violating privacy, but the legitimate,
non-privacy-abusing uses of hardware CPU ID's need something better.
The evil is that the kooks fooled the clue-free masses into thinking
that they were protecting their privacy by fighting the PIII ID.
The idiot masses were distracted from real and quite serious privacy
threats. If I were paranoid, and if I didn't know that the kooks
do such evil for free, I'd suspect that Doubleclick and the FBI
had tricked Intel into making it's silly noises and then funded
the kooks to generate their distracting smoke and noise.
>There is no question that the PIII ID had the potential for being far
>more universal than those other IDs you discuss, and with Intel pushing
>the thing certainly had the potential for being more widely used as a
>universal ID than those other things. I suggest that people who don't
>even see a potential problem lack imagination. For those who think the
>potential wasn't real, I simply disagree.
>From start to finish that is silly and even evil nonsense because it is
a classic "big lie." The other mechanisms are already more universal than
the PIII ID could ever be, since they work not only on all WINTEL systems
(and not just PIII's) but also on non-Intel MS Windows systems (albeit
declining as Microsoft forgets about non-Intel CPUs). The techniques, as
opposed to the existing library functions in provided by Microsoft, are
obviously far more universal than the PIII ID could ever be.
The privacy problems in tracking people are not mere "potential" and have
nothing to do with the PIII ID. By implying that some privacy was
threatened by the PIII ID and protected by its disappearance, you are
aiding and abetting those who can and do violate the privacy of anyone
who doesn't take precautions. By spreading the "big lie" that a battle
has been won, you fool the ignorant into not seeking and implementing
defenses.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: "Monolo" <[EMAIL PROTECTED]>
Subject: Programs needed to start?
Date: Sat, 29 Apr 2000 10:14:18 -0700
Thanks for such a quick reply! I am readint those online resources, and
going to see if I can pick up those books. For cryptography, do you need any
special programs? Or how does it work?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: factor large composite
Date: 29 Apr 2000 12:31:24 -0400
In article <mWZN4.67$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Joe Leh
erbauer) writes:
><[EMAIL PROTECTED]> wrote:
>> And again, what part of "first step" and "longer-term" is in
>> dispute? The number is question is (2^773)+1, and it does
>> indeed have 773-bits, with 773 > 768.
>
>Wrong. 2^773+1 has 774 bits.
Ah. My mistake, I stand corrected. But perhaps I can still have
that the number we're factoring has more than 768-bits?
B. Dodson
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Programs needed to start?
Date: Sat, 29 Apr 2000 17:27:05 GMT
Monolo wrote:
>
> Thanks for such a quick reply! I am readint those online resources, and
> going to see if I can pick up those books. For cryptography, do you need any
> special programs? Or how does it work?
Well you really don't need any programs... but if you want to test your
ideas you should pick up a C compiler. I am in the midst of making a
program that makes sboxes... and I'll bet others in this group have
their own collection of programs...
For starters all you need is
1) Pencil
2) Paper
3) Time
I wouldn't start to make your own ciphers until you feel comfortable
with what's going on. For example I can normally tell when some design
element sucks, but I can hardly analyze as good as the pros...
Read up the sources and ask as many questions as you can think of.
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: factor large composite
Date: Sat, 29 Apr 2000 17:27:35 GMT
[EMAIL PROTECTED] wrote:
>
> In article <mWZN4.67$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Joe Leh
> erbauer) writes:
> ><[EMAIL PROTECTED]> wrote:
> >> And again, what part of "first step" and "longer-term" is in
> >> dispute? The number is question is (2^773)+1, and it does
> >> indeed have 773-bits, with 773 > 768.
> >
> >Wrong. 2^773+1 has 774 bits.
>
> Ah. My mistake, I stand corrected. But perhaps I can still have
> that the number we're factoring has more than 768-bits?
> B. Dodson
What are you using to factor it?
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: How would a 15 year old start?
Date: 29 Apr 2000 17:19:14 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> He has put alot of time into them, and they are worth reading. If you
> want some books check up "Handbook of Applied Cryptography" published by
> CRC Press and/or "Applied Cryptography" by Bruce S.
It's worth noting that the Handbook of Applied Cryptography is available
for free download online at
http://www.cacr.math.uwaterloo.ca/hac
It is worth looking at, but it's almost certainly too brief to really
understand at this point. :-\
I would suggest picking up a copy of _Applied Cryptography_ and
finding a language and support packages which support very large
numbers which you're comfortable with. Then try to implement some of the
more interesting and simpler algorithms. The binary square and multiply
method for modular exponentiation might be a place to start, but I'm
biased towards number theoretic algorithms.
Another thing to consider -- if you have the opportunity to take a course
in computer science, you might want to do that and then work in some kind
of cryptography. In my case, I started by taking a
course taught in Scheme at a local college. With the generous help of the
professor and some sci.crypt readers, I eventually managed to implement
RSA using _Applied Crypto_.
Thanks,
-David
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: How would a 15 year old start?
Date: 29 Apr 2000 17:25:28 GMT
Monolo <[EMAIL PROTECTED]> wrote:
> As I said, in my pervious post, I would love to learn, I read Tom's post
> back to me after I sent it, sorry for the duplication. I was wondering, what
> would be the best way to start? Are there any good online resources?
oh, and also worth looking at
RSA Labs FAQ
http://www.rsasecurity.com/rsalabs/faq/
and Ron Rivest's List of Crypto and Data Security Links
http://theory.lcs.mit.edu/~rivest/crypto-security.html
Thanks,
-David
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: sboxes for the bored...
Reply-To: [EMAIL PROTECTED]
Date: Sat, 29 Apr 2000 17:31:04 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote:
: Tom St Denis <[EMAIL PROTECTED]> wrote:
: : When we look at the entry of the WT on sbox5 where we find a "-20" this
: : means that you can form a linear equation of some bits in sbox 5 that
: : will hold with probability p = 1/2 + 20/64 or 81.25% of the time.
: : Is that right?
: I don't /think/ so.
: The basic idea that the existence of a single entry with a large magnitude
: indicates high linearity seems correct.
: Having said this, a thought-experiment with a low non-linearity of 2
: (corresponding to an entry of the WT of +/-30) suggests that the best
: linear approximation would be good - but not that it would hold almost all
: the time across all possible inputs, as your equation appears to suggest.
OTOH, the equation for "p" you give appears to be correct if I interpret
it as the probability of picking a bit from the input which always has a
linear effect on the output. This is probably what you were trying to
get at.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Of Mountains and Molehills
Date: Sat, 29 Apr 2000 10:51:12 -0600
Pertaining to common characters, changing the duty profile from poor in
lower ascii to something better and more congruent with what can be
handled with encryption represents a useful challenge.
One approach is to use a simple set of those characters you actually need.
If you can predict this need, that is preferable, but we do like to be
spoiled a little, know no limitations and the like. As plaintext goes, 22
characters or less might be usable, whereas 27 is the minimum for
non-butchered spellings for English.
Using key multiplexing, appropriate coding, I have demonstrated effective
use of base 18, for example, where many little capability is lost in
normal text passages.
Since most of us are familiar with keyboards that sport 94 characters plus
basic spaces and CR's, here is a medium base that can handle them all,
base 37.
My choice were to have three internal sets of 34 characters. Externally
is a space character, that is used in 1-2-3 formatting of space, CR, and
2CR. Considering that normal lower case is the most prevalent, two
external flag characters select momentarily the uppercase letters or a
rare character set. The common set is fleshed out with common
punctuation.
If one were to desire, a similiar scheme could be used that could handle a
few special foreign language characters, as there are 8 open slots in the
above scheme. It is implemented as one of my shaped letter ciphers,
Nottoway, which uses bases 37/18/78.
Pt size is 12 characters, intermediate blocksize is 25, and Ct is 10. I
included tranposition and substitution keys at the base 18 level and
redundant substituion of 26 characters in cipertext of base 78. The
translation efficiencies of Nottoway are 99.2% and 95.9%.
Remember, these neoclassical ciphers are not designed to be ultimate
strength ditties, just to work within higher minimum Shannon limits than
older ones. Just what amount of content do you need to solve them? And,
how are you going to pick out which cipher to attack if you know there are
more that a few possible directions to go, even with a strange ciphertext
format?
Each of the base translation ciphers can be used for unkeyed format
conversion, or be keyed in many ways as encrption means. They are
open-faced, as a practice certain keys are to be better than others, but
that is not my goal, to determine which boxes are best.
More to come...
--
Laughter is often the most pleasing result of successful analysis.
------------------------------
** 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
******************************
