Cryptography-Digest Digest #975, Volume #8 Tue, 26 Jan 99 19:13:03 EST
Contents:
Re: Metaphysics Of Randomness (Darren New)
Re: Random numbers from a sound card? ([EMAIL PROTECTED])
Re: Random numbers from a sound card? (David Ross)
Re: Japanese Purple encryption (John Savard)
Re: Random numbers from a sound card? (David Ross)
Re: Random numbers from a sound card? (Frank Gifford)
Re: Random numbers from a sound card? (Paul Rubin)
Re: The Performance of Meet-in-the-Middle ([EMAIL PROTECTED])
Re: Random numbers from a sound card? (Paul L. Allen)
Entrust Developer Tools (Ted Reinhardt)
Re: Unicity, DES Unicity and Open-Keys (wtshaw)
----------------------------------------------------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Metaphysics Of Randomness
Date: Tue, 26 Jan 1999 21:16:33 GMT
Alan DeKok wrote:
>
> In article <[EMAIL PROTECTED]>,
> Darren New <[EMAIL PROTECTED]> wrote:
> >> A 'Cryptographically secure' RNG generates random numbers via a
> >> *non-deterministic* algorithm. The output of any one generator is
> >> unpredictable even knowing the algorithm and all initial conditions.
> >
> >Uh, excuse me? I'm afraid that if I know the RC4 algorithm and all
> >initial conditions including the key, I can certainly predict exactly
> >what will come out. That's why it's possible to encrypt something with
> >RC4 and decrypt it later.
>
> Then you're using RC4 as a stream cipher, not a PRNG.
I'm using it as a PRNG to generate a pad to do a stream cipher
encryption. What I use RC4 for has nothing to do with whether the
algorithm is deterministic or not.
> > There are nondeterministic algorithms, but RC4 isn't one of them.
>
> So? Did I ever say it was?
You said in the first sentence above (assuming that was you -- it wasn't
me) that a cryptographically secure RNG uses a nondeterministic
algorithm. I thought that RC4 was a cryptographically secure RNG.
Perhaps that's my confusion.
--
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"You could even do it in C++, though that should only be done
by folks who think that self-flagellation is for the effete."
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Random numbers from a sound card?
Date: Tue, 26 Jan 1999 20:47:01 GMT
In article <[EMAIL PROTECTED]>,
Jon Haugsand <[EMAIL PROTECTED]> wrote:
> * Cuykens Anthony
> | I do remember of a way a teacher told me to generate a "true" random
> | generator.
Your teacher was just trying to communicate that you need a physical
signal to start with, as deterministic algorithms can't produce
unpredictability (aka randomness).
Computers that can roll dice are not Turing machines.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (David Ross)
Subject: Re: Random numbers from a sound card?
Date: Tue, 26 Jan 1999 21:26:38 GMT
On 26 Jan 1999 13:55:26 -0500, [EMAIL PROTECTED] (Frank Gifford)
wrote:
>In article <[EMAIL PROTECTED]>,
>David Ross <[EMAIL PROTECTED]> wrote:
>> Have tried something very similar to that. I am attempting to
>>create a rotortable of all 256 byte values placed in 'random' order,
>>but the (8 bit) SoundBlaster seems reluctant to produce a 0xC0 byte.
>>I infer this because in over 80% of the rotortables I create, 0xC0 is
>>the last table entry.
>
>How are you creating the tables? I would assume that since you are creating
>rotors, that each value appears in the rotor exactly once. Are you swapping
>values or some other method? Personally, I would suspect your creation
>routine is not doing what you want instead of bad numbers.
Giff -
I create one rotor at a time, waiting for each one of the 256
bytevalues to come in from the SoundBlaster before I go on to the next
rotor. A very simple piece of code, done in assembly language.
- several bytes commonly occurred toward the end of each rotor, but
0xC0 was by far the most popular as the last byte. (Incidentally, I'm
using an ES1688 sound chip set up to emulate a SoundBlaster.)
- the process of rotor creation took _much_ more time than I had
estimated.
- using a 'small' (50+) rotor encryption scheme to encrypt the
SoundBlaster bytes before sending them to the rotor sorting routine
sped up the process by about 20X.
David Ross [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Japanese Purple encryption
Date: Tue, 26 Jan 1999 22:08:28 GMT
Jim Gillogly <[EMAIL PROTECTED]> wrote, in part:
>[EMAIL PROTECTED] wrote:
>> Does anyone know of an software emulator to illustrate
>> the algorithm used in the Japanese WWII purple cypher?
>> If not, can someone explain the algorithm used?
>Wilhelm Plotz wrote an almost-emulator for Purple. See his Web page
>at http://members.magnet.at/wilhelm.m.plotz . He used random wiring,
>since he couldn't locate the actual wiring used by Purple.
There seems to be a document listed in narafindaid.html (at the NSA
web site) at the National Archives (location II, College Park,
Maryland) which may have the actual wiring now, if someone is
interested...
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (David Ross)
Subject: Re: Random numbers from a sound card?
Date: Tue, 26 Jan 1999 22:13:11 GMT
Randombit -
Thanks for an informative post.
On Tue, 26 Jan 1999 20:12:38 GMT, [EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] (David Ross) wrote:
>> Has anyone had success using a sound card (like a Sound Blaster) to
>> generate streams of random numbers?
...
>> What sort of audio source would you suspect would be the best to use
>> in generating random numbers?
>
>I used an old radio shack mono fm radio, with antenna removed,
>tuned to hiss, at high volume, fed into the sound card.
>
>Later I got a video/radio digitizer, which I can tune to
>FM hiss, which is more self contained.
>
>This produces an apparently uniformly distributed noise spectrum,
>using a pc-based spectrum analyzer.
>
>But this doesn't have full entropy, and you have to distill (see
>RFC 1750) the bits. I experimented with parity-of-N bits,
>and used Maurer's Universal statistical test for RNGs to measure
>the entropy. When you distill enough, the entropy reaches its
>expected value.
>
>Some people might recommend a strong hashing function (e.g., a thousand
>raw bits hashed with MD5 down to a fixed output size). This is
>complex and I found unnecessary; simple parity works, though it
>may waste more bits than a serious hash would. But bits are cheap,
>and xor is fast.
Lets say I'm digitizing a sine wave of constant frequency &
amplitude. If it has a 1 Volt peak amplitude and if I digitize at a
constant rate, won't 1/2 of my samples yield a value of either >+.707
Volt or < -.707 Volt? Seems like a built-in bias toward higher
numbers...
After looking at 'random' noise on an oscilloscope, I'd expect to
see this same bias when digitizing noise...
Digitizing either a sawtooth or a triangle waveform should get rid
of this inbuilt bias, but where to find 'sawtooth noise' is beyond me.
>> How would you test the 'quality' of the generated random number
>> stream?
>1. Marsaglia's Diehard suite of statistical (structure) tests.
>2. Maurer's Universal statistical test
>As "calibration standards" I used the "RAND million normal digits and their
>deviant friends", and also block ciphers run in feedback modes (ie,
>as PRNGs).
Thanks for these suggestions.
>Also note that a 'loud' source of hiss is preferable.
A 'loud' source of hiss may put the range of the A->D converter down
lower on a sinusoidal waveform. In this more linear area of the
waveform, you would get a more even distribution of digitized values
and begin to eliminate some of the inbuilt bias mentioned above.
David Ross [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: Random numbers from a sound card?
Date: 26 Jan 1999 17:30:58 -0500
In article <[EMAIL PROTECTED]>,
David Ross <[EMAIL PROTECTED]> wrote:
> I create one rotor at a time, waiting for each one of the 256
>bytevalues to come in from the SoundBlaster before I go on to the next
>rotor. A very simple piece of code, done in assembly language.
Does this mean that (for a given rotor) you loop through rotor positions
and get a value from SB that has not been used yet, and then do the
remaining positions that way? So if SB gives you the same byte several
times in a row that you ignore the duplicates?
> - several bytes commonly occurred toward the end of each rotor, but
>0xC0 was by far the most popular as the last byte.
Assuming I understand your process, that means 0xC0 is very unlikely in
a byte stream. In that case, SB in your set up is probably a bad choice
for a random number generator. You may have to investigate your set up
a bit more. Not enough static for input?
> - the process of rotor creation took _much_ more time than I had
>estimated.
If you are doing it the way above, then yes indeed. When you get to the last
two values, you are waiting for either of them to be generated so you can
fill in the last piece of the rotor. You might want to look into generating
a simple rotor and use the random numbers to swap entries in the rotor. Then
you can simplify your code and generate a new rotor in a known amount of time.
> - using a 'small' (50+) rotor encryption scheme to encrypt the
>SoundBlaster bytes before sending them to the rotor sorting routine
>sped up the process by about 20X.
Does this mean you take the values from SB, pipe through your rotors, and
then use the results to create/modify a rotor? In that case, this may
be the source of weird results.
I would recommend checking your set up of SB to see whether the bytes it
generates directly is really 'random' and not biased.
-Giff
--
[EMAIL PROTECTED] Too busy for a .sig
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Random numbers from a sound card?
Date: Tue, 26 Jan 1999 22:20:11 GMT
In article <[EMAIL PROTECTED]>,
David Ross <[EMAIL PROTECTED]> wrote:
>Nathan Kennedy wrote:
>
>> > What sort of audio source would you suspect would be the best to use
>> > in generating random numbers?
>>
>> I tune a cheap AM radio to a loud static channel, and wire that into the
>> mic port.
> Have tried something very similar to that. I am attempting to
>create a rotortable of all 256 byte values placed in 'random' order,
>but the (8 bit) SoundBlaster seems reluctant to produce a 0xC0 byte.
>I infer this because in over 80% of the rotortables I create, 0xC0 is
>the last table entry.
>
> I'd guess that the 'consumer-grade' A->D & D->A converters used
>in common sound cards are susceptible to all sorts of troubles like
>this, i.e. missing codes and/or monotonicity problems.
Don't even think of using raw soundblaster output as actual random
data rather than just as an entropy source. Even if the a/d converter
is terrific, it's still likely to pick up correlated noise from
various sources in the PC. Run the audio bits through a cryptographic
hash function or something similar before using it.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: The Performance of Meet-in-the-Middle
Date: Tue, 26 Jan 1999 22:16:04 GMT
In article <78jibl$568$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> I didn't really understand your proof; the notation (or maybe
> the group theory) lost me. I'm sorry. I'd be happy to try
> to take a look at the proof, if you feel generous enough to
> be willing to "translate" it down to some simpler explanation
> of the construction, but the current exposition is over my
> head. :-(
I must admit that at on this late page in the thesis, some of the crucial
arguments have been used over and over again, and so I don't really invoke
them with a great deal of delicacy. On the other hand, David, you and I
both know that you are *not* weak on theory! I can probably dig up the
exact article, but once on sci.crypt you noticed, in minutes, something
about computing the sizes of groups of units in a ring. The same problem
had occurred to me earlier and to be honest it took me weeks to completely
resolve it. So turn that frowning face into a smiley face, because you do
us both a disservice here! :-)
To understand the counterexample you don't need to understand the
theorem which precedes it. The theorem is interesting as a general
lower bound on MITM, in terms of information theoretic quantities. To
follow it you *do* need a large part of my thesis [1].
The MITM counterexample relies on some elementary group theory which I
think I can explain. But first let's agree to treat keys in the keyspace
of a cipher as elements of a group G. This is very natural because each
key Ky corresponds to the permutation p -> E(Ky,p) on the messages space,
so the two descriptions are equivalent. Let us also agree that the adversary
carrying out the MITM attack is in possession of a single *fixed*
plaintext-ciphertext pair (p,c). The proof doesn't change one bit if there
are multiple pairs. (But of course the performance, averaged over random
plaintexts and over all "random ciphers", will change dramatically.)
The basic idea is that the counterexample is constructed so that the
*specific* pair (p,c) lends no additional side information to the overall
key (x,y) of the product (x and y are group elements corresponding to the
keys of the product Z = XY). Put another way, for every x,y
xyp = c, (1)
which is the group theory shorthand for c = E(Kx, E(Ky,p)). One could
consider this a minor ciphertext-only weakness because observing c always
tells you that the corresponding plaintext block was p. But this event
(observing that particular c) has low probability, and the strength of Z
should be measured by the adversary's difficulty in decrypting *all*
ciphertexts. To make Z strong in resisting attacks which determine its
key, the component ciphers are constructed so that Z = XY has ``maximum
entropy'' despite the restriction of (1). To see what (1) really implies,
we employ a bit of the elementary theory of permutation groups (groups,
like our G which act by left multiplication as in (1) on some set, like our
message space).
Def: The stabilizer Stab(p) is the subgroup of all g in G such that gp = p.
Fact: The set of all g in G such that gp = c, can be identified with a
left coset of Stab(p). The proof is easy and so important that we include
it in full:
Let H = Stab(p). If c = gp = fp, then (g^-1 f)p = p, so that
(g^-1 f) is in H. This is equivalent to saying that
(g^-1 f) H = H, as sets, which in turn is equivalent to gH = fH,
or in other words g is in gH and also f in gH. Q.E.D.
Thus for the plaintext-ciphertext pair (p,c) to provide *no* useful side
information, we must have for every x and every y
xy is in g'H, where H = Stab(p), and g' is some group element.
Now let S be the set of all group elements x corresponding to encryptions
by the cipher X, and let T be the set of all group elements y corresponding
to encryptions by the cipher Y. We take the sizes of these sets to be |S|
= |T| = 2^k, where each component cipher has k bits of key. I think it
should be clear that the set of trial key pairs (x,y) within the MITM
attack is nothing more than the set
ST intersect g'H,
because anything in ST is a possible outcome of the product cipher Z = XY,
and thus anything in both ST *and* g'H is a candidate for the key of Z,
given the pair (p,c). In the naive MITM we are lucky enough to have the set
of intermediate message blocks Tp line up 1-1 with the intermediate message
blocks S^-1c, and our search takes about |Tp| = |T| = 2^k trials. But
that is because the pair (p,c) really does provide useful side
information. So we may now summarize in group theoretic language the
requirements of the counterexample:
1. ST is contained in g'H.
2. |ST| = |S|*|T|.
If we can build X and Y satisfying these requirements, then a set of
size |ST| = 2^(2k) must be checked for the one true key. To me the
simplest way to do that is to find a subset of H of the form S'T' and
multiply it by g' so that S = g'S', and T = T', and obviously then.
ST = g'S'T' is contained in g'H
Of course we must have also that |S'T'| = |S'|*|T'|, which is easily
facilitated by the following additional fact from elementary group
theory:
Fact: For any subgroup K of a group H, the left cosets of K partition
H, or equivalently H is a *disjoint* union of these left cosets. Moreover,
the cosets are all of the same size.
Since H = Stab(p) is typically a huge symmetric group (on the order
of (2^n-1)! elements), it has no shortage of subgroups of various
sizes. Let T' be a subgroup of H of size about 2^k elements. Let
S' be a set of distinct left coset representatives of T' in H, in
other words for each s in S', sT' is a distinct left coset of T' which
is itself completely contained in H. From the previous fact,
S'T' is a disjoint union of sets of size T', each contained
in H.
Thus g'S'T' is contained in g'H, and |ST| = |g'S'T'| = 2^(2k). To
summarize, the product cipher Z = XY has the property that knowing
the plaintext-ciphertext pair (p,c) provides no side information. This is
done by having the group elements of Y be in a subgroup of size 2^k within
H = Stab(p), and by having the group elements of X be the elements
of the group of the form g's, where s ranges over 2^k distinct left
coset representatives of the subgroup (the elements of Y) of H. This
completes the counterexample.
* * *
> I could well be confused; it's easy for me to make mistakes
> when I try to do theory. If I am, I hope you'll point out
> where I went wrong.
I think your analysis starts to go wrong when you average over all
plaintexts. While is true that if Prob[YP = Y'P'] is large, then you get
an equivalent key, I am only assuming (indirectly)
Prob[Yp = Y'p] = 1,
which doesn't diminish the cipher's strength nearly so much.
Cheers,
John Pliam
[EMAIL PROTECTED]
http://www.ima.umn.edu/~pliam
refs:
[1] John Pliam, Ciphers and their Products: Group Theory in Private Key
Cryptography, PhD in preparation, 1999.
URL: http://www.ima.umn.edu/~pliam/doc
[2] ___, section 6.5 of [3], "About the MITM Attack".
URL: http://www.ima.umn.edu/~pliam/doc/mitm.ps.Z
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Paul L. Allen)
Subject: Re: Random numbers from a sound card?
Date: Tue, 26 Jan 1999 22:55:51 +0000
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>
Medical Electronics Lab <[EMAIL PROTECTED]> writes:
> DIEHARD from Marsaglia
I can never find a URL for that when I need it. I saw Marsglia posted
his various PRNGs the other week and mentioned it but no URL. Actually,
I am more interested in the accompanying docs than the actual tests right
now. What a shame we can't get the FAQ updated.
--Paul
------------------------------
From: [EMAIL PROTECTED] (Ted Reinhardt)
Subject: Entrust Developer Tools
Date: 26 Jan 1999 23:19:40 GMT
Reply-To: [EMAIL PROTECTED] (Ted Reinhardt)
Just in case folks are interested I found out today that the Entrust
toolkits are available for downloading. It used to be that you had to pay
a large hunk of change to get your hands on them, but I guess they have
changed their tack. I briefly glanced at their web site www.entrust.com (
I think they have a http://developer.entrust.com site as well.
Anyways I think they are giving away the development tools and a mini PKI
setup for developers. It is all for the downloading.
Check it out yourself as I may have gotten the facts wrong .
Cheers,
--
Ted Reinhardt
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Unicity, DES Unicity and Open-Keys
Date: Tue, 26 Jan 1999 16:23:09 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
>
> > Unicity, DES Unicity and Open-Keys
> >
> > Archived at http://www.mcg.org.br/unicity.htm
>
> I have a tiny question. You say that 'magic numbers' or 'information
> tags' enable the analyst to identify the compression algorithm.
> Could one suppress that, i.e. let it be part of the secret information
> of the communication partners? One could also vary the algorithm
> setup (the Huffman table, etc.) depending on some (time-varying)
> value not known to the analyst, I suppose.
I've stumbling more onto, lets us say, novel means of simple, basic
compression, more information in fewer characters. The idea is to vary
such methods and incorporate them more closely with the encryption
itself....these best described as "bucket" ciphers, somewhere between
block and stream ciphers, are still in the scratch paper phase, and will
be explained in detail once they start being born...implemented.
>
> More generally: It is commonly assumed that the analyst knows the
> encryption scheme one uses. But this is reasonable if one repeatedly
> uses the same scheme. If one has a fairly large set of schemes to be
> chosen according to a secret schedule, then the analyst has first of
> all to figure out the scheme actually being used, i.e. he has a much
> higher work load. I believe all this could be subsumed under the
> paradigm 'Security through variability', which underlies, in
> particular, those algorithms that are parameter-dependent (analogous
> to parametrized data types in programming languages; the parameters
> can be regarded as kind of 'key extensions' which is of interest
> in the context of the Wassenaar regulation).
What is needed is a multitude of algorithms, with view as to what output
is produced. Recently, I began posting some rather simple, probably dumb,
ciphers, whose goal is more than anything to add more straw to the pile.
The are probably dumb, as Ritter suggested, but they also facilitate a
mechanism of having to chose from a bank of ciphers, also a Ritter idea,
perhaps where multiple layers can involve appropriate chaining, probably
more my idea.
Consider that even no-brainer, default keys in a number of applications
can be a problem for filtering, if not routine more careful analysis.
Routinely, posting ciphertext is discouraged, but to reenforce the idea
that having lots of algorithm choice presents a definite problem, what is
included are what might be encountered. Some are specifically not
efficient. Many more implemented algorithms to follow in rapid
succession, one ever two to four days, some not so dumb. Ciphertext for
the above sentence in a variety of default-keyed algorithms follows:
ROT13: Pbafvqre gung rira ab-oenvare, qrsnhyg xrlf va n ahzore bs
nccyvpngvbaf pna or n ceboyrz sbe svygrevat, vs abg ebhgvar zber pnershy
nanylfvf.
INV26: Xlmhrwvi gszg vevm ml-yizrmvi, wvuzfog pvbh rm z mfnyvi lu
zkkorxzgrlmh xzm yv z kilyovn uli urogvirmt, ru mlg ilfgrmv nliv xzivufo
zmzobhrh
ROT45: pBAF<78E G;4G 8I8A ABZ5E4<A8EY 7894H?G >8LF <A 4 AH@58E B9
4CC?<64G<BAF 64A 58 4 CEB5?8@ 9BE 9<?G8E<A:Y <9 ABG EBHG<A8 @BE8 64E89H?
4A4?LF<F[
INV90: X,-(276) '3:' 6%6- -,n9):2-6)o 765:&/' 06"( 2- : -&.96) ,5
:++/28:'2,-( 8:- 96 : +),9/6. 5,) 52/'6)2-4o 25 -,' ),&'2-6 .,)6 8:)65&/
:-:/"(2(m
Not to mention simple Caesar shifts for the above. Here are a few more,
not all, encrypted with dumb defaults, not to mention real, user defined
keys:
BLT: mgrne lkwbo vydou dzygn znull xrrdw sitsd sfvec /rgqw ongst ekqel
lothn wblu/ xppwt rfvpd mcukt qdhqz oowdp cffpn vjbng kfajv lyuwp ilabf
/leyk dtto/ pupyi figfr wwbo/ iappx fueew cj/zt amsna zee/c rirqw ijkuc
crsvp bxdhi vwyrs xxvdr yyjrg ep/cb bfqeq xpmrr rpplp gatee u/cav kgewo
rlvav rruqc shrfh nogdq qdojn eknm/ fxyz/ zqitf /rufa tlyff qprry kjnbk
f/vco wqbvr yhavr i/so/ jk/fr unqwn to/mz lroer /zwoi picjn jxxze kdqqu
luntp zzoei cvwni ildsu dvjk/ iswwa tf/yo wac/f fppyh zbmsa kvoor mlmdp
ccoad rnx
Code Blue: Cnlpeczk azki ttkz de-kjhoitu, bdw/stp wcr/ by q /ucomh ey
hgkmqa/thmqo dgg jn k ec/n/mc xgy /dmqcqime, fb tim zfrixak ychn vhx/sxj
/o/jgoyp.
Divinity 36: e?;ERhJC-gPA g-iki.-.\$DC Aq.Jdx@GJlbI wg@UJQE-q.@b
-;jYciC-\K@b =~wqFbgq?;E- FA.-ci@A@=C? cwJY@K\C@Kqw gJCq;MW-RK-;
?g@C\Igq.i@Y \Ci-FACJlIw@ A;AXrfREVjfA
Penuche 25: E?,ei gjd=d obh-e ki,-n /?dca q.jdl -gika ixh-k jrf-i ,-b-n
iycjb -?l-a --wqc bgq?n f-ean -cj-a -=c?b wiz-f /d-ki xgjci .nx-i l-./d
=c/jd q.j-m /cj-c bcile x-a.a xrerc v=jea
Penuche 36: e?.EqhiC~Goa G~iKi.~.?$cC aq.iCW~gikaI wG~uiQE~q.~a
~.IyciC~?k~a --wqeaGq?.E~ ea.~ci~a~-C? cwiy~k?C~kqw GiCq.mW~qk~.
?G~C?IGq.i~y ?Ci~eaCikIw~ a.awQEqEU~IE
Fudge 25: Elgwi /zki? nnzim /i=?j mdddk .qgty ldnbb o-j.n imj.o ,k,,k
ualcr nlplj hxdpa sky?c shssd ljnjj xlllf zj-ni ofnvg lderk nol/m x.pos
tvnf, ki-,i kznjk ka?as ldklc bvalw clgdp
Fudge 36: ELGwij~?veoC LD-ClATnPPjI uaMgQrlDNbB: hPUNgI.t.~tB tbplFM;w~wtj
hXDPAdjVmOrq ?JmMic\NNNv. TS$.qIOfnVGK vBsYFE,t:xtJ oXVvOIvR$WRa
KznJKCVQOQjn KIc.QVAwiF~:
Rimfire 12: hqirx sghre ypkia jdujr ajfth qupkn qpkew adnws hrots onqts
frszg axdcp iuooh rvgad kpkrx qtdgr fiacz adnxt rvotq dsyss lgacz srgrq
utojz mtmds lptdg wozms cnotd aczad ptcho tlpkd jades luade rfgtl ztcbs
fqqtx clnrf aadjn slyad sslzt qmdsf rwqad msluq pfpoz mtbvp pbrjr ljooa
onyun hrfow qdbmt gf
Balsas 10: gscin ypcus nllts voakw dthro mxixe sktgp umbop kjynn conke
silmm jmxln veuqx pceac uxcwc qlzky jommv qgpmu uhwlr nefco nnwgn mikkc
omsnu vglyi neacz ifaad vlnpw hufxl jqllf edgvj wdqto eudin ucggs acbap
hrlac viqeo syfmn cmrma eonmu gibsd ovrnz dsdeq pflni qtpdw hrdmw abfpy
bksav tacjw rqwqx eqmln epiaf nmugo pyhrn lfdaq lllna kkjqk nsndg vcgvh
gpzcs jpigw emkx
Ping 12: fhgfq kmymg ptiwk khfim zozsn kbmnb tifsn dkkca bomhc bfzok kahro
ckqkh gevab uknfk smitb jqlly jjwal imzpn mvkkr zhyjl oyhcb ayubo mnlnj
nunmu yidgp kkokb mfeim rldnp nmoob dmawh emkfc oczsz abkau vnabj tgyem
fvffh kdabf lmabr gmcnp ikmld xamuo miwrw rtrqg lecep bnfai kkuok tyxom
qrcto mamkc fbmow xozxb ckizh jnyqm cwtod narbk gnmjo fsknb gaaka jymjl
ylltv znhle rueak rnbiz upn
Bankok 8: ekphs rlqmq vodjj ulabl nmauv bzzyp uiakw kwzsy nlctc kolba
jwdkg zyral epkhv bnmix ucikd cnreu bkmju jbnqc jdizh dlltk cqmcv ynclv
jydnv hbtnk jlchw tqyko mjapv bghfe yzoni yxomq azvcm rwnck icvzj tqcnl
vkksu opdgt xrmta vjipn lwuct mqrow suebk rroiw entfc einlc imvza iulnw
nrxng xbpab yhvsa tohmd ixyvm psubr nuynl lraqb ewugt saqcc abzeo xflat
ymzld gpkqk ajkwx gooeq torms ylqkx rijla gisle kziug uedrf rasrk igqrk
nczjk zgwzv efrst obnsl kiofn gtpbg inlcl dqhpj fkrwg ktfci ksxqe gjzrw
lclna hxshn stnbr zzqni qzqku lnkos
Winters 12(NEW): k/s.z rxyvj .yz,n bzumf .ovca hwhef pkub= cvj,e agwvv
sazxo mqxdh /zktz xzzba hwnxw o/za, pvlvb yvemw pp/z, qtyb. muuxc agqna
gleyv kxuma vxqaw ylpyv szqz, egwqs pdvij vlvoy lwazi srz,q svb?/ ylr/a
gtnzh s..fq aucoj xo-xw rak.g h/
Note: Winters is a town in Texas at about 100W and 32 N, and close to my
traditional family roots. Input is in base 100 and output in base 32.
The application includes Winters 6/12/18/24, uses the THF key structure,
and includes 32 character substitution as well as the four transposition
block sizes. I bypassed a couple of mathematically demanding bases for
the time.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
** 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
******************************
