Cryptography-Digest Digest #906, Volume #10 Fri, 14 Jan 00 15:13:01 EST
Contents:
Re: Need some design suggestions for mass encryption (Mike Rosing)
Re: Blum, Blum, Shub generator (John Savard)
Re: Ciphers for Parallel Computers (John Savard)
Re: RSA (Bob Silverman)
Re: Random numbers generator (Bob Silverman)
A Hash Function Application (John Savard)
Stage 8: Singh's Cipher Challenge (Mark VandeWettering)
Re: Ciphers for Parallel Computers (Paul Koning)
Re: Cryptography Exporting? (Mike Rosing)
Re: LSFR (Scott Nelson)
Re: New Crypto Regulations (Mike Rosing)
Re: New Crypto Regulations (Jim)
Re: AES & satellite example (Jerry Coffin)
Re: AES & satellite example (Jerry Coffin)
Re: AES & satellite example (Jerry Coffin)
Re: New Crypto Regulations (Eric Lee Green)
Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?) (Derek Bell)
----------------------------------------------------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Need some design suggestions for mass encryption
Date: Fri, 14 Jan 2000 12:19:18 -0600
Albert Yang wrote:
> My company has commissioned me with a daunting task. We deal with
> highly sensitive private information (phone, credit card #, addy, etc..)
> and we want to save it on our DB encrypted. But there are certain
> things that have to happen. For example, I'm allowed to share my phone
> number or address with certain people, kind of like a group
> phonebook... So I would need to allow them access at any time. Yes, I
> know, sounds like a Public key deal, where I just encrypt with all the
> public keys that I want to have access to my stuff. But I need to be
> able to revoke access from certain people at any given time. So is
> there any way to design this smartly, where I don't have to basically
> decrypt, reencrypt with one less key, just to deny someone who use to be
> on my access list? Also, Public key crypto is slow, I'm not sure this
> is something that public crypto can do on the fly, fast enough. I would
> need to use something that's really fast. So any suggestions are
> welcome!
You definitly need 2 levels. The first level would be the data,
and each field needs to be encrypted with it's own key.
The second level is permissions. Use a public key for each user
on each field they are allowed access to. When you revoke access,
you only have to delete their public key encrypted version of
the field key.
This will work as long as the field key is only known by the
DB program and it never leaks out to the "real" world. It's also
a key management nightmare, but as long as you are dealing with
a DB, you can have one for the users keys too.
Speed won't be a problem if the DB is on a server anyway. The user
has to authenticate access to the DB, and you can get the field
keys for that user during their login.
Note that there's no real security here, once the data is in the
clear, the user can copy it. The trick is to leave the field
keys off the users machine, otherwise they can steal the key and
come back later to unlock the data directly. But this also
assumes they know how the data is stored etc. For the general
user, it should work fine.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Blum, Blum, Shub generator
Date: Fri, 14 Jan 2000 11:28:27 GMT
Kent Briggs <[EMAIL PROTECTED]> wrote, in part:
>But based on the
>comments here, the period is not easy to calculate so that kills that idea.
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, since it can't be
proven hard to analyze (given the unprovable assumption that certain
mathematical problems are genuinely hard) in the same way.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Ciphers for Parallel Computers
Date: Fri, 14 Jan 2000 11:25:36 GMT
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.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: RSA
Date: Fri, 14 Jan 2000 18:25:37 GMT
In article <85nas5$tkf$[EMAIL PROTECTED]>,
Michael J. Fromberger <[EMAIL PROTECTED]> wrote:
> >the code :
>
> >key : 51,3
>
> >616
<snip>
>
> The RSA encryption and decryption rule are modular exponentiation --
> that is:
>
> C = M^e (mod n)
>
> M = C^d (mod n)
>
> If n = 51, and d = 3, then you can take each x from the list above,
> and compute:
>
> x^3 (mod 51)
>
> ... to get the decoding. (With n = 51, p = 3 and q = 17, so e = 11).
>
> Hint:
>
> 616 = 4 (mod 51), 4^3 = 13 (mod 51)
NO! NO! NO!
616 is not a possible ciphertext with n = 51 and d = 3. (e = 11) Why?
Because RSA ciphertext is bounded by n. Secondly, I would assume e = 3,
not d = 3 as you do. The *public key* is the one which gets exposed,
not d.
The question is poorly posed.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Random numbers generator
Date: Fri, 14 Jan 2000 18:33:31 GMT
In article <85kq97$17c$[EMAIL PROTECTED]>,
"Simone Molendini" <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> where can I find C code for a *good* random number generator?
For what purpose? Cryptographic? Discrete Event Simulations?
Requirements differ for these. And you need to tell us what *you*
mean by "good".
>
> C rand() routine seems me to be a weak one: it has only a 32768 cycle
(it
> seems me).
Cycle length is not the only measure of a good PRNG. May I suggest
you read Knuth Vol 2? For example, a PRNG with a very very long period
but which exhibited strong auto-correlation would be useless for
either application cited above.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: A Hash Function Application
Date: Fri, 14 Jan 2000 11:42:47 GMT
Let us devise a method to encrypt a message that is used for
encrypting messages with a length up to N bits which uses a key
somewhat longer than N bits. (It's important the technique isn't just
a simple XOR, though.)
The intention is that it should be necessary to intercept at least two
messages before cryptanalysis even becomes theoretically possible.
Then, we might make use of this scheme to perform encryption as
follows:
Both parties posess a shared secret of the size of this large key or
larger.
Each message sent is accompanied by a session key, sent in any
convenient encrypted form (by conventional public-key techniques, or
enciphered by a key-exchange-key which is also a shared secret).
The large key is then encrypted by the session key, and then a one-way
hash is used to produce the actual long key used to encrypt the
current message.
The idea is that now the cryptanalyst _must_ be able to invert the
hash function in order to establish the connection between multiple
messages required to attack the cipher.
Since inverting a hash function isn't _fundamentally_ harder than,
say, finding the key of a block cipher given known plaintext, this
doesn't take cryptography into a new realm of unbreakability.
Also, it doesn't make messages deniable in the form shown: if a step
in the encryption involved XORing the message with a portion of the
key that was _not_ the output of a one-way hash function, *then* one
could construct a key causing any single message to decrypt to any
plaintext of the appropriate length.
Even so, it does seem to be a way to place an additional obstacle in
the path of the cryptanalyst.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mark VandeWettering <[EMAIL PROTECTED]>
Subject: Stage 8: Singh's Cipher Challenge
Date: Fri, 14 Jan 2000 10:38:35 -0800
I just finished The Code Book, by Simon Singh, and thought I'd at least
give a try to doing some of the Cipher Challenge. I'd solved
cryptograms before, so the first couple of stages didn't present much
difficulty. I'd never even attempted a polyalphabetic cipher like Stage
4 before, but was very pleased when I broke it in less than 40 minutes
or so, most of which was spent writing simple little programs to compute
correlations and do test encryptions. I found the key very easily, and
was rather pleased with the decoded text. :-)
So, having dispatched the simpler ones, I thought I might try Stage 8,
which is presumably a German Enigma cipher. I've read about the history
of the WWII code breaking efforts, but never had the time or incentive
to actually learn about what the principle weaknesses of the cipher
type. I thought I'd learn something first.
The basic approach I considered came about by considering this line of
thought: There are only 26^3 possible starting positions. That's a
small number. Indeed, my teensy little 400Mhz Celeron box can do trial
decryptions of all possible initial rotor positions in roughly 30
seconds. My idea was to monitor the distribution of outputs (I
originally considered just the entropy of the letter distribution, more
on this later) and keep track of settings where the entropy drops. The
primary problem I hadn't analyzed was the role that the plugboard would
have in disrupting the symbol frequencies. If they only operated to
scramble the outputs, there would be no problem, but since they also
operate on the inputs, they can significantly disrupt the output
statistics. Nevertheless, I plunged ahead...
So, I began by writing a simple Enigma simulator. It turned out to be
relatively difficult to find a truly adequate description of the Enigma
machine, and I am not quite sure I've got it down entirely. I found out
some obvious things (rotors stepping before encoding, the oddness in
stepping the middle rotor), but am still confused on a number of things.
In particular, I am not sure of the interaction between the ring
settings and the notch positions. Rather than pollute this newsgroup
with the code for this simulator, I'll just post this pointer:
http://tempest.idle.com/~markv/singh/stage8.html
which has a link to the simple ANSI C program I wrote to do the
simulation. If anyone finds any errors in the simulation, or even just
finds it of use, I'd appreciate an email.
It was about this time that I discovered the following webpage:
http://www.fortunecity.com/skyscraper/coding/379/gillog1.htm
which seemed to verify the basic idea behind the approach I was
considering. I considered this considerable morale boost (since I don't
_really_ know what I am doing :-) Since I was unsure of my approach
and the Enigma simulator, I decided to test it by taking a known text,
enciphering it, and trying to recover it via more or less exhaustive
search. For my initial tests I chose not to use any plugboard
transpositions. I selected for my test a brief passage from Bram
Stoker's Dracula (hey, it was available via Project Gutenberg). Since I
had the entire text of the novel, I also took the time to draw single
letter, digraph and trigraph distributions from the novel as well.
So, the basic loop of my search program loops over all 26^3 of the
possible decipherments, and gather single letter, digraph and trigraph
indices of coincidence for each output text. Quite predictable, these
indices peak rather nicely in the region where the rotors end up in the
right place. Success!
Well, sort of. There are an additional 26^3 ring settings. Gillogly's
exposition claims that the IC will peak near the proper initial
position, but my experiments with my simulation show that if I run the
same procedure with the rings improperly set, that their is no clear
trend or peak near the appropriate initial position. I _suspect_ this
might be because I still don't undertand the role that the ring settings
have in the encryption process. If anyone has any comments I'd love to
hear them.
All in all, it's great fun! I urge people to give it a shot.
Mark
--
Mark T. VandeWettering Telescope Information (and more)
Email: <[EMAIL PROTECTED]> http://www.idle.com/~markv/
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Ciphers for Parallel Computers
Date: Fri, 14 Jan 2000 13:44:34 -0500
Mok-Kong Shen wrote:
>
> John Savard wrote:
> >...
> > Thus, if technology reaches an upper limit to how _fast_ a single
> > processor can be made - but does not reach an upper limit to how
> > _cheap_ such a processor can be, thus allowing very large parallel
> > computers to be made, it is possible to make full use of such a
> > computer in encipherment with this kind of approach. Hence preventing
> > the otherwise inevitable result of an advantage to the cryptanalyst
> > resulting from the technology going in that direction.
>
> That parallel processing is used in all kinds of computing (where
> hardware is economically available) is a fact today. Clever compilers
> do quite a lot of automatic parallelizing of programs But 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. On the other hand, I suppose some sort of 'inefficiencies'
> are disadvantageous to the analyst.
Consider a brute force key search engine. It works on a single
ciphertext
block. So the issue of block chaining does not appear, and you can
parallelize it at will. On the other hand, when doing CBC encryption
you cannot even make use of a pipeline, let alone parallel encryptors
(unless you interleave, which makes your messages nonstandard).
So there's a situation where parallel computation massively favors
the attacker. The EFF DES cracker is an example of this type of
construct.
paul
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Cryptography Exporting?
Date: Fri, 14 Jan 2000 12:46:22 -0600
NFN NMI L. wrote:
>
> Hi. I read:
> http://www.cdt.org/crypto/admin/000110cryptoregs.shtml
> And was quite confused. So, what the heck are the rules now? I'm curious
> because I have a 1024-bit RSA program I'll be releasing soon.
Is it open source? Then all you have to do is tell BXA the URL.
No reviews required! If it's for sale, then you have to file
once, and make sure Cuba, Iraq, etc. can't download it. I'm
pretty amazed, but it looks like they actually figured out there's
no stopping bits over the net.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: LSFR
Reply-To: [EMAIL PROTECTED]
Date: Fri, 14 Jan 2000 19:09:01 GMT
On Fri, 14 Jan 2000 Robert Largent <[EMAIL PROTECTED]> wrote:
[big snip]
>...
>If you are interested in lfsr, a very nice Application
>Note with all of the taps listed for maximum-length
>lfsr up to 168 bits can be found at
>http://www.edtn.com/scribe/reference/appnotes/md000769.htm
>
An interesting read.
I note there's an error in the table.
(probably a transcription error)
102,101,36,35 isn't maximal length - probably
should have been 102,101,36,5 which is maximal.
All the others seem to be correct.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: New Crypto Regulations
Date: Fri, 14 Jan 2000 13:04:48 -0600
John E. Kuslich wrote:
>
> I hereby dare anyone to tell me that he/she has read and understood the
> new crypto regulations. They are simply beyond comprehension and
> deliberately so. These regs will make many a lawyer rich!
>
> see http://www.cdt.org/crypto/admin/000110cryptoregs.shtml
Nope, I won't take that dare! But the parts that affect me are
terrific.
> 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?
Where have you been for the past 50 years??!! It's been that way
for a long time, it's just that you're being directly affected now
and notice it.
> What kind of government can prohibit or license the sale of "Tempest
> fonts". These are fonts (software) intended to reduce compromising
> emanations. That's right, BXA, under the new crypto regs can stop
> export of software designed to allow someone to eavesdrop on the
> electromagnetic emanations from your computer!!!!
>
> Here's the quote:
>
> "a.4. Specially designed or modified to reduce the compromising
> emanations of information-bearing signals beyond what is necessary for
> the health, safety or electromagnetic interference standards;"
>
> It appears under "items controlled" way down near the end of the revised
> EAR document.
That's a good one. You meant to say how can they stop you from
shipping *software* that reduces emmissions. It doesn't, it's
about hardware. Basicly, the regs for health are high enough that
a truck outside can pick up the signals, and if you shield the box,
it's a munition. That's actually resonable and fair. The way
around that is to sell the shielding separately :-)
>
> 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.
Hey give the guy some credit! The democrats can now promise
a blowjob in every office! The (male) masses will certainly
vote for that. :-)
Here's the part I like:
3. Also in �740.13, to, in part, take into account the "open source"
approach to software development, unrestricted encryption
source code not subject to an express agreement for the payment of
a licensing fee or royalty for commercial production or sale of
any product developed using the source code can, without review,
be released from "EI" controls and exported and reexported
under License Exception TSU. .... To qualify, exporters must
notify BXA of the Internet location (e.g., URL or Internet address) or
provide a copy of the source code by the time of export. These
notifications are only required for the initial export; there are no
notification requirements for end-users subsequently using the
source code. Notification can be made by e-mail to
[EMAIL PROTECTED]
They've given up the Bernstien case. If it's freeware source, it's
freely distributable. That puts me in the clear!
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: New Crypto Regulations
Date: Fri, 14 Jan 2000 19:27:56 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 14 Jan 2000 10:27:17 -0700, "John E. Kuslich" <[EMAIL PROTECTED]> wrote:
>These regulations are an abomination and should be completely removed by
>an act of Congress.
>
>After all, we do have the best Congress money can buy. Perhaps we
>should tell BXA to stick it in their EAR.
Quite. How much does it cost to buy a congressman these days?
--
Jim,
nordland at lineone.net
amadeus at netcomuk.co.uk
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: AES & satellite example
Date: Fri, 14 Jan 2000 12:31:39 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Jerry Coffin <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > This is not a point I missed. In fact, it's one I addressed directly.
> > You'd want to do this if you had reason to believe that all the
> > ciphers you could include at launch time were at least somewhat likely
> > to be broken. I'm convinced that this possibility is so remote that
> > there's nothing to be gained by trying to design against it.
>
> So you are claiming that today's technology is such that we can
> design 5 ciphers and be certain that at least one of them is secure,
> but we cannot design one cipher and be certain it is secure?
I think "certain" is the wrong word. I think the likelihood of
finding a serious flaw in one is a GREAT deal higher than the
likelihood of finding serious flaws in all of them.
> You might be right, but it seems like a peculiar position to me.
The alternatives seem much MORE peculiar to me. The alternatives seem
to be to assume that either all of them are completely flawless, and
no useful attack can ever be found against any of them, or else that
all of them are equally flawed and attacks of exactly equal usefulness
will be found against all of them, and at essentially the same time at
that.
To me, that seems so unlikely as to defy any attempt at rational
discussion at all.
> 25 years ago, if the US had adopted 5 ciphers instead of DES,
> would we have been better off? How?
Yes and no. Given that DES appears to have been designed specifically
to be weak enough to break within a fairly predictable time-frame,
designing 5 (or more) with the same basic characteristics wouldn't
likely have done anybody much good.
A number of attacks have been found on DES, but it happens that key-
exhaustion is still a bit easier than any of the alternatives. With
any of the AES finalists, key-exhaustion is not a reasonable option,
but it seems unlikely to me that attacks that reduce the complexity of
attacks will suddenly stop being found.
> Were we just lucky that DES was as secure as it appears to be?
No, we weren't JUST lucky, but yes, I think some luck was involved. I
don't think they contemplated every attack yet devised when they
designed DES. It happens to be reasonably resistant to most, but yes,
I think in some cases that's more by accident than design.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: AES & satellite example
Date: Fri, 14 Jan 2000 12:31:36 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> If people are so helpless that, upon discovering that the "official
> standard" cipher is no good, they cannot switch to another cipher
> unless it, too, has become an "official standard", they have little
> hope of achieving secure communications in any event.
It's not really a question of helplessness. When the US government
makes something a standard, they often mean that literally: people
working with government data are often _required_ to follow all the
government standards relevant to their situation. Just for example,
even though DES is pretty thoroughly broken, there are still agencies
that have NO choice but to continue using it. They'll only be
_allowed_ to switch to 3DES when FIPS 46-3 gets approved.
This isn't restricted to the government itself either: quite a few
other industries mandate use of particular government-approved
standards as well. Let's face it: for quite a few people, poor
security and a strong excuse is a MUCH safer position than having to
take responsibility for what's _probably_ stronger security.
> One assumes that, even in the absence of "multiple AES winners", there
> will be new cipher designs and continued cryptographic research in the
> forthcoming years just as there has been in the past.
Of course there will. Without government sanction, quite a few people
will either not be able to use them at all, or else will only be
allowed to use them by going to considerable extra work to justify a
departure from the standard.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: AES & satellite example
Date: Fri, 14 Jan 2000 12:31:40 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> As you say, whether FPGA + configuration library or ASIC with all
> algorithms is larger/cheaper/less power depends heavily on the number of
> algorithms you want to support. However, I have some doubts that the cross
> over point is in the 100s of algorithms.
You're right -- that's probably an exaggeration. A dozen or so would
probably be a more accurate guess at the cross-over point. In any
case, I can see little likelihood of a real use for more than a half
dozen algorithms, and I really doubt that the factor would be that
low.
> A single AES algorithm can be
> fairly large in an ASIC, especially if you have to do pipelining etc. for
> speed reasons. Note that many modern block ciphers require FAR more area
> than DES. At the same time, the AES algorithms can be implemented pretty
> comfortably on current FPGAs at very high speeds (Gbit/sec range).
Absolutely. Keep in mind, however, that one of the things that
contributes to large area of many of the AES finalists is going to be
RAM cells, and these are easy to share between all the algorithms.
IOW, if you decided to implement all five finalists (for example) it's
nearly certain that any reasonable design would consume a GREAT deal
less than 5 times the die area of a single algorithm.
> However, note that traditional hardware does in no case allow algorithm
> upload which is an attractive option for various reasons.
>
> I believe it is important to not forget about HW implementation (ASIC or
> FPGA) since many modern applications have channel speeds that can not be
> supported by SW implementations.
>
> Don't get me wrong: I principally agree that traditional ASICs can do a
> better job in many cases, but one has to look carefully at the actual
> system.
Oh, there's no real doubt about that. I think, however, that most of
the arguments that have been advanced against use of multiple
algorithms apply to an even greater degree against use of re-
programmable hardware. That doesn't mean an FPGA-based solution can't
ever be useful, but it does indicate that if/when it is, it will
likely be for different reasons that those cited so far.
Just for one example, if you were contemplating a design knowing that
only (for example) 20 units would ever be of use, FPGAs would
typically have a much lower overall cost than ASICs despite FPGAs
having a substantially higher unit cost.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: New Crypto Regulations
Date: Fri, 14 Jan 2000 12:35:31 -0700
Mike Rosing wrote:
> Here's the part I like:
>
> 3. Also in �740.13, to, in part, take into account the "open source"
> approach to software development, unrestricted encryption
> source code not subject to an express agreement for the payment of
> a licensing fee or royalty for commercial production or sale of
> any product developed using the source code can, without review,
> be released from "EI" controls and exported and reexported
> under License Exception TSU. .... To qualify, exporters must
> notify BXA of the Internet location (e.g., URL or Internet address) or
> provide a copy of the source code by the time of export. These
> notifications are only required for the initial export; there are no
> notification requirements for end-users subsequently using the
> source code. Notification can be made by e-mail to
> [EMAIL PROTECTED]
>
> They've given up the Bernstien case. If it's freeware source, it's
> freely distributable. That puts me in the clear!
I like that part too. As soon as I clear it with SourceForge and with
[EMAIL PROTECTED], I'm going to put some software of mine up for free
download/revision/etc.
However, there is still a confusing morass for those of us who sell mass
market software. For instance, they classify "banking" software, "e-commerce"
software, and "retail" software under separate categories, each with their own
separate requirements. Unfortunately, if we make our software compliant with
the "retail" software requirements, then it doesn't meet the needs of our
customers who wish to use the software in e-commerce or banking situations --
and we don't have the manpower or resources to maintain four different
versions of our software (three for export, and one domestic).
Maybe I'm just reading it wrong, though. The whole regulation is utterly
confusing, with no clear guidance as to what bit-length keys for retail
products could be, for example (is it 56? Or 64? Or any length?). When I was
asked about the regulations by our marketing manager, I just shook my head and
said it was something our lawyer would have to dig through (for many $$$, sigh
-- I'd prefer to have that money in my own pocket as a bonus!).
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Derek Bell <[EMAIL PROTECTED]>
Subject: Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?)
Date: 14 Jan 2000 19:38:11 -0000
John Myre <[EMAIL PROTECTED]> wrote:
: It isn't quite the same, but I certainly remember my chagrin when I
: figured out that "misled" is not the past tense of "misle" (with a
: long "i" and "s" as "z").
That reminds me of the poem in one of Douglas Hofstadters' books that
began:
What *is* the past tense of beware?
Do we say he bewore being caught?
Unfortunately, I can't remember the author.
: Do you remember the joke about how to pronounce "ghoti"?
Yep, George Bernard Shaw came up with it.
Derek
--
Derek Bell [EMAIL PROTECTED] | Socrates would have loved
WWW: http://www.maths.tcd.ie/~dbell/index.html| usenet.
PGP: http://www.maths.tcd.ie/~dbell/key.asc | - [EMAIL PROTECTED]
------------------------------
** 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
******************************
