Cryptography-Digest Digest #579, Volume #11 Thu, 20 Apr 00 06:13:00 EDT
Contents:
Re: Regulation of Investigatory Powers Bill (Robert Stonehouse)
Text File Encryption ([EMAIL PROTECTED])
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: password generator (John Myre)
Re: Text File Encryption (Andru Luvisi)
A future tenant of the dog house?? (James Muir)
Montgomery squaring (JCA)
Re: OAP-L3: Answer me these? (James Felling)
Re: BS on AES3 (from the latest Cryptogram) (Bruce Schneier)
What is Bluestem? (Charles Blair)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Robert Stonehouse)
Crossposted-To: alt.security.scramdisk,alt.computer.security
Subject: Re: Regulation of Investigatory Powers Bill
Date: Wed, 19 Apr 2000 14:33:27 GMT
"Scotty" <[EMAIL PROTECTED]> wrote:
>Robert Stonehouse wrote in message
><[EMAIL PROTECTED]>...
>>"Scotty" <[EMAIL PROTECTED]> wrote:
>>...
>>>Now compare that with the new clause in the RIP bill:
>>>
>>>"(2) If any person with the appropriate permission under Schedule 1
>>>believes, on reasonable grounds-
>>> (a) that a key to the protected information is in the possession of any
>>>person,
>>><snip>
>>>the person with that permission may, by notice to the person whom he
>>>believes to have possession of the key, require the disclosure of the
>key."
>>>
>>>and
>>>
>>>"49. - (1) A person is guilty of an offence if-
>>> (a) he fails to comply, in accordance with any section 46 notice, with
>any
>>>requirement of that notice to disclose a key to protected information; and
>>> (b) he is a person who has or has had possession of the key. "
>>
>>The effect of this is to impose a duty on any person who uses
>>encryption to keep a complete record of the keys he (or she) has
>>used. Similarly, any person who enjoys the privileges of limited
>>liability has to keep statutory records - register of members, books
>>of account.
>
>There is no statutory duty to keep any such records. If it was a requirement
>it would be written into the act, you are reading something into the act
>which isn't there. Keeping a written record of passwords is hardly conducive
>to good security, and escrow was specifically dropped from the early version
>of the e-commerce bill.
That is why I said 'the effect of this ...'. The Bill is imposing
this duty, in the form of a duty to be able to produce the key. This
follows in a simple and obvious way from the wording. Exactly how
you do it is up to you, but I don't see how it can be done without
keeping records.
The desirability of recording keys, from a security point of view,
is one of those 'other problems' I referred to. This is a real
problem, not easy to solve. 'Guilty until proved innocent' is a
pseudo-problem and time spent on it is wasted.
>
>>>Clause 2 now requires the prosecution to show 'reasonable grounds' to
>>>believe that you have a key. Reasonable grounds is in effect 'balance of
>>>probabilities'. Notice the argument is not over whether you have a key or
>>>not, but whether the police etc can *reasonably believe* that you do. Once
>>>this hurdle is passed everything is automatic as before. Failure to comply
>>>is still an offence and forgetting your key wont get you off, you have to
>>>prove you've forgotten it.
>>
>>It won't get you off even then. You have a duty to know the key. If
>>you prove you've forgotten it, you prove yourself guilty.
>
>With respect that's nonsense, if you can satisfy a judge and jury that you
>have forgotten the key you can't be found guilty.
Yes you can. The law (proposed) is that you must be able to produce
the key. You must maintain the capability to do that. If you fail,
you are in breach of the (proposed) law, much like a company
secretary who forgets who the shareholders are.
A company secretary has to keep records in a pretty closely defined
form and that is different from the proposed law. But in both cases
not knowing what you should know can be an offence.
...
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Text File Encryption
Date: Wed, 19 Apr 2000 14:46:16 GMT
Folks,
Is there an encryption application available which can be referenced
within code or executed via shell commands to decrypt a text file for
import into Access? Maybe a set of dll's or methodology which would
work?
TIA
Dave
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Wed, 19 Apr 2000 08:27:57 -0700
James Felling wrote:
>
> Anthony Stephen Szopa wrote:
>
> > James Felling wrote:
> > >
> > > >
> > >
> > > <Big snip>
> > >
> > > >
> > > > You want me to believe that there is a useful attack of the random digit
> > > > generator?
> > > >
> > > > You want to talk reality? Then consider this:
> > > >
> > > > If there is why do I have to give anyone the raw random digit
> > > > output directly from the random digit generator before they
> > > > can make such an attack?
> > >
> > > You don't. However, most peole are willing to spend a few days worth of computer
> > > time to proove a point, more than that and its not worth the effort. Since the
> > > dificulty of attack increases greatly without such, it becomes impractical and
> > > expensive for anyone to do so merely to allow you to see the light. Your cypher
> > > on the whole is (given the attacks against it) probably as strong as the AES
> > > candidates( but not significantly stronger). What we are discussing is
>equivalent
> > > to saying that there is a weakness in the round key generator for such a cypher.
> > > This will NOT compromise a cypher(directly), but it provides a point of attack,
> > > and can remove an algorithim from contention for serious practical usage.
> > >
> > > >
> > > >
> > > > Keep in mind that there is no way this data is going to be
> > > > available in a real life situation.
> > >
> > > Agreed to a point. It certianly is not directly exposed, but the weaknesses it
> > > posesses will result in artifacts in the stream generated that CAN be used to
>make
> > > an (admitedly academic -- it needs truly ridiculous quantities of stream data)
> > > attack against it.
> > >
> > > >
> > > >
> > > > Your questions / points of contention indicate clearly that you
> > > > do not have the software, you have not thoroughly read the Help
> > > > Files, you have not run the examples, you have not done the
> > > > tutorials.
> > >
> > > Really now? I have read your tutorials, examined the software, read what
> > > helpfiles exist, and messed with it enough to familiarize my self with its
> > > function as far as that goes.
> > >
> > > >
> > > >
> > > > You have refused to do your homework.
> > >
> > > You sir, have refused to answer my direct questions, you have accused me of
> > > neglecting to familiarize myself with the topic, and have been generally
> > > uncooperative in nearly all respects. If you are atempting to educate people
> > > about your software, you are sadly deficient in teaching skills.
> > >
> > > >
> > > >
> > > > I do not have any more time to spend with such an unmotivated
> > > > pupil.
> > >
> > > If my simple questions were answered in a satisfactory manner, I would cease to
>be
> > > a drain upon your time, and may even be an advocate. Is it possible, sir, that
> > > you cannot do so?
> > > Here they are again:
> > >
> > > Your RNG is flawed. This does not sink your algorithim, however, it does raise
> > > issues. Can you give a good expalnation as to why the flaws in the RNG do NOT
> > > result in an artifacts in the resulting stream? Or if they do can you explain why
> > > such artifacts do not comprise a security risk? Do you understand the nature of
> > > the flaw in your RNG? Do you know how to fix it?
> > >
> > > I accept that a direct attack versus the RNG while not impossible is going to be
> > > quite challenging. I will accept even for the sake of argument that you are as
> > > secure as the AES.
> > >
> > > your program needs several MINUTES to setup before encryption, while equivalently
> > > secure algorithims take at worst seconds to setup on an equivalent machine -- Why
> > > should I use it? What benefit does it offer that justifies the time investment?
> > >
> > > your program generates stream data much slower than, oh say, RC4 for example, why
> > > should I use it in prefrence to other stream algorithims?
> > >
> > > PGP has a much cleaner and easier to use user interface and offers equivalent
> > > security and faster encryption, why should I use your program?
> > >
> > > Even ScottXu has had more thourough examination, and has actually had some
> > > sophisticated analisys performed upon it, has your program? If so why does the
>RNG
> > > have the weakness that it does( it is a fairly simple one that can be easily
> > > avoided by trivial modification)?
> >
> > "time to proove a point"? Prove what point? That there is a flaw
> > in the random digit generator? No flaw exists except in your own
> > imagination. The random digit generator serves a purpose. To
> > this end it has no flaw. You choose to perceive a flaw. But this
> > is because you do not comprehend the purpose of the random digit
> > generator.
>
> Your RNG has a severe flaw in that it leaks key data. Yes, your later steps in which
>the
> raw RNG data is mangled into the actual code stream will to some degree mask this,
>and
> make attack more difficult. I accept that your RNG's flaw is thereby masked.
>However,
> this still leaves your encryption weaker than it is claimed to be. Correct the flaw,
> and your algorihim's strength will increase greatly.Why not do so?
>
> >
> >
> > "without such, it becomes impractical and expensive" (To put it
> > mildly.) When the software is used according to recommended use
> > it becomes practicably impossible, is more like it.
>
> It become very dificult to nearly impossible. If I had serious money at stake then
>the
> cost in time and resources to break your code might be worth it. But I don't, and so
>I
> cannot break your code. OTOH, if I were to have something very valuable that I
>wished
> to protect your code would likely be insulficient as as with such resources a break
>may
> be achieved.
>
> >
> >
> > "This will NOT compromise a cypher(directly), but it provides a
> > point of attack" Oh? Regarding OAP-L3 this claim is completely
> > irrelevant. Again, when used according to recommended use,
> > specifically, when the original random number stream output
> > (0 - 255) is completely and irretrievably lost with subsequent
> > processing, there will be no attacks according to your pointless
> > generalization.
>
> Really? irretrivably lost, huh? I will admit the truncation adds some security, but
>the
> data leaked by the RNG is not "irretrivably gone". Given a byte B is generated as
> output after truncation then we know the following. Treat the digits as seperate
> substreams -- that is how they are generated isn't it? Then given an output value
> B=100*B1+10*B2+B3 we can conclude the following.
>
> then the actual output of the 3 streams call it S=100*S1 +10*S2+ S3 was either B,
>B+256,
> or B+512. this allows us to conclude the following
> S3= either B3, (B3 -6) Mod 10, or (B3-2) mod 10
> S2= either B2, (B2-5) mod 10, or (B2-1) mod 10
> and S1 = either B1, (B1-2) mod 10, or (B1-5) mod 10. in addition 0<=S1<=7 so we can
> always eliminate at least 1 possible form the valuse of S1, in addition since S1
> determines which values get droped any ability we get to guess at S1 also means that
>we
> get closer to guessing where the droped values fall.
>
> True, as I said with all the fiddling you do we cannot exactly predict what the input
> streams are, but we can make predictive guesses, and thus the RNG is somewhat
>exposed.
>
> >
> >
> > "will result in artifacts in the stream generated" Totally
> > ridiculous. I will give you any amount of the final OTP data
> > you think you will need and you will never ever ever deduce the
> > random digit output from the random digit generator or the original
> > MixFiles used as the random digit generator input. You cannot
> > even justify your statement other than to say that you read it
> > somewhere.
>
> Excuse me. If you are going to respond to selected quotes please do not put words
>in my
> mouth. Where in my positng did I say anything about "having read it somewhere"? You
>are
> lying here. This is a DELIBERATE UNTRUTH. Given your output stream, it is possible
>to
> build a statistical model of your Mix Files, and from that statistical model you can
>in
> turn build a model of your keying data. Yes this requires alot of data, time and
> effort, but it can be done. You have shown me nothing in your process that will
>result
> in the RNG artifacts remaining hidden or that compensates for such in even a simple
> manner, other than the truncation, which merely complicates attack, and most
>definitely
> does not render such impossible. You are correct in saying given that data I will not
> generates such -- I do not have that kind of spare time available. If I felt that
>the
> stakes were high enough to justify such an expenditure of time and effort however,
>your
> code would be comprimised.
>
> >
> >
> > You know I am correct if you have read and understand the OAP-L3
> > software, specifically regarding the processing done to the RandOut
> > files and the final generation of the OTP files.
>
> I regret to say that I spent several hours going over that morras of print data you
> claim sulfices as documentation
>
> >
> >
> > "messed with it enough" Clearly not enough.
>
> Perhaps, perhaps not.
>
> >
> >
> > Can any one of you imagine when you were in the university, a
> > student telling his professor that he "messed around" with his
> > homework "enough"? "Yeah, teach. I messed around with your
> > homework enough..."
> >
>
> Yep, and here are the solutions to the exercises that I could solve. You know as
>well
> as I that in higher level courses, you are expected to not always be able to fully
> answer all questions on the homework. What you are doing here is attacking my
>choice of
> words, not responding to my questions. I am still waiting for your reply to any
>serious
> questions that I have presented.
>
> >
> > Then how do you explain your obvious lack of understanding about
> > OAP-L3? What kind of credibility do you bring to this discussion
> > when you admittedly (implicitly) have not done your homework
> > adequately?
>
> By the logic in that paragraph, and the fact that you have not responded to the
> questions that I have asked you have (implicitly) admitted that you are unable to
> respond to my questions in a satisfactory manner, and thereby admited that your code
>is
> inadequate to the job. Come on, be reasonable now. We both know that resorting to
>such
> debator's tricks serves only to obscure the topic at hand. Stop attacking my
>language,
> and answer my questions. Are they so difficult to respond to?
>
> >
> >
> > "Your RNG is flawed" I thought we were talking about the random
> > digit generator.
>
> We were. Sorry that my terminology is confusing. I consider the RNG to be the
>portion
> of the code used to generate the Mix files. Any time that I have refered to such
>that
> is what I have meant. (What you have meant I can only guess, but I have been assuming
> that we were talking about the same thing.) Your documentation regretably lacks
>useful
> labels for the various subsections of the code.
>
> > If you insist: the random number generator
> > outputs the random numbers found in the OTPs. Are you now talking
> > about the OTP random numbers or are you fantasizing about some other
> > numbers. You really must decide what you want to discuss. You
> > are ridiculous if you think there is a flaw in the OTP random
> > numbers. You still have given us no proof of this: not even a
> > plausible glimmer.
>
> The flaw in the generated output stream which you persist in calling "OTP random
> numbers" exists. Follow the data back through the cycle, you can and will see its
> origins.
>
> >
> >
> > Your insistence borders on the insane, and we can be sure of this.
>
> Can we now? I have asked you a set of simple questions that you have yet to respond
> to. All I want is an answer to my questions. If that makes me insane then so be it,
>but
> I think you cannot reply to my questions in a way that makes you look good, so you
> refuse to do so. Here they are again:
>
> Your RNG is flawed. This does not sink your algorithim, however, it does raise
> issues. Can you give a good expalnation as to why the flaws in the RNG do NOT
> result in an artifacts in the resulting stream? Or if they do can you explain why
> such artifacts do not comprise a security risk? Do you understand the nature of
> the flaw in your RNG? Do you know how to fix it?
>
> I accept that a direct attack versus the RNG while not impossible is going to be
> quite challenging. I will accept even for the sake of argument that you are as
> secure as the AES.
>
> your program needs several MINUTES to setup before encryption, while equivalently
> secure algorithims take at worst seconds to setup on an equivalent machine -- Why
> should I use it? What benefit does it offer that justifies the time investment?
>
> your program generates stream data much slower than, oh say, RC4 for example, why
> should I use it in prefrence to other stream algorithims?
>
> PGP has a much cleaner and easier to use user interface and offers equivalent
> security and faster encryption, why should I use your program?
>
> Even ScottXu has had more thourough examination, and has actually had some
> sophisticated analisys performed upon it, has your program? If so why does the RNG
> have the weakness that it does( it is a fairly simple one that can be easily
> avoided by trivial modification)?
>
> >
> > The only flaw is in your illogical thoughtless position.
>
> Name calling -- always the sign of a man who is in possession of all the facts, and
>with
> superior logic on his side.
>
> > There is
> > absolutely no flaw in the theory, processes, and procedures of
> > OAP-L3.
>
> Bullshit. The mix file generation has huge flaws in it.
>
> > Show us how you intend to break the OTPs.
>
> Analisys of stream data will yeild good models of the mix files, and from those the
>10
> digit user permutation may be attacked directly, and the other permutes, etc. will
> fallout thereafter.
>
> >
> >
> > Consider the probabilities inherent in the recommended use of
> > OAP-L3 software. Then give up.
>
> Why shoud I quake in my boots in fear of a broken piece of software?
>
> >
>
> >
>
> >
>
> >
> >
> > FACE IT: YOU HAVE BEEN BEATEN BY AN ALGORITHM!
> >
>
> Yep, I have --hundreds of times. There are many algo's that I cannot hope to attack.
> OAP-L3 is NOT one of them however.
>
> >
> > And consider this: you and your phony cronies in this news group
> > are just about out of time.
>
> I have no "cronies" as you claim. I am merely one man voicing one man's opinions. I
>am
> NOT selling anything -- you are, and I'm growing increasingly less likely to buy your
> story.
>
> >
> >
> > Version 4.3 is about to be released. And version 5.0 has been
> > spec'ed out.
>
> >
> >
> > In fact, I have had a working prototype of version 5.0 running for,
> > let me look... over three months now.
> >
> > Version 5.0 will blow everyone away with its variability and power.
> >
> > Isn't this really why you and your phony cronies in this news group
> > are so unnaturally concerned about OAP-L3?
> >
>
> All I asked were some simple questions, and you accuse me of being part of some sort
>of
> "crypto cabal"? Get a clue man, all I want are answers. Give them to me and I will
> either go away, or I will become an ally, is that so hard to understand?
>
> >
> > I think so.
> >
> > You asked me to write a paper. Guess what? There are probably
> > a dozen papers already written on OAP-L3. One is at NSA, another
> > at MI 6, one is in Moscow, another in Tokyo, ... But don't hold
> > your breath waiting for one of these to be published.
>
> You are delusional. What you have done is neither revolutionary nor terribly
>original,
> I strongly doubt the existence of any real analisys of your algoritim -- even by you.
>
> >
> >
> > Perhaps someone else will get around to publishing one. They
> > would certainly get much attention from the experts in the field.
>
> >
> > It would be great publicity for someone. But I recommend they wait
> > until Version 5.0 is released.
> >
> > Here is a suggestion: why don't you write one and highlight your
> > supposed flaws in OAP-L3. Now that would take some guts on your
> > part. Are you not sure enough of your position? I don't think
> > you are. The experts will slaughter you (and your phony cronies as
> > well.) Be sure of it.
>
> Perhaps if I get a few spare hours in the next few days I will.
You don't know what you are talking about.
You cannot even describe the process of how the final OTPs are
created from start to finish.
OAP-L3 has no bias because I say so, AND because I have provided
a solid and sound argument why, in the Theory and Processes Help
Files available at http://www.ciphile.com
There is no more bias in the OTPs from OAP-L3 than there are from
picking true random numbers since the recommended use requires
that the user input true random numbers when choosing what
processes to run and what input parameters to use in each process.
True random numbers in: true random numbers out. This should be
a no brainer.
I have supported everything I have said here in this news group
and in the Help Files available at my web site. None of you have
supported anything you have said.
Mr. Huuskonen claims that the current implementation of the random
digit generator is not cryptologically sound. Have any of you
asked Mr. Huuskonen if the output from the random digit generator
is used to encrypt messages? No, none of you have. This is
because none of you knows what they are talking about.
The output from the random digit generator is not used to encrypt
messages in OAP-L3. And there is no way Mr. Huuskonen or anyone
else is going to get the extensive secret data required to attempt
an analysis as he has proposed. If one could, they would also have
access to the key and or the OTPs themselves, and would not waste
the time attempting such an analysis. So the idea that the random
digit generator is not cryptologically sound is a statement with no
implications to the security of OAP-L3 software as currently
implemented.
I guess it is like they say in Orange County, California:
"If you don't get it: you don't get it."
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: password generator
Date: Wed, 19 Apr 2000 09:40:54 -0600
Tom St Denis wrote:
>
> Got bored this afternoon so I wrote a password generator using the
> windows timer rng idea.
>
> You can get the source at
>
> http://24.42.86.123/files/passwd.c
Why do you generate 8 bits per byte (in trng_byte), and
then throw two of them away (via & 63)?
John M.
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: Text File Encryption
Date: 19 Apr 2000 08:41:33 -0700
[EMAIL PROTECTED] writes:
> Folks,
>
> Is there an encryption application available which can be referenced
> within code or executed via shell commands to decrypt a text file for
> import into Access? Maybe a set of dll's or methodology which would
> work?
The answer is probably yes, but it would be easier to be sure if you
were to tell us more of the background.
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
From: James Muir <[EMAIL PROTECTED]>
Subject: A future tenant of the dog house??
Date: Wed, 19 Apr 2000 15:42:15 GMT
I stumbled across "Polymorphic Cryptography" today:
http://www.identification.de/crypto/index.html
http://www.identification.de/crypto/descript.html
Here's a quote from the splash page:
"Common ciphers like DES and RSA are extremely slow when calculating on
long keys. Polymorphic Cryptography is 10^1500 times as secure at
comparable encryption speed!"
Here's another one from the description page:
"The widespread DES algorithm has long been supposed to be unbreakable.
In January 1999 a test performed by RSA Data Security, Inc. (San Mateo,
Calif., USA) proved that it takes less than 22.25 hours to crack the 56
bit algorithm by brute-force (by trying all 256 possibilities)."
Ouch... I hope they just forgot the "^" character. Is anyone
suspicious?? I wonder if you get a free bottle of snake oil with every
order?
-James
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: Montgomery squaring
Date: Wed, 19 Apr 2000 08:35:12 -0700
I am looking for a reference describing Dusse and Kaliski's
approach to Montgomery squaring. Can anybody provide any
pointers?
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Wed, 19 Apr 2000 11:01:32 -0500
Mr. Szopa, I seem to recall asking you a few simple questions in re: your program
that you still haven't answered ( either through personal e-mail or newsgroup
discussion. Since they have now rolled off the servers, and in order to give you
a fair oportunity to answer them I feel compeled to repost them.
1)Your RNG is flawed. This does not sink your algorithim, however, it does raise
issues. a) Can you give a good expalnation as to why the flaws in the RNG do NOT
result in an artifacts in the resulting stream? b) Or if they do can you explain
why
such artifacts do not comprise a security risk? c) Do you understand the nature of
the flaw in your RNG? d) Do you know how to fix it?
I accept that a direct attack versus the RNG while not impossible is going to be
quite challenging. I will accept even for the sake of argument that you are as
secure as the AES, but in that case given that:
2) your program needs several MINUTES to setup before encryption, while
equivalently
secure algorithims take at worst seconds to setup on an equivalent machine --
a)Why
should I use it? b)What benefit does it offer that justifies the time investment?
3) your program generates stream data much slower than, oh say, RC4 for example,
why
should I use it in prefrence to other stream algorithims?
4) PGP has a much cleaner and easier to use user interface and offers equivalent
security and faster encryption, why should I use your program?
5) Even ScottXu has had more thourough examination, and has actually had some
sophisticated analisys performed upon it, a) has your program? b) If so why does
the RNG
have the weakness that it does( it is a fairly simple one that can be easily
avoided by trivial modification)?
Please reply to the NG at your earliest convenience.
Thanks
Jim
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: BS on AES3 (from the latest Cryptogram)
Date: Wed, 19 Apr 2000 16:21:12 GMT
On Tue, 18 Apr 2000 22:58:34 GMT, [EMAIL PROTECTED] (Lonie M.
Raky) wrote:
>Bruce Schneier is a regular on this newsgroup. I would think that if he
>wanted that posted here, he would have done it himself.
Indeed.
I don't mind, though.
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
------------------------------
Subject: What is Bluestem?
From: [EMAIL PROTECTED] (Charles Blair)
Date: Wed, 19 Apr 2000 16:24:07 GMT
I have been hearing about a tool called ``Bluestem'' for
signing documents. Is this an implementation of a public-
key system? If so, is it known which 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
******************************
