Cryptography-Digest Digest #908, Volume #10 Fri, 14 Jan 00 22:13:01 EST
Contents:
Re: LSFR ("Douglas A. Gwyn")
Re: Random numbers generator ("Douglas A. Gwyn")
Re: Ciphers for Parallel Computers ("Douglas A. Gwyn")
Re: Blum, Blum, Shub generator (Terry Ritter)
Re: Need sources for cryptology / security (Timothy M. Metzinger)
Re: New Crypto Regulations ("Douglas A. Gwyn")
Re: "1:1 adaptive huffman compression" doesn't work (Mok-Kong Shen)
Re: Blum, Blum, Shub generator (Terry Ritter)
Re: Blum, Blum, Shub generator (Mok-Kong Shen)
Re: Random numbers generator (Eric Lee Green)
Why didn't I think of this...crypto patent for sale on eBay (Bruce Schneier)
Re: Random numbers generator (Michael Sierchio)
Re: Little "o" in "Big-O" notation ([EMAIL PROTECTED])
Re: Blum, Blum, Shub generator (Michael Sierchio)
THE ULTRA SECRET (Jim Reeds)
Re: Blum, Blum, Shub generator (David Wagner)
Re: Cryptography Exporting? (Guy Macon)
Re: New Crypto Regulations (Guy Macon)
Re: RANT New Crypto Regulations (ray gaudia)
Re: Ciphers for Parallel Computers (Tim Tyler)
Re: Does this internet encryption item transfer scenario make sense? ("Douglas A.
Gwyn")
Re: Word Counter (Jerry Coffin)
My Encryption system (Jeff Lockwood)
Re: Triple-DES and NSA??? (lcs Mixmaster Remailer)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: LSFR
Date: Fri, 14 Jan 2000 21:16:03 GMT
Terje Mathisen wrote:
> To sample this counter, just read both the data and carry array, and add
> them together.
The key point is that this defers all "ripple" effects until the
register (pair) is sampled, rather than at each tick of the counter.
That is probably acceptable for your application, and it is in many
ways simpler than the alternatives.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Random numbers generator
Date: Fri, 14 Jan 2000 21:19:31 GMT
Sander Vesik wrote:
> And problems with the randomness of many of the lower bits, IIRC.
That's why the example implementation returns the high-order bits
of the accumulator.
> Why would one ever use rand() instead of random()?
Because it exists in all standard-conforming C implementations.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Ciphers for Parallel Computers
Date: Fri, 14 Jan 2000 21:25:39 GMT
Mok-Kong Shen wrote:
> ... I don't yet clearly see an advantage that pertains to only one
> side of the antagonist pair user-analyst. Higher speed can be of
> 'advantage' to both sides.
I think the assumption is that the work factor for the cryptanalyst
goes up at a higher rate (complexity-wise) than the work factor for
the encryptor, implying that for some sufficiently large key size,
the cryptanalyst can't afford the resources while the encryptot can.
Whether or not this assumption is correct is debatable.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Blum, Blum, Shub generator
Date: Fri, 14 Jan 2000 23:25:42 GMT
On Fri, 14 Jan 2000 16:22:26 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt Kent Briggs
<[EMAIL PROTECTED]> wrote:
>FYI: The reason I was asking about the BBS period was not to ensure that it
>was long but to know exactly what is was for a given pq. The equation to jump
>forward in the BBS stream is relatively simple but the equation to jump
>backwards is more complicated and involves an extended Euclidean calculation.
>If the exact period was known, I thought it would be an easier calculation to
>jump forward period - 1 steps than to go backwards 1 step. But based on the
>comments here, the period is not easy to calculate so that kills that idea.
Apparently, the main reason for using "perfect primes" and the other
construction details of BB&S was to define a structure that contains a
known long cycle length. This is not just greater than some minimum,
it is a particular computable length. That makes it possible to check
whether or not x0 is on the long cycle. And if it is, you may have
the information you need, *if* you follow the full BB&S construction.
This possibility will not exist with the more casual construction.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Timothy M. Metzinger)
Subject: Re: Need sources for cryptology / security
Date: 14 Jan 2000 23:36:35 GMT
In article <[EMAIL PROTECTED]>, "Roger W. Winget"
<[EMAIL PROTECTED]> writes:
>I am seeking sources of information on cryptology. I especially look
>forward to
>materials explaining the security / time to compute ratio of different
>algorithms.
>
>I thank you a thousand times in advance.
Aloha...
Start with "Applied Cryptography" by Schnier (hope I spelled it right). You'll
find LOTS of references to other good info.
Also, for a fun relaxing read with some good illustrations of real-world crypto
applications and political implications, get "Cryptonomicon" by Stephenson, now
in hardback in the sci-fi section.
Best Wishes,
Tim
Timothy Metzinger
Commercial Pilot - ASEL - IA AOPA Project Pilot Mentor
DOD # 1854 '82 Virago 750 - "Siobhan"
Cessnas, Tampicos, Tobagos, and Trinidads at FDK
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New Crypto Regulations
Date: Fri, 14 Jan 2000 21:36:12 GMT
wtshaw wrote:
> The most important fact regarding any of these regulations is that the
> source retains the tendency to be capricious, arbitrary, ...
The question everyone should be asking is, by what *right* does our
government control exportation of privately-developed cryptologic
technology? Is it necessary to protect the natural rights of our
citizens, or is it infringing on those rights? (I say the latter.)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Date: Sat, 15 Jan 2000 01:16:39 +0100
Tim Tyler wrote:
>
> I thought I explained. The compressor doesn't identify anything
> really. It's the bits at the end of the file that scramble an enitr block
> that do the revealing. They can show (for example) the size of the block
> size - or give other clues about the cypher being used.
>
> If you know the different parties present use different types of cyphers,
> information about the cypher used reflects on the identity of the sender.
If an analyst tries a key, then, depending on that key, the
decrypted compressed file will be uncompressed to a (presumed)
plaintext and in my scheme a certain number of filling bits will
be ignored. If he tries another key, then there will be another
(presumed) plaintext of generally another length and other filling
bits (and maybe also of another length.) So these filling bits are
'variable' and of such nature that he can't use them in general. But
I must admit that one 'can' construct very special cases where the
conditions are such that the analyst is effectively at the
place of the sender and is running himself the compressor, i.e.
he has full control over the state of the generator of the more or
less random (or non-random) filling bits. That, together with maybe
some other favourable circumstances, could indeed give him some real
advantage, though I would consider the probability of such special
cases occuring to be practically negligible. (I certainly can't
convince you, if you consider it to be not negligible. See also
my last paragraph below.)
>
> : Here the analyst tries a key
> : K to get a compressed file which he finds, say, to have 2 filling
> : bits 00. On repeated uncompresion-compression he finds other
> : patterns (01, etc) and that all these patterns occur equal frequently.
> : So that original '00' is nothing 'particular' and hence he can't
> : derive any information from that particular occerence of the
> : filling bits, can he?? (Sorry that I repeat what I said.)
>
> Equal frequency != random. If the endings are random, the analyst gains
> nothing. But if there's any detectable pattern, all may be lost.
>
> As a crude example 1010101010101010 has the same frequency of 0s and 1s as
> a typical random string - but is *very* easy for an analyst to spot.
Using the example with the simple-minded implementation, if the
analyst gets a consecutive series of messages and uses the correct
key he will find the filling bits in the order 00, 01, 10, 11 in
case these messages are such that they all lead to 2 filling
bits (no more no less). Otherwise, if either some messages lead
to filling bits of other lengths, or the key he uses is not
correct, then he will not get 00, 01, 10, 11 in that order in
general. Yes, there is thus a conceivable problematical case here,
but it's chance of occurence is very small in my view. Using a better
implementation, e.g. with the aid of the system time, this could be
largely eliminated, i.e. the risk becomes negligible practically,
though (certainly you would point out rightaway) it 'can' occur.
Yes, I agree that, if one wants things perfect, then one should indeed
use the 1-1 scheme. (I personally tend not to seek perfection but
only certain sufficient amount of security in relation to the actual
circumstances, since an encryption system consists of many components
and not everyone of these 'can' be perfect.) So, you win the debate,
since my 'quite and dirty' (admitted at the very beginning of
my first follow-up) scheme certainly can't be exactly 'equivalent'
to a theoretically satisfying one.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Blum, Blum, Shub generator
Date: Sat, 15 Jan 2000 00:23:37 GMT
On 14 Jan 2000 23:00:03 -0000, in
<[EMAIL PROTECTED]>, in sci.crypt lcs Mixmaster
Remailer <[EMAIL PROTECTED]> wrote:
>[...]
>BBS proves that with randomly chosen x and an RSA modulus (with
>p=q=3 mod 4) then if anyone can predict the next bit with even an
>epsilon advantage, the modulus can be factored. This is the proof
>of strength. If you assume that RSA is secure, BBS with a random x
>is secure. Cycle-counting can gain you no more strength than that.
>It is a pointless and counter-productive effort.
The BB&S security proof occurs, as I recall, in the first third of
their paper. This is the part that most people can read and then
think they understand BB&S.
The last 2/3 of the BB&S paper shows how to construct systems which
fit the characteristics of their earlier result. The last part is not
fun to read, and can hardly have been easier to write. The purpose
for all the complexity and detail is not well described, which makes
the last part seemingly irrelevant and so it is generally ignored by
most readers.
But if the first part was all that was required, why did they bother
to lay out the arduous and complex construction of the last part?
Unless we consider these people actual bumbling fools, they understood
their own security proof, and probably much better than we do even
now. So if their proof was insufficient for them, I think we would be
well advised to consider it insufficient for us.
It seems to me that one would have to have at least their level of
number theory expertise before one could rationally start throwing out
the BB&S construction because it all seems so unnecessary. That's not
me.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Blum, Blum, Shub generator
Date: Sat, 15 Jan 2000 02:00:21 +0100
Kent Briggs wrote:
>
> John Savard wrote:
>
> > There is a way to do a quadratic congruential generator modulo 2^n
> > guaranteed to have maximal period
>
> How?
See V. S. Anashin, Uniformly distributed sequences of p-adic
integers, Mathematical Notes, Vol. 55, No. 2, pp. 109-133 (published
by Plenum Publ. Corp.)
M. K. Shen
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Random numbers generator
Date: Fri, 14 Jan 2000 18:34:23 -0700
Tom St Denis wrote:
> > If you are on the Linux or FreeBSD platforms, simply fetch bytes from
> > /dev/urandom (or /dev/random, if you need truly random numbers as vs.
> a good
> > PRNG). Because they have access to internal entropy events within the
> kernel
> > to continually seed and re-seed the generator, they produce better
> results
> > than user-mode PRNG's can produce. /dev/urandom has had some slight
>
> I would argue this is a bad idea. Since dev/random is not portable. A
> good RNG fed thru AlgM [or a hash] would be better. It's more portable.
The difficulty in any RNG is to gain adequate bits of entropy. See the
Yarrow paper at http://www.counterpane.com for the lengths they had to
go through under the Windows platform in order to gain adequate bits of
entropy to generate a reasonable amount of random data within a
reasonable amount of time. Basically, they wedged all over the internals
of the Win32 platform.
The problem with this approach on the Unix platform is that the Unix
platform (of which FreeBSD and Linux are a subset) does not allow user
"wedges" into kernel vectors. Thus the reason for /dev/random under
Linux and FreeBSD, which, since it is wedged into kernel space, has full
access to interrupt jitter etc. that are good sources of entropy. If
you're stuck up in user space, you're left to use the jitter between
keystrokes and network packets as your source of entropy -- and both
could possibly be controlled by an attacker (much more easily than
low-level interrupts, anyhow).
Thus I would STRONGLY recommend that, if you are on the FreeBSD or Linux
platform, you use /dev/random as your primary source of random numbers.
Even if all you do with it is seed a PRNG for further numbers.
As for the portability issue:
#ifdef LINUX
#define RANDOM(x) devrandom_rand(x)
#endif
#ifdef FREEBSD
#define RANDOM(x) devrandom_rand(x)
#endif
#ifndef RANDOM
#define RANDOM(x) otherrandom_rand(x)
#endif
....
bytes=RANDOM(128)
....
'Nuff said.
For those of us who program for multiple platforms, #ifdef is our
friend... there are far more bigger differences causing problems porting
software between IRIX and Linux than the lack of a /dev/random presents.
--
Eric Lee Green [EMAIL PROTECTED]
http://members.tripod.com/e_l_green/
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Why didn't I think of this...crypto patent for sale on eBay
Date: Sat, 15 Jan 2000 01:37:37 GMT
http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=236358604
Bidding starts at $5M. Don't all bid at once, or you'll drop the
server.
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: Random numbers generator
Date: Fri, 14 Jan 2000 17:52:50 -0800
Bob Silverman wrote:
Hi Bob!
I am no longer at RSAS. I joined the start-up generation. I wish
to solicit your opinion on a PRNG. Please let me know if this is
a reasonable request.
Didja hear the one about Roger Schlafly and the banana slug? Oh,
nebbamind.
Cheers,
Michael
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Little "o" in "Big-O" notation
Date: Sat, 15 Jan 2000 01:49:17 GMT
Mike McCarty) wrote:
[...]
> I have never seen O and o used as the names for *sets*.
Computer scientists started using the notation with
a somewhat flaky "this is how we use it" kind of
definition. The set definition put it on a
respectable theoretical foundation.
> It would not be consistent with
>
> f(x) = x^2 + O(1/x)
>
> unless f(.) were somehow promoted to a set as well.
Yeah, that's a specially defined usage. It's
meant as shorthand for:
There exists some function g(x) in O(1/x)
such that f(x) = x^2 + g(x).
The same shorthand rule applies to "f(x) = O(h(x))".
We probably wouldn't use that one at all if ASCII
had a set membership symbol.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: Blum, Blum, Shub generator
Date: Fri, 14 Jan 2000 17:58:30 -0800
Terry Ritter wrote:
> Apparently, the main reason for using "perfect primes" and the other
> construction details of BB&S was to define a structure that contains a
> known long cycle length. This is not just greater than some minimum,
> it is a particular computable length. That makes it possible to check
> whether or not x0 is on the long cycle. And if it is, you may have
> the information you need, *if* you follow the full BB&S construction.
>
> This possibility will not exist with the more casual construction.
In particular, selecting two primes p,q == 3 mod 4 is insufficient.
The first condition, if you're to take the requirement that p & q
be special primes and only one of p,q has 2 as a quadratic residue, is
that p,q == 7 mod 8.
Terry is too modest, but I posted refs to his paper in an earlier post.
--
QUI ME AMET, CANEM MEUM ETIAM AMET
------------------------------
From: [EMAIL PROTECTED] (Jim Reeds)
Subject: THE ULTRA SECRET
Date: Sat, 15 Jan 2000 01:45:49 GMT
I just saw that F. W. Winterbotham's THE ULTRA SECRET
is being reprinted by Weidenfeld and Nicolson,
ISBN 0 297 64405 X. The price (in England) is GBP 16.99.
It created a sensation when it came out 25 years ago.
--
Jim Reeds, AT&T Labs - Research
Shannon Laboratory, Room C229, Building 103
180 Park Avenue, Florham Park, NJ 07932-0971, USA
[EMAIL PROTECTED], phone: +1 973 360 8414, fax: +1 973 360 8178
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Blum, Blum, Shub generator
Date: 14 Jan 2000 18:06:56 -0800
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
> There is a way to do a quadratic congruential generator modulo 2^n
> guaranteed to have maximal period, but whether it has the desirable
> security properties of BBS or not is debatable, [...]
<HANDWAVING>
Such generators can (I believe) be broken by an iterative process: first,
you break it mod 2; then you break it mod 4; and so on. The information
learned at each stage lets you do the next stage efficiently.
</HANDWAVING>
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Cryptography Exporting?
Date: 14 Jan 2000 21:14:23 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jeff
Williams) wrote:
>It's nearly the end of the week. I'm tired. Was this meant to be funny?
>Specifically, how do I make certain that a Cuban, Iraqi, etc, cannot
>download the source? How much effort, on my part, to prevent such
>an occurrence is considered to be legally adequate? If this requirement
>is thoroughly unreasonable (and bureaucrats are frequently
>unreasonable) how does this improve things?
If you provide the source, you don't have to restrict distribution in
any way. Those rules are for commercially sold programs which almost
always keep their source secret.
On consequence of this is that Linux can have a single version with
strong encryption while Microsoft Windows must have two versions
with strong or weak encryption depending on where the buyer and
seller reside.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: New Crypto Regulations
Date: 14 Jan 2000 21:17:43 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jim)
wrote:
>How much does it cost to buy a congressman these days?
How *DARE* you imply that a Congressman of Our Great Nation can be
bought!? Scurrilous lies, I tell you! I do, however, have quite a
few that are for rent...
------------------------------
From: [EMAIL PROTECTED] (ray gaudia)
Subject: Re: RANT New Crypto Regulations
Date: Sat, 15 Jan 2000 02:35:32 GMT
you guys are amazing. this is truly one of the best presidents this
country ever had. nobody will remember his trysts. they will
remember a republican congress that impeached. they will remember
more jobs created and the longest run of prosperity with low inflation
in this country's history. they will remember people off of welfare
and americorps and the end the middle east conflict and they'll
remember china coming of age and how america addressed it and the end
of the soviet union, and no new taxes, and nobody will care about
lips. your letting morality get in the way of the big picture. the
stock market and this vehicle right here, untaxed internet supported
by wiring the schools and hands off government and a break up of the
first dominant capitalist outfit to grab the frontpage of our eyes out
here on the net. that's the stuff that will be remembered. morality
will be fought over long after you and i are dead and it won't gain a
whit of a footnote, so crack the codes and focus on what you can add,
not what you think should be the morality of any group. heck, this
country is not founded on morality. it's founded on life, liberty and
the pursuit of happiness....embodied in a constitution...and nothing
more, on purpose. opinions are just that, airy fairy, mine included.
but the list of stuff above, that's what history's made of.
later, end of rant
On Fri, 14 Jan 2000 15:03:59 -0700, "John E. Kuslich"
<[EMAIL PROTECTED]> wrote:
>I am embarrassed all right. As should every citizen of this land who has
>to see that mendacious laughing stock stand up for a great nation. We
>should all be embarrassed.
>
>And as for you...Why the heck the Virgin Islands? How in the heck can
>they stay virgin for so long. Sounds like a pretty stern place for a
>vacation?
>
>You...you DEMOCRAT! :-)
>
>Or take Extra Virgin olive oil. How can anything be EXTRA virgin?
>
>That's all, I promise. I have had my little rant. Now back to cracking
>passwords.
>
>...Sound of the lid coming down..."clank"
>
>JK
>
>--
>John E. Kuslich
>Password Recovery Software
>CRAK Software
>http://www.crak.com
>
>JPeschel wrote:
>>
>> John E. Kuslich [EMAIL PROTECTED] writes, in part:
>>
>> >What kind of government can get away with making laws the meaning of
>> >which are not clear until such time as one is prosecuted for violating
>> >such laws?
>>
>> then rants, in part:
>>
>> >Perhaps the answer is a government led by a man who can lie under oath,
>> >violate his marriage vows with a post pubescent bimbo in the Oval
>> >Office, and keep a Cabinet together after using them to lie to the
>> >public and assist in the cover-up of his immoral acts.
>> >
>>
>> Put a lid on it, John. You only embarrass yourself.
>>
>> Joe
>>
>> __________________________________________
>>
>> Joe Peschel
>> D.O.E. SysWorks
>> http://members.aol.com/jpeschel/index.htm
>> __________________________________________
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Ciphers for Parallel Computers
Reply-To: [EMAIL PROTECTED]
Date: Sat, 15 Jan 2000 02:07:11 GMT
John Savard <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote, in part:
:>In some respects, /enforced/ serial operation (i.e. operations which it
:>is simply not possible to efficiently parallelise) is desirable, since
:>it forces the attacker to perform operations in sequence as well.
: Well, maybe, but I can't think of a way to force an attacker to
: perform a brute-force search of the keyspace serially.
Of course not. However, you can pretty-much force him to perform
operations in serial in the process of decrypting with any particular key.
This is what I meant.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
I love work. I can look at it for hours.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Does this internet encryption item transfer scenario make sense?
Date: Sat, 15 Jan 2000 01:24:00 GMT
ray gaudia wrote:
> This may be puerile, but this is the scenario we think can combine the
> best of both worlds, the efficiency of the internet, and the privacy
> of the point to point POTS.
If you don't think the telephone system can be hacked
or simply eavesdropped, think again.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Word Counter
Date: Fri, 14 Jan 2000 19:54:42 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> I am looking for word counting software, a program which will not only count
> the number of words in a document, but actually physically number them. Does
> anyone know of such software?
Hmm...perhaps (in AWK):
BEGIN { NUM = 0; }
{ gsub("[][(),.;:{}!?\"]", " ");
for (I=1; I<=NF; I++)
printf("%d: %s\n", NUM++, $I);
}
Depending on the sort of input you're working with, and what you want
to count as a word, you might want to get rid of the gsub line -- it's
basically just getting rid of most punctuation. Alternatively, you
might want to add characters to the first string, to keep them from
being counted as words (or parts of words) either. Given the rather
vague definition of "word", this sort of stuff is more or less
inevitable.
As-is, this produces output at one word per line -- if you want to
change that, the format string in the printf call is what you'll need
to play with.
AWK, PERL, etc., are nice for jobs like this since short scripts like
this are easy to tailor for specific jobs. If you wanted a word
frequency counter, you could use:
{ gsub("[][(),.;:{}!?\"]", " ");
for (I=1; I<=NF; I++)
words[$I]++;
}
END { for (I in words) printf("%s:\t%d\n", I, words[I]); }
Note that as-is, this prints its output in unsorted order -- for most
purposes, you'll want to feed its output to a system sort program.
Whether you want alphabetical order or something like a descending
list by frequency depends a bit on what you're doing.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jeff Lockwood <[EMAIL PROTECTED]>
Subject: My Encryption system
Date: Sat, 15 Jan 2000 12:01:38 +1100
Description of my R.A.T. encoding and decoding system
Notes:
all values and variables mentioned in this document will be single byte
quantities , with values ranging from 0-255.
the key is an array of 256 bytes; containing all all the possible values,
sorted into a random order, with one extra requirement: the value contained
in each cell of the array cannot be the same as the index number of the cell
eg: cell 0 cannot contain 0, cell 1 cannot contain 1 ,...
Variables:
X This contains the data byte to be encoded
A This is used as an index into the key array
B This is used as an index into the key array, and for
the encoded output byte.
A1 This is used for temporary storage
B1 This is used for temporary storage
The Encode function:
1) Initialise variable A with the value 0 and B with 128.
2) read 1 byte into X.
3) The value in X is XORed with the byte in the key indexed by B,
and the result is stored in A1.
4) The value in A1 is XORed with byte in the key indexed by A,
and the result replaces the value stored in B.
5) Write out the the byte in B
6) Replace the value in A with the value in A1
7) Loop back to step 2 until all bytes have been encoded.
The Decode function:
1) Initialise variable A with the value 0 and B with 128.
2) read 1 byte into B1.
3) The value in B1 is XORed with the byte in the key indexed by A,
and the result replaces the value in A.
4) The value in A is XORed with the byte in the key indexed by B,
and the result is stored in X.
5) write out the value in X
6) replace the value in B with the value in B1.
7) loop back to step 2 until all bytes have been decoded.
Aditional notes:
The above functions are relesed into the public domain. You may use them
in any program (even commercial ones). they may also implemented directly
in hardware. I place no restrictions upon their use.
I also release this document into the public domain and permit distribution
without any restrictions.
Jeff Lockwood January 8 2000
I have also written a simple C program to demonstrate these routines, and
posted it in sci.crypt on the 8th of january
Jeff Lockwood <[EMAIL PROTECTED]>
PGP public key:
homepages.ihug.com.au/~satan/pgpkey.asc
------------------------------
Date: 15 Jan 2000 03:00:09 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Triple-DES and NSA???
Crossposted-To: alt.privacy,alt.security
> Did the NSA screw around with Triple-DES like they did with DES back in
> the 70s? How secure is it in comparison to blowfish and other
> algorithms?
> --
> Navid
Good FAQ on crypto algos here...
http://www.users.globalnet.co.uk/~firstcut/pgpfaq.html
3DES is probably the NSA's biggest headache.
------------------------------
** 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
******************************
