Cryptography-Digest Digest #59, Volume #12 Mon, 19 Jun 00 04:13:01 EDT
Contents:
Re: Comments please: A protocol for Digital voting (zzapzing)
Re: Is Gretchen down? (Patrick Farrell)
Mathematical formula ("Yuriy Stul")
Re: Extending LFSR...... (Simon Johnson)
Re: Extending LFSR...... (Simon Johnson)
Re: Mathematical formula (Mack)
Re: XOR versur MOD (Mack)
Question about lja1 (Benjamin Goldberg)
Re: XOR versur MOD (Simon Johnson)
Re: Extending LFSR...... (Simon Johnson)
Re: Mathematical formula ("Douglas A. Gwyn")
Re: Mathematical formula (Simon Johnson)
Re: small subgroups in Blum Blum Shub (David A. Wagner)
Re: Encryption routine anyone? (Bob Deblier)
Re: Logical attack on RSA ("Michael Brown")
Re: software protection schemes (wtshaw)
Re: LSFR, a character twist (wtshaw)
----------------------------------------------------------------------------
Subject: Re: Comments please: A protocol for Digital voting
From: zzapzing <[EMAIL PROTECTED]>
Date: Sun, 18 Jun 2000 20:37:39 -0700
Let's call the random number generated by the validator V
and the random string generated by the individual voter I.
I have noticed a few more "aspects" of your protocol which
might be considered weaknesses. First of all the
validator can disenfranchize anyone he pleases by refusing
to recognize his value of V as valid, or by sending him
some random numbers instead of a validation of I. The
disenfranchized voter will not be able to prove that he was
disenfranchized. Also the validator could disenfranchize a
voter after the vote is cast by refusing to publish the
voters vote in the list of valid votes. The voter would of
course be aware that this had occured but would not ba able
to prove it to anyone else without sacrificing his anonymity.
and noone else would ever suspect that it occured if he did
not object. These acould be problems which could not possibly
be overcome, its true, but the potential weaknesses of any
protocol should be made apparent (in other words, nothing
personal).
I have also noticed that this protocol is unnecessarily
complex in at least one aspect. That is, the multiple
validations that are done by a long string of remailers, in
order to eventually get I validated. Let me explain a simpler
way to do this.
First of all, each voter puts his individual string, I into
an electronic envelope. Let e(I) denote this. This is the
same as your protocol. Next, the voter sends, through
anonymous broadcast, the pair V,e(I) to the validator. the
validator checks V against his list and then validates e(I)
inside its electronic envelope. Call the result of this
v(e(I)). the validator publishes a list of all the values of
V along with their corresponding values of v(e(I)). The
voters find their V values in this list and read off their
corresponding v(e(I)) value, from which they calculate their
individual value of v(I) (by removing the elctronic envelope).
The voters send in their votes along with their v(I). I
believe this would result in less traffic and computation but
have the same security features as the procedure you proposed.
that said, the protocol could possibly be used for a very
large number of voters, Not all voting protocols can do more
than, say 100 people with present technology.
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: Patrick Farrell <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.firewalls,alt.privacy.anon-server,alt.privacy
Subject: Re: Is Gretchen down?
Date: Mon, 19 Jun 2000 00:00:57 -0500
Reply-To: [EMAIL PROTECTED]
It would in theory show up in the trace routes if you did that however.
Patrick
"Trevor L. Jackson, III" wrote:
>
> I still think you have the difficulty ordering backward. "...slap another set of
>wires on
> ..." is a non-trivial operation when you are dealing with trans-oceanic wires. Yet
>in the
> digital world setting up another virtual circuit is no big deal.
>
> Patrick Farrell wrote:
>
> > Perhaps I grossly misunderstand the way a telegraph worked, but in my opinion
> > your comparing hooking up 2 phones on an analog phone system to 2 on a digital
> > system. In the first case, you just slap another set of wires on, in the
> > second, you can't. (Can't as in just hooking it up won't work)
> >
> > Patrick
> >
> > "Trevor L. Jackson, III" wrote:
> > >
> > > Patrick Farrell wrote:
> > >
> > > > A telegraph signal does not fall into the same category as a high speed network
> > > > device.
> > >
> > > Correct.
> > > Duplicating telegrams required a massive amount of human effort. Rerouting or
>T'ing a
> > > high speed network can be done without a man in the loop, so it's drastically
>easier.
> > >
> > > > Hell if you add a little impedance to a 100baseT cable it will fail,
> > > > yet I saw someone stick 2 computers back to back with arcnet cards in them and
> > > > put a coat hanger in between and network them.
> > > >
> > > > Little bit different :)
> > > >
> > > > Patrick
> > >
> > > Those who fail to learn from history are doomed to repeat it.
------------------------------
From: "Yuriy Stul" <[EMAIL PROTECTED]>
Subject: Mathematical formula
Date: Mon, 19 Jun 2000 08:16:42 +0200
Hello everybody!
Sorry, maybe my question is very stupid. Does exist any mathematical
criteria, or formula to calculate effectivity of SSL protocol? Is it
possible to compare SSL protocols? For example what is better: SSL2 with 512
certificate and RC4_128 or SSL3 with 1024 certificate and RC4_40?
Thanks in advance.
--
Regards
Yuriy Stul, Tashilon Ltd., Core Technology Division Manager
<mailto:[EMAIL PROTECTED]> <http://www.tashilon.com>
------------------------------
Subject: Re: Extending LFSR......
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Sun, 18 Jun 2000 22:49:51 -0700
A futher question. In Applied Cryptography, it say a polynomial
is primitive if all its powers are relatively prime.
Since i am no longer working in GF(2) but in some GF(p). I could
use primes as the exponents, provided they are smaller than the
new modulo. For example:
x^31 + x^17 + x^13 + x^7 + x^3 + x^2 mod 257
Would be primitive, and once converted to a LFSR would result in
a period which is the maximum allowed?
Instinct tell me this period is 257^31?
If i am wrong, could you explain why?
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: Extending LFSR......
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Sun, 18 Jun 2000 23:00:43 -0700
As trivial waste of time:
I have noticed that the words: modulo & modulus have been used
to describe the remainder on division by a number. Surely both
of these terms don't mean the same thing do they?
In which case, which is the correct term?
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Mathematical formula
Date: 19 Jun 2000 06:18:23 GMT
"Yuriy Stul" [EMAIL PROTECTED] wrote:
>Hello everybody!
>
>Sorry, maybe my question is very stupid. Does exist any mathematical
>criteria, or formula to calculate effectivity of SSL protocol? Is it
>possible to compare SSL protocols? For example what is better: SSL2 with 512
>certificate and RC4_128 or SSL3 with 1024 certificate and RC4_40?
>
>Thanks in advance.
>
>--
>
>Regards
>Yuriy Stul, Tashilon Ltd., Core Technology Division Manager
><mailto:[EMAIL PROTECTED]> <http://www.tashilon.com>
>
what you really need is 1024 bit certificate with RC4_128.
RC4_40 is subject to brute force attack
a 512 bit certificate is subject to attack but I would say
it is harder than brute forcing the RC4_40.
As to the version of SSL I would like to hear what
the pros and cons of the various versions are.
Obviously Ver 2 is older and probably in use on more
systems. What advantages does ver 3 have?
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: XOR versur MOD
Date: 19 Jun 2000 06:26:35 GMT
>[EMAIL PROTECTED] (Mack) wrote:
>>Simon Johnson wrote:
>>>Security wise there is no difference.
>>>
>>>It has been pointed out that XOR is the addition of bits at the
>>>same level of significance mod 2 anyway, it must therefore be
>of
>>>equal security to addition mod n. However XOR is self inverse,
>>>so is simpler to use.
>>>
>>>Got questions? Get answers over the phone at Keen.com.
>>>Up to 100 minutes free!
>>>http://www.keen.com
>>>
>>>
>>
>>addition modulo greater than two may have different
>>security than XOR (addition modulo 2). Just
>>depends on the cipher. DES with addition modulo 32
>>is weaker than with XOR (someone wrote a paper
>>back in the 80s). RC5 is probably stronger with addition
>>modulo word size than with XOR (haven't seen an
>>analysis just a gut feeling). The main difference
>>between the two is at the hardware level.
>>XOR is easier to implement.
>
>RC5 is not more secure because of the use of addition (although
>the alternating add/xor does make rotations secure) it's more
>secure because of the rotations.
>
>Tom
What I was trying to say is that addition appears to
help distribute the bits in RC5. Whether this is actually
true or whether it leaves RC5 open to some future
attack that XOR might prevent is an open question.
Unless someone has an attack they would like to share.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Question about lja1
Date: Mon, 19 Jun 2000 06:28:21 GMT
I saw a cipher posted some time back called lja1, but I don't remember
any cryptanalysis on it. I have it included here since the original
post seems to have expired.
/* Designed by Andru Luvisi <[EMAIL PROTECTED]> */
/* Some optimizations and code clean-up made by */
/* Ben Goldberg <[EMAIL PROTECTED]> */
/* synopsis: for each byte in the block, a one-byte hash */
/* of all the other bytes is taken, and this (along with */
/* a counter) is xored with that byte. */
/* The purpose of the counter is to eliminate sliding */
/* attacks. One of the special advantages of this cipher */
/* is that it has a variable block size, and will work for */
/* an arbitrary number of bytes. */
void lja1_encrypt(
unsigned char *block, int blocksize,
const unsigned char *key, int rounds)
{
unsigned char acc;
int i, j, counter = 0;
while(rounds--)
for(i = 0; i < blocksize; ++i) {
for(j = 1, acc = 0; j < blocksize; ++j)
acc = key[acc+key[
block[(i + j) % blocksize]]];
block[i] ^= acc + (counter++);
}
}
void lja1_decrypt(
unsigned char *block, int blocksize,
const unsigned char *key, int rounds)
{
unsigned char acc;
int i, j, counter = rounds * blocksize;
while(rounds--)
for(i = blocksize-1; i >= 0; --i) {
for(j = 1, acc = 0; j < blocksize; ++j)
acc = key[acc+key[
block[(i + j) % blocksize]]];
block[i] ^= acc + (--counter);
}
}
void lja1_schedule(
unsigned char *key,
int (*p_ranmod)(void *closure, int modulo),
void *ng_closure)
{
int pool[256], i, j, k;
for( i = 0; i < 256; ++i )
pool[i] = i;
for( i = 255; i > 0; ++i ) {
j = (*p_ranmod)(ng_closure, i + 1);
k = pool[j];
pool[j] = pool[i];
pool[i] = k;
}
/* pool is now one of 256! permutations, and */
/* has at most log2(256!), or 1684 bits of entropy */
for( i = 0, k = pool[255]; i < 256; ++i ) {
key[k] = pool[i];
k = pool[i]);
}
/* because there are 256 different pool arrays which */
/* map to any particular key array, that means that */
/* there are 255! key arrays, which means that a key */
/* has at most 1676 bits of entropy */
}
------------------------------
Subject: Re: XOR versur MOD
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Sun, 18 Jun 2000 23:33:13 -0700
tomstd <[EMAIL PROTECTED]> wrote:
>Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>>
>>
>>Simon Johnson wrote:
>>
>>> equal security to addition mod n. However XOR is self
inverse,
>>> so is simpler to use.
>>
>>How much more simplicity is there really? (The inverse of
>addition is
>>simply subtraction).
>
>I think he meant that you can just use the same routine to
>decrypt/encrypt.
>
>Tom
>
And that to. In this case, XOR is far simpler to implement, in
the sense, the encryption program doesn't have to know the files
are encrypted.
>Got questions? Get answers over the phone at Keen.com.
>Up to 100 minutes free!
>http://www.keen.com
>
>
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: Extending LFSR......
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Sun, 18 Jun 2000 23:42:04 -0700
Is the fact that 45*45...... will eventually produce every
element in GF(257) the definition of a primitive element, or
mearly a consequence of it?
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Mathematical formula
Date: Mon, 19 Jun 2000 06:47:09 GMT
Yuriy Stul wrote:
> Sorry, maybe my question is very stupid. Does exist any mathematical
> criteria, or formula to calculate effectivity of SSL protocol?
No. Certainly, not without a precise definition of your criteria.
> Is it possible to compare SSL protocols? For example what is better:
> SSL2 with 512 certificate and RC4_128 or SSL3 with 1024 certificate
> and RC4_40?
What if they both suck?
------------------------------
Subject: Re: Mathematical formula
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Mon, 19 Jun 2000 00:00:18 -0700
>Sorry, maybe my question is very stupid. Does exist any
mathematical
>criteria, or formula to calculate effectivity of SSL protocol?
>Is it
>possible to compare SSL protocols? For example what is better:
SSL2 with 512
>certificate and RC4_128 or SSL3 with 1024 certificate and
RC4_40?
Yes there is, if assume that the best attack is brute-force for
all the algorithms, this is a massive assumption, we can compare
the number of decryptions that need to be completed to find the
key with absolute certainly.
e.g. For RC4 40-bit, it 2^40 possible keys (roughly 1 trillion).
Where as RC4 128-bit has 2^128 keys. Therefore RC4 128-bit is 88
times as 'strong' RC4 40-bit.
For certificates, the situtation is a little more complex. If
512-bit is refering to Public|Private key cryptography, then the
complexity of attack, by brute force, is different. The reason
for this is that factoring a 512-bit composite requires less
work than searching every single number from 1 to 2^512. It
therefore requires less steps. I would estimate a 2^512
Public|Private key algorithm to be equal in security to a 2^80
Secret key algorithm.
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: small subgroups in Blum Blum Shub
Date: 19 Jun 2000 00:06:19 -0700
You seem to think that, if an algorithm is "provably secure", then it
cannot have any weak keys (no matter how infrequent). This is just
plain wrong, at least under the normal definitions of "provable security".
You could always pick your own favorite definition which excludes weak
keys, of course, but this isn't the standard meaning of the term, and
I see no reason to stop using the standard definitions.
------------------------------
From: Bob Deblier <[EMAIL PROTECTED]>
Subject: Re: Encryption routine anyone?
Date: Mon, 19 Jun 2000 09:18:17 +0200
Jules and Rich wrote:
> Help please!
>
> Does anyone have (or know where I can find) example(s) of an
> encryption routine in assembly? I need one for part of a college
> assignment. Ideally it would be based on an 8-12 char
> encryption key.
>
> Any help gratefully received!
>
> Julie
Assuming you mean Intel x86 assembler: BeeCrypt contains pentium/pentium
pro assembler code for Blowfish, intended to be called from C - the code
itself shouldn't be too hard to understand or adapt to the platform you
use. You can find the library at http://beecrypt.virtualunlimited.com/.
An update release 1.0.1 will be released later today. Watch this
newsgroup for more info.
Enjoy
Bob Deblier
Virtual Unlimited
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Subject: Re: Logical attack on RSA
Date: Mon, 19 Jun 2000 07:20:44 GMT
There is nothing more annoying than to try several values into your
algorithm and put it out for comments, then try another value in your spare
time and discover that it fails. I have found out that if the second bit
(as in bit 1 in "76543210") is zero then the nice flow-on effect does not
occur as it cannot be started. I found this using 7 * 11 = 77 for the
number I'm trying to factor.
>From the furthest left box you get a1=b1, but it seems you must make a
decision on what a1 is to progress further. Then you carry on as before,
finding boxes with an output of 1 and two product inputs (eg a3b2 and a2b3)
and using this. This means that the security of an RSA key is dependent on
the number of zeros between the LSB and the next 1. For example, a key of:
11000001
is much more secure than a key of
11000011
even though the key lengths are the same. I'm going to try to figure out if
there is a way around this, but this won't delay the release of the
spreadsheet. Its just that the spreadsheet will demonstrate a key where the
2nd bit is zero so can be factored easily.
Oh well, hope nothing else goes horribly wrong. At least I may have
simplified the process of factoring :)
Regards,
Michael Brown
______________________________
/ [EMAIL PROTECTED] \
| (Remove .nospam) |
\_____________________________/
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: software protection schemes
Date: Mon, 19 Jun 2000 01:07:32 -0600
In article <pyf35.5748$[EMAIL PROTECTED]>, lament
<[EMAIL PROTECTED]> wrote:
> A simple example is that a current value is the limit in a FOR loop, or
is bitwise
> ANDed to a local integer. Subsequent changes are made to the value, and
usages occur
> during the normal execution of the program. All subsequent values, or
most all, have
> to be correct. A value could be accessed many times (in a loop) in a
harmless way,
> but would cause a debugger to repeatedly detect a "hit." Further, a
single hashed
> value can be replicated into many other hashed global values at various
times and
> places in the application. Some are used in an essential way, some not.
I think it
> would be very difficult to hunt down all accesses to this data, and
determine what
> the initial "returned ID' ought to be.
Poor programming can involve convluted code. If you want to tiptoe close
to disaster, fine, but being able to separate real bugs from suspicions
about abuse is going to prove that you can replace narcissism with
masochism.
--
Some Turkeys can fly, for short distances. If you are to depend on
birds for communication, if it's with turkeys, consider the
discussions that might occur while feasting on one.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: LSFR, a character twist
Date: Mon, 19 Jun 2000 00:58:20 -0600
In article <[EMAIL PROTECTED]>, tomstd
<[EMAIL PROTECTED]> wrote:
> Linear Feedback Shift Register.
>
> Second they are not secure, but do appear statistically random
> (somewhat). It's the filters on the output of the LFSR's that
> make it secure, not the LFSR itself.
>
Considering the truth in the above, I think I see a bigger picture.
Lately, I have been fiddling with generation of streams, for use with
stream ciphers. I started with a means found for spewing digits in the
Gromark cipher. It seems that the same problem of being cryptographically
secure is the same there as in LFSR's, that the simple structure and rules
are likely trivial to obtain, not much keyspace likely to be involved.
With one simple keystring and a normal base sequence, it not too hard to
see what is happening with a known Pt attack.
With binary, not much can ever be done at the top of the process, so you
are stuck with result filtering. With digits, on the other hand, their
order can be handled as a key, the sequence of ten elements representing
some 21.79 bits of keyspace. Forget them as digits and treat them as
characters at that point. Later, they could be used as digits, or not.
If generation involves base 26, the base alphabet represents 88.38 bits of
keyspace. The resultant stream will be letters, which will be combined
with plaintext to get ciphertext. The mere use of a deranged alphabet
might null itself out except for having the substitution also for finding
values for Pt/Ct characters, a three-substitution process, the design
being greatly simpifed by using the same substitution throughout.
Now, one question is how easy it is to solve a deranged sequence.
Another is the effect of using different keywords of seeds, of different
lengths, useful? A quick test of the process using normal alphabet base
26, adder 3, reveals the following:
Pt0: This is a test and only a test.
Ct1: Ttof bm h hgok zbu ctrt n vnif. "Red" is key in encryption.
Ct2: Bnuh qp i qyhp kdg bkfi z mtmh. "White" is key in encryption.
Ct3: Sxxf sd k rpyt dmc znld b wvku. "Blue" is key in encryption.
Pt1: Slrs zj d dncc eyl lhfi o umui. "Red" is key in decryption.
Pt2: Krlq kg c uvjx twz mqrt c dgqg. "White" is key in decryption.
Pt3: This is a test and only a test. "Blue" is key in decryption.
Note that the keys do form a group, such that using all of them in any
order gets the same result. But, what is the structure of the generator
and the nature of the key that would get us directly from Pt0 to Ct3?
I would speculated that the process because of different word lengths is
vastly more complicated than simple substitution would predict. I find
the prospects of this on-the-fly use of several keys, perhaps long words,
tantalizing.
This is something like being able to cobble together a special LFSR at
will, no soldering or additional programing involved.
Depending on dispay widths of letters, the key field handles 20, w's, to
45, i's, characters, in whatever set is being used, automatically
converted to the designated lower-case form.
I see that the adder does not change sizes or numbers of chain-strings
generated, but does grossly change the sequences. In a standard alphabet,
if two A's were added as characters zero, only A would result. If the
adder of three is used, AA yields D. I allow an adder value of zero to
one less than the base.
Knowing where to start in a generation sequence is a problem, even if you
know how the steps work. I built in a feature that is nice to have if
good and long keys are used, a skip mechaism that will allow up to 9999
steps of generation to be wasted before actual processing, something that
occurs in the bink of an eye; this whole stream cipher process using
characters is rather fast.
My little application does have some convenient presets, but it will
handle bases 10 to 94, deranged, weird sequences, etc. One mischief part
is to present actual words lengths in ciphertext as a default and a dare,
but that is not required if spaces, etc., are substituted.
(As a deception in any cipher where ciphertext includes format
information, even pseudoword groups could be generated or patterned from
another source. I'm at the point of incorporating no additional features
into the current goodie.)
There is no restriction on how characters are made into a set, as this
paragraph results in the following full set of upper and lower case
assignments:
Therisnotcw amd,pgulf:§
This is base 11, with a filler character at the end since only 21
characters could be harvested.
The same text encrypted with the keyword "this" and adder 3 follows:
rTsrs oc wr TTnewiswhis oh con ewfi,soorh gcw ,mue theh a nerg dh nnrT
fgcapilpe hwou,tt hr het §epgsrTrf :afm hci cm §,aTo lhg fwcot hgsT
:Tih§h:sohn,
The actual "this" , converted to lower case as "fmpg", series is as follows:
fmpgm fm:mm ddgul §,g:g auuf: pu:gd lu§mg f,:g, pua§d :dp,, :§:pa agl,f
pd,p: f§g:§ lua:g :muud §papu lldgu m§,§, gggad dfgld gpm§m f,,m, :llpf
u,pum §d§,p pg§am ldpam :lpdf ,:d,p ,f§§, §mgg, :dap, gl§ap :dlg, mpalf
l§ll: :uf§l u§:gf auga: ,fmp, mf§lm §:a,a muup§ pduu: aplml ,aadu ,gama
fppap alll§ uu:fp l:p,f g§,gl gappf lapl§ l,::d p§,:u gpl,m ,dllf mulm§
ga,lf udlua mg:p: uggl, dpdf: :d:§, ,ag:u fuluu ggp,d m§fu, §umgf §:g§a
uld:g m,u:l mlfaa la,§§ ugmf, :m,pd l§:m: addmg lu:pg lgmpp :fag: afuma
u§p:f ug:u, ulmmg ag:ff u:ful :ugfl ,glda pmglf :pl:g ,fua, u:uml l§au:
d:l,, fd:,d ,pff§ pf§up §fdu§ dafpg apmfl fmllm auap: :lg§f pl§p, :u§pl
fu,lu mdg§u §lff: lf:fl ::lf§ fl§§l :m:fd d:dl, ,md:l u,fgm ,g:la uf§:u
§alfd §ldp: m:gdd u§laf :§a:a dmmgu g:,,u p:mdg du§§a fmdam ugp§, mugl§
,p:g§ gull, guda, aguuf ,pu,§ dmgpu :mdld umma§ gpdlm :madd pgl:m pfdfp
ddp:l :gffu gfu,g uma,§ pugud ,,af: ua:l: mffdm fdumd a§ugd f,§d, gpfam
papfl lplu, ,gm:a :dmm, uglm, pal§l §:::a §§mdm ,uulm pgafm famma pgplm
m,agl ufpgu pm,df lfdll dmumu §§§fm m§mg, ,:a:p mmgfg :gguu d,paf §la§:
§daap g,lma dapgg lmdpa u:l:l ffflf fllfl ullgg upd,d :ff,: f,p:, §gpgl
mmpag flfgl lgpup mddfu ldugm a,:pu pgddm §lu,: gmpu: fdl:d mf,um ,m§ll
,:udp la:,§ mpg,f ma,mp ulfdg ld§pm puffd ufdau dg:a§ umdf§ ud§fa p§alu
d§gap lfl,l lddum la§a§ dddpl l:,uf pmupf §dp§p :uugl p,p,§ §§gmm l:gaf
ufauu a:p:m ggd:d §,,pg :§mua ,§:ug al,f§ d,§pf gupg, dmafu paudl :amfm
pmmff gmfg: mgud: ,a,pu u§dpf p:ppg gamdf pudpd a::gm §u:,f lp,l, §ddgp
l§m,: ,lppd ,a:fu m:u§d lfpml pfa,p au§l: f:f:: ::§§§ ammdp gu:m, ldldm
mmugg §,dlg fmpg values = 1330 from fmpg
Putting many options together in a single package has proven fairly easy,
with surprizing results, having long neglected stream ciphers as not too
promising. Maybe something here is useful to others.
As characters are the product of the generator involved, numbers not
necessarily as digits, perhaps it is best to call tyhe generator part of
the mechanism in Pomegranate a pRCG, not a pRNG.
--
Some Turkeys can fly, for short distances. If you are to depend on
birds for communication, if it's with turkeys, consider the
discussions that might occur while feasting on one.
------------------------------
** 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
******************************
