Cryptography-Digest Digest #127, Volume #13 Thu, 9 Nov 00 01:13:00 EST
Contents:
Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware (Tom St Denis)
Re: Regarding assymetric encryption algorithms ("Brian McKeever")
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile (Scott Craver)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile (Scott Craver)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile (Scott Craver)
Re: CHALLENGE TO cryptanalysts (Scott Craver)
Re: CHALLENGE TO cryptanalysts (David Schwartz)
Re: Authentication and taking credit (was Re: Protocol) ("rosi")
Does PGP sdk 1.7 have Prime Number Generator or Checking Functions? ("P.C. Teo")
Re: Hardware RNGs (Steve Portly)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile ("Trevor L.
Jackson, III")
Re: Hardware RNGs (David Schwartz)
OT Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile ("Trevor
L. Jackson, III")
Re: Regarding assymetric encryption algorithms ("rosi")
Re: Purported "new" BXA Encryption software export restrictions (Anthony Stephen
Szopa)
About blowfish... (Cory C. Albrecht)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware
Date: Thu, 09 Nov 2000 01:00:50 GMT
In article <[EMAIL PROTECTED]>,
d <[EMAIL PROTECTED]> wrote:
> Command line One Time Pad utility. Options: pad generation, randomness
> testing, en/decryption, base64 en/decoding and disk wiping. ANSI-C
> source and DOS executable included.
>
> Free download at <http://www.vidwest.com/otp/>
>
> Your bug reports/other feedback will be gratefully received.
Perhaps you missed the boat, OTP's are not practical solutions!
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Brian McKeever" <[EMAIL PROTECTED]>
Subject: Re: Regarding assymetric encryption algorithms
Date: Wed, 8 Nov 2000 17:47:54 -0800
<[EMAIL PROTECTED]> wrote in message
news:8ucsfb$le9$[EMAIL PROTECTED]...
[ruthless snipping of intentionally massively-overkill system]
> p,q,e different primes of 513 BYTES
Can anyone estimate how long this step would take? Are there any rules of
thumb for this?
Brian
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile
Date: 9 Nov 2000 01:43:33 GMT
Richard Heathfield <[EMAIL PROTECTED]> wrote:
>>
>> [snip] Amazing. Maybe you should run speed tests.
>
>I did (having first sorted out a test machine that I didn't mind
>reinstalling from scratch if need be). They're about the same. Mr
>Szopa's may even have a slight edge (I didn't spend any time trying to
>make mine quick, after all). For speed, I have an ISO C version on the
>Web.
Does your program do the XOR a byte at a time or a long int
at a time? More importantly, does it fwrite and fread in
units of bytes, or larger? I'm interested in what Mr. Szopa's
program is actually doing, and if it's reading in units of
bytes rather than larger chunks there could be a major speed
difference.
>Richard Heathfield
-S
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile
Date: 9 Nov 2000 01:46:15 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
>Here's the difference between most of you and myself:
>
>I ACT and you react: BIG difference.
Is this your way of claiming that you were the first person to write
and make available an XOR utility? As others have already pointed
out, people have already written such utilities.
Yours is a record-breaker for size, however.
-S
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile
Date: 9 Nov 2000 01:52:36 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>Scott Craver wrote:
>>
>> We just *told* you. It's a huge binary, not open, and
>> only runs on a single platform.
>
>You know why it is as large as it is. Don't complain to me. This
>is the nature of the modern GUI interface.
Um, no, it is not the GUI's fault. Other people have tried
and failed to make a GUI program bloated as yours. Others
have written much smaller utilities with GUIs.
Bloat is almost always a result of bad programming, not of
an API. Certain OS's and APIs do contribute more bloat,
but for the amazing record-breaking huge programs the bloat
comes from programmers who just don't know or care how to
keep a program from getting huge. Extra unneeded resources,
leaving in all the debugging info, no attempt at
optimization, et cetera.
>Why do you need it open source? It does what it is intended to do
>and what it is claimed to do and does no more than it is supposed
>to do and you can prove this by using it
NO. While I trust that you are not providing an evil
trojan horse (or accidentally distributing a 70KB binary
with 230KB of viruses attached,) it is NOT EVER the case
that merely using the program proves it works as
specified.
-S
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Subject: Re: CHALLENGE TO cryptanalysts
Date: 9 Nov 2000 02:02:33 GMT
Melinda Harris <[EMAIL PROTECTED]> wrote:
> There will be no-holds barred hacking rules to illustrate the
> confidence in the strength of A.N.E.C.
Of course, the way to illustrate any confidence in a cipher's
strength is to describe the algorithm, keeping only the
key secret. A strong cipher must be so strong that it
is uncrackable even if the algorithm is known.
In fact, providing only ciphertext usually betrays a
severe lack of confidence in the algorithm's strength.
Creating a cryptographic challenge with a secret algorithm is
like challenging someone to a duel but not telling him/her
where in the world the duel will take place.
I trust that this information will be provided at or before
the beginning of the challenge?
>[EMAIL PROTECTED]
-S
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: CHALLENGE TO cryptanalysts
Date: Wed, 08 Nov 2000 18:43:13 -0800
Scott Craver wrote:
> Of course, the way to illustrate any confidence in a cipher's
> strength is to describe the algorithm, keeping only the
> key secret. A strong cipher must be so strong that it
> is uncrackable even if the algorithm is known.
>
> In fact, providing only ciphertext usually betrays a
> severe lack of confidence in the algorithm's strength.
> Creating a cryptographic challenge with a secret algorithm is
> like challenging someone to a duel but not telling him/her
> where in the world the duel will take place.
>
> I trust that this information will be provided at or before
> the beginning of the challenge?
After all, I can create a secret cipher where "1" codes for "When in
the course of human events" and "0" codes for "it becomes necessary". I
can then produce just the ciphertext ("10") and defy anyone to decrypt
it.
DS
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: Authentication and taking credit (was Re: Protocol)
Date: Wed, 8 Nov 2000 22:27:29 -0500
Paul Crowley wrote in part in message
<[EMAIL PROTECTED]>...
>(Posted and mailed)
>
>David Wagner wrote:
>>
http://gatekeeper.dec.com/pub/DEC/SRC/technical-notes/abstracts/src-tn-1998-
007.html
>
>Thought-provoking paper. There's no point in trying to protect credit
(Just poor me again. So if you would please, please...)
Mainly for Paul and David.
To be honest, when I first read it, my mind went virtually blank. I
think I got what it
was trying to say, but I do not get it.
Since you two have obviously read it as well, I would like to ask: Does
it seem to
you that different levels of semantics are mixed up good? Any opinions would
be
appreciated.
Thanks
--- (My Signature)
------------------------------
From: "P.C. Teo" <[EMAIL PROTECTED]>
Subject: Does PGP sdk 1.7 have Prime Number Generator or Checking Functions?
Date: Thu, 9 Nov 2000 11:17:01 +0800
Does PGP sdk 1.7 have Prime Number Generator or Checking Functions?
I don't see any description of such kind of functions in the Reference Guide
of PGP sdk 1.7
Any help will do, thanks.
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Wed, 08 Nov 2000 22:12:01 -0500
David Schwartz wrote:
> Steve Portly wrote:
>
> > The Pentium time stamp takes up so little system overhead that you can repeat it
> > many times without bogging down your system. I found that it only takes about 40
> > microseconds to produce 1 bit of satisfactory entropy. (your mileage may vary).
> > I used a crude home grown frequency analyzer to check to see where the
> > distribution went flat. My sample size was a gig in size and every way I tried
> > to slice it I came up with an even distribution better than the reported results
> > of hardware cards. If you are a programmer it is definitely worth experimenting
> > with.
>
> The problem is, unless you can come up with a satisfactory theoretical
> explanation of the source of this randomness, all you can say is that
> they're apparently random and that you have one bit of apparent entropy.
> It may be that the data appears random, but is actually predictable
> based upon sufficient knowledge of the initial conditions (what's in the
> caches) and the set of rules that govern their behavior (wait states,
> frequency ratios, cache sizes and associativity, and so on).
>
> More entropy cannot come out than is going in. So it's important to
> identify the sources coming in and quantify how much entropy they're
> providing. Even that's not enough, because there's the question of how
> much less entropy came out than went in.
>
> However, from a practical standpoint, there appears to be massive
> amounts of entropy in this data. Far greater than can be theoretically
> justified. And there doesn't seem to be any way to predict it. However,
> that may just mean that an attacker needs to be more sophisticated. See,
> for example, how relatively incompressible the output of
> http://youknow.youwant.to/~djls/entropy.c seems to be.
>
> DS
For applications that are network intensive, timing packets would be a better
alternative than timing interrupts. Network jitter is over 100 times greater than
system jitter so the laws of physics give you a natural firewall. "One cycle count"
is easily lost to signal rise times even inside your system case. I doubt anyone would
be able to monitor TS intervals from a distance of more than a few feet. This is
sci.crypt so a detailed explanation of system jitter would probably be off
topic.
------------------------------
Date: Wed, 08 Nov 2000 22:41:15 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile
Richard Heathfield wrote:
> Scott Craver wrote:
> >
> > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> > >"Trevor L. Jackson, III" wrote:
> > >>
> > >> Pointing out the limitations of your software is to amusement as Jerry Springer
>is
> > >> to entertainment.
> > >
> > >You said it: so what are the limitations of the XOR software
> > >utility?
> >
> > We just *told* you. It's a huge binary, not open, and only runs on a
> > single platform.
> >
> > -S
>
> Mr Szopa's program is 315392 bytes in size after decompression. No
> source code is provided. I know I'm not the only one to think this to be
> the height of lameness. So, perhaps not unnaturally, I wondered (purely
> in the spirit of scientific enquiry, as befits a sci. newsgroup) if it
> were possible to write an even lamer program. I tried hard. But did I
> succeed? That's for the scientific community to judge. (I was going to
> save this till April 1st, but the moment seems ripe.)
>
> I'm afraid I can't challenge the original for file size, even though I
> made every effort not to tell the compiler to optimise for size, and
> even copied the OP's idea to bloat the binary by making the interface
> graphical. I included some radio buttons and a progress bar, in a
> desperate attempt to add even more bloat. I managed to scrape together
> 302592 bytes of binary - just 12800 bytes short of the target.
>
> I chose C++ Builder as my development platform, and Borland are working
> hard to make Builder portable to Linux, so although I match the original
> on lack of actual portability, my program is - alas - potentially
> portable.
>
> Unfortunately, the full source code (C++ Builder files, I'm afraid) is
> available at http://users.powernet.co.uk/eton/crypto/SNAsrc.zip (around
> 8 kilobytes zipped). This doesn't bode well for the title challenge.
>
> On features, I think I have him. My program doesn't just do the XOR
> thing. It also has two other settings - Vigenere (re-using the shorter
> file to ensure that the longer file is fully encrypted) and Bit Flip -
> the original SNA-Coil algorithm which some of you may remember.
>
> You can get the binary at
> http://users.powernet.co.uk/eton/crypto/SNACoil.zip (around 150
> kilobytes zipped), if you're the kind of person who runs Windows
> binaries without having first personally built them from source code.
> (You have my word, for whatever you think my word is worth, that the
> program is non-destructive in all respects EXCEPT it will happily
> overwrite an existing file if you specify it as an OUTPUT file. It never
> modifies its input files.)
>
> So, my question is: have I succeeded in outlaming the lamer? Only you
> can decide.
Let's not be premature. You've alluded to certain operational situations in which data
destruction may occur. Have you fully investigated this behavior? Are you able to
tell us
what behavior to expect when the output file is the same as one or both of the input
files?
Also, how well does the repeat-shortest-file feature work when the shortest input file
has
zero length?
Does the software check for input files that are all zero? This check does not offer
an
efficiency improvement, but it does make additional bloat available if you warn the
user
about the insecurity of the output.
If your program is more destructive or has more /witless/* features than his then you
have
a good case for an affirmative response to your query.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Wed, 08 Nov 2000 19:38:46 -0800
Steve Portly wrote:
> For applications that are network intensive, timing packets would be a better
> alternative than timing interrupts. Network jitter is over 100 times greater than
> system jitter so the laws of physics give you a natural firewall. "One cycle count"
> is easily lost to signal rise times even inside your system case. I doubt anyone
>would
> be able to monitor TS intervals from a distance of more than a few feet. This is
> sci.crypt so a detailed explanation of system jitter would probably be off
> topic.
These are measuring the same thing. So it's not an alternative.
DS
------------------------------
Date: Wed, 08 Nov 2000 22:46:02 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: OT Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile
Anthony Stephen Szopa wrote:
> By the way, Gore hasn't lost yet. 11/8/00 11:35 am PST
Hmmm. I think this explains quite a bit.
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: Regarding assymetric encryption algorithms
Date: Wed, 8 Nov 2000 23:53:21 -0500
NoLimitB wrote in part in message ...
> I am seeking a solid assymetric encryption algorithm for the purpose of
encoding
> small amounts of information ( generally less than 512, but sometimes up
to 1024 octets ).
> The only necessity is a VERY high level of security.
(Just poor me again. So if you would please, please...)
May have one for you.
The informal "VERY high level" is hard to get a precise sense of.
Anyway, I believe I can offer something that kind of more than basically
qualifies.
But there are strings attached.
I may charge a fee, even though that could be nominal. However, it could
be free in
a number of instances. E.g. if it is used for the promotion of freedom of
speech
(advocation of hate does not qualify).
If I understand correctly, you only need algorithms but not executable
code.
Also, we understand that the distribution of the asymmetric encryption
key is not
part of concern of this system by the algorithm.
If padding needs to be used or any random input required, the assumption
is that
you have a 'good enough' one available. In other words, this algorithm does
not cover
that area.
I can not give that to you right now. You have to wait a number of
months. Or I can
give it to you now, but you have to keep it confidential for a number of
months before
making it public or sharing it with other people (if you choose to).
Since your primary concern seems security (and an overkill is no problem
for you),
I venture to make a less dramatic statement. If this particular scheme
falls, all asymmetric
ones that I know of will as well. Unfortunately, it may also be one of the
fastest asymmetric
algorithms, and bulk data encryption should not be a problem, either.
If you are interested (even with the strings attached), please let me
know.
--- (My Signature)
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto,alt.hacker
Subject: Re: Purported "new" BXA Encryption software export restrictions
Date: Wed, 08 Nov 2000 21:23:05 -0800
CMan wrote:
>
> At the time the White House held a news conference to announce that they had
> "relaxed" the encryption regulations I was convinced that the White House
> was again lying about what was being done re: encryption.
>
> At that news conference Attorney General Janet Reno was asked if the new
> regulations had changed anything. She at first avoided the question. Then
> the reporter pointed out that she had not answered the question and
> repeated, What has changed?" Her reply in a rare fit of honesty was "Nothing
> has changed!"
>
> The White House, staff putting on this incredible dog and pony show
> involving that idiot Commerce Secretary Casey, was of course apoplectic at
> this truthful answer.
>
> I encourage anyone who has swallowed the lies put forth by the White House
> on encryption policy to go to the BXA web site and read the regs.
>
> NOTHING HAS CHANGED!!!!!!!
>
> The encryption regulations HAVE NOT BEEN RELAXED!!!
>
> Read the classification procedure. There is still unconstitutional prior
> restraint!!! I'd rather fill out a thousand tax returns than try to comply
> with these regulations. There is NO WAY anyone could become compliant
> without expert legal counsel and then only if your code passes review and
> meets unpublished requirements - like backdoors maybe - or "workfactor
> reduction fields."
>
> I can't believe they were able to pull the wool over the eyes of our famous
> cryptographer friends who have written popular books on cryptography -
> unless these guys now have corporations and big fat government contracts!!!
>
> Hey BXA, give me a big fat government contract and I'll stop pointing out
> the emperor's lack of clothing just like the rest of them!! C'mon, share the
> wealth...
>
> JK
>
> --
> CRAK Software
> http://www.crak.com
> Password Recovery Software
> QuickBooks, Quicken, Access...More
> Spam bait (credit E. Needham):
> root@localhost
> postmaster@localhost
> admin@localhost
> abuse@localhost
> webmaster@localhost
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Purported "new" BXA Encryption software export restrictions
> >
> > I have had time to look up these purported new BXA regs.
> >
> > But first let me digress.
> >
> > The OAR-L3 random number generation software is exactly the same
> > software as OAP-L3: Original Absolute Privacy - Level3 encryption
> > software except there is absolutely NO encryption or decryption
> > capability.
> >
> > Not only have the encryption and decryption GUI forms, menus,
> > buttons, etc. been deleted, but also, the encryption and decryption
> > source code has been deleted, then the entire package recompiled.
> > So there is no way to enable any encryption or decryption methods
> > or capabilities using OAR-L3.
> >
> > You can download OAR-L3 Random Number Generation Software by
> > going to http://www.ciphile.com
> >
> > Go to the Downloads Currently Available web page.
> > Scroll to the bottom of the page.
> >
> > Click on the blue anchor tag: OARL3_41.zip and ReadMe_R.zip to
> > download.
> >
> > There is a new XOR Software Utility (freeware) available at
> > http://www.ciphile.com
> >
> > Go to the Downloads Currently Available web page.
> > Scroll to the bottom of the page.
> >
> > Click on the blue anchor tag: CiphileXOR_11.zip to download.
> >
> > OAP-L3 encryption software uses the XOR process to encrypt messages.
> >
> > Now my comments and decision regarding these purported new BXA regs:
> >
> > Except for (I think) there are no longer any restrictions on key
> > length and that the software can be exported immediately, there is
> > one major proviso in any case:
> >
> > The exporter needs to file an encryption classification request by
> > the time the encryption software is exported. Here is what the
> > exporter must do:
> >
> > "For all classification requests of encryption items provide
> > brochures or other documentation or specifications related to the
> > technology, commodity or software, relevant product descriptions,
> > architecture specifications, and as necessary for the technical
> > review, source code. Also, indicate any prior reviews and
> > classifications of the product, if applicable to the current
> > submission. Provide the following information in a cover letter
> > with the classification request:
> > (a) State the name of the encryption item being submitted for
> > review.
> > (b) State that a duplicate copy has been sent to the ENC
> > Encryption Request Coordinator.
> > (c)For classification request for a commodity or software,
> > provide the following information:
> > (1) Description of all the symmetric and asymmetric encryption
> > algorithms and key lengths and how the algorithms are used. Specify
> > which encryption modes are supported (e.g., cipher feedback mode or
> > cipher block chaining mode).
> > (2) State the key management algorithms, including modulus
> > sizes, that are supported.
> > (3) For products with proprietary algorithms, include a textual
> > description and the source code of the algorithm.
> > (4) Describe the pre-processing methods (e.g., data compression
> > or data interleaving) that are applied to the plaintext data prior
> > to encryption.
> > (5) Describe the post-processing methods (e.g., packetization,
> > encapsulation) that are applied to the cipher text data after
> > encryption.
> > (6) State the communication protocols (e.g., X.25, Telnet or
> > TCP) and encryption protocols (e.g., SSL, IPSEC or PKCS standards)
> > that are supported.
> > (7) Describe the encryption-related Application Programming
> > Interfaces (APIs) that are implemented and/or supported. Explain
> > which interfaces are for internal (private) and/or external (public)
> > use.
> > (8) Describe whether the cryptographic routines are statically
> > or dynamically linked, and the routines (if any) that are provided
> > by third-party modules or libraries. Identify the third-party
> > manufacturers of the modules or toolkits.
> > (9) For commodities or software using Java byte code, describe
> > the techniques (including obfuscation, private access modifiers or
> > final classes) that are used to protect against decompilation and
> > misuse.
> > (10) State how the product is written to preclude user
> > modification of the encryption algorithms, key management and key
> > space.
> > (11) For products that qualify as ``retail'', explain how the
> > product meets the listed criteria in Sec. 740.17(b)(3) of the EAR.
> > (12) For products which incorporate an open cryptographic
> > interface as defined in part 772 of the EAR, describe the Open
> > Cryptographic Interface.
> > (d) For classification requests regarding components, provide
> > the following additional information:
> > (1) Reference the application for which the components are used
> > in, if known;
> > (2) State if there is a general programming interface to the
> > component;
> > (3) State whether the component is constrained by function; and
> > (4) the encryption component and include the name of the
> > manufacturer, component model number or other identifier.
> > (e) For classification requests for source code, provide the
> > following information:
> > (1) If applicable, reference the executable (object code)
> > product that was previously reviewed;
> > (2) Include whether the source code has been modified, and the
> > technical details on how the source code was modified; and
> > (3) Include a copy of the sections of the source code that
> > contain the encryption algorithm, key management routines and their
> > related calls."
> >
> > IN EFFECT NOTHING HAS CHANGED.
> >
> > I am not able to go through all this hassle.
> >
> > I am sorry.
> >
> > AS
You did scroll down my post and see the license submission
requirements, didn't you?
I agree with you 100%.
Beware of those who calmly implore you to submit comply sell out.
They are working against your freedom. They are nuts.
------------------------------
From: [EMAIL PROTECTED] (Cory C. Albrecht)
Subject: About blowfish...
Date: Thu, 09 Nov 2000 05:35:04 GMT
Hello all,
I'm looking at the source for SSLeay (0.9), and the blowfish algorithm=20
specifically. I think I understand what it's doing, except for one part...
Depending on what one defines BF_ROUNDS to, you can get either 16 or 20 rou=
nd=20
encryption, and they struct for the keys is defined thusly:
typedef struct bf_key_st {
BF_LONG P[BF_ROUNDS+2];
BF_LONG S[4*256];
} BF_KEY;
My problem comes about in BF_set_key() when the initial key bf_init is copi=
ed=20
into the initially empty key provided by the user - bf_init.P is only 18 lo=
ng,=20
seemingly made only for 16 round blowfish. Anything more than 16 ( + 2) wil=
l=20
get written into key.S, and then get overwritten later on when key.S is=20
filled.
Can I get a 20 round version of bf_init from somewhere? Or is there a reaso=
n=20
why it has too few? Why? (Feel free too imagine a little kid going "why! wh=
y!=20
why! why!... :-)
--
Cory C. Albrecht
http://members.home.com/cory.albrecht/
------------------------------
** 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
******************************
