Cryptography-Digest Digest #598, Volume #13 Wed, 31 Jan 01 18:13:01 EST
Contents:
Re: fast signing (lcs Mixmaster Remailer)
Re: Most secure code for US Citizen. ("Kristopher Johnson")
Re: fast signing ("Joseph Ashwood")
Re: fast signing ("Joseph Ashwood")
Re: fast signing ("Joseph Ashwood")
Re: Did NSA change the ECDSA-standard (Roger Schlafly)
Re: Most secure code for US Citizen. ("Joseph Ashwood")
Re: Most secure code for US Citizen. (Bill Unruh)
Re: fast signing (DJohn37050)
Re: crypto algoritm or program ("Bteee")
Re: On combining permutations and substitutions in encryption (John Savard)
Re: Most secure code for US Citizen. (DJohn37050)
Re: MIKE - alternative to SPEKE and PAK (Philip MacKenzie)
Re: Algorithm M question (Terry Ritter)
Re: On combining permutations and substitutions in encryption ("Douglas A. Gwyn")
Re: Most secure code for US Citizen. ("Douglas A. Gwyn")
Scramdisk (Fred Louder)
Re: Most secure code for US Citizen. (Splaat23)
Re: fast signing (Paul Rubin)
----------------------------------------------------------------------------
Date: 31 Jan 2001 19:20:30 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: fast signing
Joseph Ashwood writes:
> I need signing to by excessively fast. I've got an application where one
> person here expects in the 10,000 signature/second range (I doubt he'll get
> that speed out of his code, but that's another issue), on a single-processor
> x86 P4 1.5 GHz, gobs of RAM, etc.
Could you try batching signatures? The idea would be to take say 10
messages and hash them together in a two-level structure:
H = Hash( Hash(M1), Hash(M2), Hash(M3), ..., Hash(M10) )
and then feed H into the DSA algorithm. Save all ten individual hashes
Hash(Mn) along with the DSA output. This allows message verification
using just the contents of the individual message M_i, but you only have
to do the PK algorithm 1/10 as often.
The downside is that you can't output the sig for M1 until you have
collected all the messages up to M10, but maybe this delay is OK as
long as you are keeping up with the messages in general.
------------------------------
From: "Kristopher Johnson" <[EMAIL PROTECTED]>
Subject: Re: Most secure code for US Citizen.
Date: Wed, 31 Jan 2001 19:31:37 GMT
You're about to get jumped upon by the know-it-alls in the group. I'll try
to give you some friendly advice:
You want the "most secure encryption code". For what purpose?
What kinds of data are you sending, over what kinds of links? Who is
sending the data, and who is receiving the data? What sorts of attacks are
possible, and what sorts are likely?
How valuable is the data? Does the value decrease over time?
Finally, security is more than just using good code. The procedures you
follow and the mechanisms you have for detecting and reacting to attacks are
at least as important as the algorithm and implementation you use.
-- Kris
"Michael Robbins" <[EMAIL PROTECTED]> wrote in message
news:959lkv$pd2$[EMAIL PROTECTED]...
> Pardon my naivate, I guess you guys will give me the straight dope.
>
> Where can I get the most secure encryption code (C/C++).
>
> I am a US Citizen.
>
> --
> Michael Robbins, CFA
> Director, Debt Capital Markets
> Canadian Imperial Bank of Commerce, World Markets
> New York
>
>
> Sent via Deja.com
> http://www.deja.com/
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: Wed, 31 Jan 2001 12:00:07 -0800
I'll look into it. 8x may be enough. Any suggestions on free
implementations?
Joe
"DJohn37050" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> ECDSA signing should be faster than DSA signing. For 1,000 bit keys it is
> about 8 times faster than DSA, if you just look at the bit calculations
(back
> of envelope) for bigger keys it would be a larger ratio, for smaller keys
it
> would be smaller but still better. See my ECDSA paper at www.certicom.com
> white pages.
> Don Johnson
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: Wed, 31 Jan 2001 12:00:26 -0800
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Just program a second module to be able to verify the MAC's but not
> sign new ones.
Not gonna work. Then we depend on the security of the storage medium.
Obscurity of location, etc will not be enough. I've taken extra measures to
make it so that even given complete knowledge of the audit state you can't
write prior logs. If the MAC is used then it will be possible.
> Look, what's the purpose of the signatures on the logs? To safeguard
> against security breaches on the logging machine, right? Well, if the
> logging machine can be breached, what makes your boss think the signing
> machine can't also be breached?
And to safegaurd against an untrusted verifier from tampering, and
protecting an attacker from altering prior logs if they attach a debugger,
etc, etc, etc. There are a massive number of attacks that are being dealt
with here, even the construction of the input to hash function has been
designed for an extra alteration (an embedded hash chain)
> Whether you use public key or secret key signing algorithms, you
> should use secure hardware modules, not general purpose computers, to
> do the signing, if the signatures are expected to be important for
> something.
I agree, but that is extra expense that we can't make a profit from, that we
have to require our customers to pay for. Additionally where would I find a
module that could only be coerced into performing the MAC operation for my
program? I can manage the PKI operations because of the passphrase issue
(the verifier is untrusted). I actually tried to get a MAC version ok'd but
the trusted verifier was deemed innapropriate. I've gone through all these
and ended up at the DSA vs RSA decision, I went with DSA. Now I'm looking at
ECDSA versus DSA, we'll see where it ends up.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: Wed, 31 Jan 2001 12:00:41 -0800
I've thought of that, it weakens the argument provided by the signature to
basically apply to m*n entries, it would be cheaper, and just as secure to
up the distance between signatures to m*n. It's not an option I want to do.
So far I think the best idea was the ECDSA suggestion. I need to examine it
versus the trust model we need (but I suspect it'll be appropriate).
Joe
"lcs Mixmaster Remailer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Joseph Ashwood writes:
>
> > I need signing to by excessively fast. I've got an application where one
> > person here expects in the 10,000 signature/second range (I doubt he'll
get
> > that speed out of his code, but that's another issue), on a
single-processor
> > x86 P4 1.5 GHz, gobs of RAM, etc.
>
> Could you try batching signatures? The idea would be to take say 10
> messages and hash them together in a two-level structure:
>
> H = Hash( Hash(M1), Hash(M2), Hash(M3), ..., Hash(M10) )
>
> and then feed H into the DSA algorithm. Save all ten individual hashes
> Hash(Mn) along with the DSA output. This allows message verification
> using just the contents of the individual message M_i, but you only have
> to do the PK algorithm 1/10 as often.
>
> The downside is that you can't output the sig for M1 until you have
> collected all the messages up to M10, but maybe this delay is OK as
> long as you are keeping up with the messages in general.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Did NSA change the ECDSA-standard
Date: Wed, 31 Jan 2001 12:23:31 -0800
DJohn37050 wrote:
> I am the editor of X9.62 ECDSA and here is what I observed:
> 1) Just before ECDSA was being balloted, there were concerns that curves over
> 2**m, m composite might be weaker than over 2**p, p prime. As nothing was
> known, they were allowed, after a lot of discussion. Because of the
> compositeness, some argued that they were faster; Certicom argued that they
> were riskier, but lost that discussion as there was no proof.
> 2) Then NIST published their recommended curves, none of them were so-called
> composite binary curves. There were all over prime fields or "prime" binary
> fields. By agreement, NIST can use NSA for cryptographic consultation, as they
> did with AES also. ...
I guess the conspiracy theorists might conclude that those are the
curves that NSA can break.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Most secure code for US Citizen.
Date: Wed, 31 Jan 2001 12:22:20 -0800
Well your basic choices are:
Twofish
Serpent
Rijndael
3DES
RSA
Those should be a wide enough selection for most purposes. RSA is the
exception there because it is a public key algorithm, and it's key size and
block size scale to absurd sizes, depending on your view it may be the most
secure. 3DES has very known security, it's been studied for 2 decades, and
should remain secure for the forseeable future. Serpent, Twofish, and
Rijndael are 3 of the AES finalists, Rijndael was finally chosen, Serpent is
believed to be the most secure of them, followed by Twofish, and lastly
Rijndael. Considering the company last place still puts it's currently
believed security above 3DES.
Since you seem to be from bank without more knowledge I'd say 3DES is the
way to go. It's level of security is extremely well known, and the future
most likely holds that it will simply keep going. It's mature, very strong,
it's only downside is speed, of the four (Serpent, Twofish, Rijndael, 3DES)
it is by far the slowest. If speed is of absolutely no concern, 5DES, 7DES,
11DES, 13DES, 17DES, etc will all be harder to break than 3DES. But they get
slower, using single DES as a flat benchmark, 3DES is 1/3 the speed, 5DES
1/5, 7DES 1/7, 11DES 1/11, 13DES 1/13, 17DES 1/17. If you trust RSA
completely (which may be the case in your security model), and don't mind
the ever slower speed, using RSA with large keys may be the way to go.
Joe
"Michael Robbins" <[EMAIL PROTECTED]> wrote in message
news:959lkv$pd2$[EMAIL PROTECTED]...
> Pardon my naivate, I guess you guys will give me the straight dope.
>
> Where can I get the most secure encryption code (C/C++).
>
> I am a US Citizen.
>
> --
> Michael Robbins, CFA
> Director, Debt Capital Markets
> Canadian Imperial Bank of Commerce, World Markets
> New York
>
>
> Sent via Deja.com
> http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Most secure code for US Citizen.
Date: 31 Jan 2001 20:47:53 GMT
In <959lkv$pd2$[EMAIL PROTECTED]> Michael Robbins <[EMAIL PROTECTED]> writes:
>Pardon my naivate, I guess you guys will give me the straight dope.
>Where can I get the most secure encryption code (C/C++).
No such thing, Unless you want to use a one time pad. But that requires
and external source of random stuff, and requires you to securely
exchange it with your counterpart.
If you told us what you were doing we might be of more help. As it is
your request makes little sense.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 31 Jan 2001 21:03:53 GMT
Subject: Re: fast signing
There are some free implementations of ECDSA out there. Wei Dai and U.
Waterloo(?) I have heard about. Of course, if something goes wrong... And I
hear that Certicom's stuff is very fast (grin) and is priced reasonably.
Don Johnson
------------------------------
From: "Bteee" <[EMAIL PROTECTED]>
Subject: Re: crypto algoritm or program
Date: Wed, 31 Jan 2001 21:08:16 GMT
Ok maybe I was unclear, the game is not about crypto in any way (it's
diplomacy if you happends to know it)
When you communicate in this variant you can only send messages to a message
board (like a usenetgroup) now I want to send messages that only one player
can read. And let them send me message that I only can read.
Also it should be something that I understand and can use (ig generating a
lot of random and then use a hash function is a bit to complicate for me to
understand.....)
So goal is to send message to a message board that only the one who I want
to can read and for the others it's just trashtext......
"Mike Rosing" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> Bteee wrote:
> > The settings are as follow:
> > The goal is to communicate secret with other players.
> > Everyone can read all communication so you will need some kind of public
> > key cryptation. All communication are in plain text.
> > The secure level has not to be good at all (but of course it's better if
> > it's high). It should be easy to use.
> >
> > Do PGP solve this problem or do it makes files that are not "plain
text"?
> > Is there any other free program that solves it or is there a simple
> > algoritm that solve my problem (keep in mind that it's more important
that
> > it's easy to use then that it is secure it's just a game:)
>
> There are lots of routines you can use. Far simpler than PGP, you can
make
> everything automatic so the user just types in some random garbage every
> time to create a session key (using a hash function for example) or else
> each person can generate their own private/public key pair and send the
> public keys to all the other players when they login.
>
> Encrypting files for individual users is not the same as sending them
around.
> I'm not really clear on what you need to do. Do you just want to share
> files now and then, or do you want to "go private" and have communications
> be secret between all players? Or just 2 players while everyone else is
> talking in the clear? It's all possible, and there's lots of free code
> around to play with.
>
> Patience, persistence, truth,
> Dr. mike
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: On combining permutations and substitutions in encryption
Date: Wed, 31 Jan 2001 21:05:20 GMT
On Mon, 29 Jan 2001 23:29:56 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>I am unaware of any proofs in cryptography which would prevent one
>from achieving a complete information hiding in a combiner or a
>sequence or array of combiners.
>I am unaware of any proofs in cryptography which would prevent one
>from achieving a known extent of information hiding, so that the
>combiner or RNG could be re-keyed before sufficient information was
>available for solution.
>Claiming that an RNG cipher simply cannot ultimately be secure as a
>fact is just unscientific.
With your last point, I completely agree, since it makes as much sense
to say that a block cipher cannot ultimately be secure. Like a block
cipher, a PRNG can have any desired degree of complexity.
There is a tendency to think of 'linear congruential' when one hears
PRNG, and those are considered to be poor bases for secure ciphers,
even with such a technique as "Algorithm M". I've pointed out my
opinion on this: that the weakness of the MacLaren-Marsaglia algorithm
in this case is primarily due to retaining the tell-tale LSBs of the
generated numbers.
Achieving complete information hiding, or a definite extent thereof,
by which you mean, I presume, that a cipher can be proven to be
'secure' under circumstances where it _would_ succumb to a brute-force
attack, were one possible, requires provable work-factor security.
To my knowledge, this has never been proven for any cipher. Some
ciphers related to public-key cryptography have been proven to be as
hard to break as it is hard to solve certain mathematical problems,
like factoring; but no one has come up with a proof that factoring
really is hard.
Thus, the lack of 'provably secure' ciphers in the sense apparently
discussed here does not appear to be because we need better ciphers.
The problem appears to be in the available mathematical tools with
which we construct proofs. Of course, absent proof in the mathematical
sense, combiners that appear to hide information better are still of
value.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 31 Jan 2001 21:37:44 GMT
Subject: Re: Most secure code for US Citizen.
For symmetric key, the strongest would be AES with 256 bit key.
For asymmetric key, the strongest for a reasonable sized key would be ECC, see
the NIST recommended curves that are appropriate to use with AES-256. They are
a little over double the symmetric key size.
For a hash, it would be SHA-512.
This all assumes you believe NIST in its statements about what is appropriate
to protect federal info assets that are not classified.
Don Johnson
------------------------------
From: Philip MacKenzie <[EMAIL PROTECTED]>
Subject: Re: MIKE - alternative to SPEKE and PAK
Date: Wed, 31 Jan 2001 17:18:03 -0500
Michael Scott wrote:
>
> Some months ago I mentioned an idea I had concerning a new algorithm for a
> low-entropy password-authenticated key-exchange, along the lines of SPEKE,
> PAK and SRP. Tom Wu was kind enough to make a few comments.
>
> I have since written up the idea in more detail - it may be found at
> http://www.compapp.dcu.ie/CA_Working_Papers/wp00.html#1300
>
> I have three questions
>
> 1. Has it been thought of before?
It's hard to say if anyone has thought of it exactly. I certainly
have thought of a gazillion (that's a technical term) protocols
that were similar to it. The problem that I had was that
I couldn't prove any of them secure, even in the random oracle model.
I don't think anyone has published the MIKE protocol, and
so it's certainly a reasonable protocol to propose and analyze.
> 2. Are there any security problems with it that I haven't seen?
Well, one obvious problem is that you have to test X and Y to see
if they are equal to zero "mod p" (not just if they are equal to zero),
or first check they lie in Z_p, or something like that.
Another thing is that I don't think there is any reason to have k mod q
in the
exponent for calculating Z, but that is not a security problem.
In general, I am leery of protocols with no proofs of security,
but if you fix the problem above, I don't see any other attacks right
now.
One potential avenue of attack (that you mention also)
may be in regards to "cooking the parameters".
To avoid that, I would use p in the hash function that generates the
parameters,
something like g=h(t,p)^((p-1)/q), r=h(t+1,p)^((p-1)/q).
> 3. Are there any patents that apply?
The patent submitted for PAK may actually cover MIKE also. Just
something you
should be aware of.
>
> It is not my intention to patent it - but I shouldn't give away what isn't
> mine.
>
> The method is rather like PAK. The main novel idea is the use of two
> independent group generators. Its main advantage is that it works well in
> any type of group (e.g. Elliptic Curves - unlike SRP), also it avoids the
> sub-group membership problems that arise with SPEKE and PAK. In a common
> context it is maybe 5 times faster.
>
> Mike Scott
Just to clarify some points about PAK:
- in regards to Tom Wu's comment, PAK was consciously designed to use
the group
DH-2 (i.e., DSA-like parameters) instead of DH-1 (safe primes) for
efficiency
reasons. If you count up the number of modular multiplications, you can
see
that using DH-2 is faster.
- at the RSA conference this April I will present some more efficient
versions of PAK (sorry about the blatant plug :) ). To anticipate
questions,
let me just say that the variant that uses DH-2 is probably still not as
efficient as MIKE, but like PAK it has a proof of security in the random
oracle model. I'll post the paper on my web site as soon as I can.
-Phil
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Algorithm M question
Date: Wed, 31 Jan 2001 22:23:52 GMT
On Wed, 31 Jan 2001 06:59:46 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt Benjamin Goldberg
<[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>>
>> On Wed, 31 Jan 2001 00:41:30 GMT, in
>> <[EMAIL PROTECTED]>, in sci.crypt Benjamin Goldberg
>> <[EMAIL PROTECTED]> wrote:
>>
>> >[...]
>> >A fast, statistically good generator, like MT, might be
>> >usable for both PRNGs -- provided of course, that MT with scrambled
>> >order outputs is secure.
>>
>> http://www.io.com/~ritter/RES/COMBCORR.HTM#Retter84
>> http://www.io.com/~ritter/RES/COMBCORR.HTM#Retter85
>
>] "It is the purpose of this paper to show that the algorithm can be
>] attacked by searching for the key to one of its generators, while
>] ignoring the other." "Therefore, the amount of computation required to
>] break the combined keystream generator is only about twice what would
>] be required if one of the input generators had been used to generate
>] the keystream directly."
>
>Does this attack still work if both prngA and prngB use the same MT
>state?
I don't know; I'd have to study the article, and time is an issue.
>Also, it does not say anything about the amount of known
>keystream needed -- it only says "twice the amount of computation"
Normally, we are simply unable to put a fine enough point on exactly
how much information is exposed to care about a factor of two.
I don't know that there can be an easy fix. I think the mechanism is
fundamentally flawed with respect to exposing information we want it
to hide. And while we might use many other things to overcome that
flaw, if we do, why use that mechanism at all?
What advantage do you see the mechanism producing which is not better
produced in some other way? If the real issue is that it was in a
Knuth book, we just have to be aware that Knuth was not addressing
RNG's intended for use in secure stream ciphers.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: On combining permutations and substitutions in encryption
Date: Wed, 31 Jan 2001 22:00:54 GMT
Terry Ritter wrote:
> It should be obvious that XOR does not protect the confusion stream
> against exposure from known-plaintext. A keyed Latin square provides
> some protection, so it is also obvious that various amounts of such
> protection are possible. What we do not know -- because it is not
> addressed in the cryptographic literature -- is how far that process
> can go.
You may recall that I've pointed out several times in past
postings to this newsgroup that it is a mistake to define a
"stream cipher" as necessarily a KG-style (CT = PT xor RNG)
system. That style is vulnerable to certain simple attacks
that would not be so simple with a more general design.
The value of complicated "combiners" has long been known,
and such designs have been used in official cryptosystems.
Indeed, there *is* a substantial amount of literature on
this, but not much has been released to the general public.
Why there has been so little "outside" research in this
area is anybody's guess; mine is that attention was
diverted mainly into the new-fangled block ciphers.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Most secure code for US Citizen.
Date: Wed, 31 Jan 2001 21:39:42 GMT
The problem with the original request is that it is missing
information about threat environment and constraints, so it
is impossible to be sure of any criteria one might come up
with for the required level of "security", whatever that
might mean. Better would be a simple statement of the
actual requirements, as it is easier to be confident that a
design has met specified requirements than to come up with
a meaningful single measure of "security".
------------------------------
From: Fred Louder <[EMAIL PROTECTED]>
Subject: Scramdisk
Date: Wed, 31 Jan 2001 14:32:35 -0800
I discovered this program while searching for a way to encrypt data on a
disk drive
and have it transparent to the OS once it's presented with the correct
password.
However, after reading the manual, it's not clear to me if it will work
with read-only devices. I.e. CDROMS.
Is there a way to copy an encrypted Scramdisk file/partition onto a
CDROM, retain
the encryption, and enjoy the OS transparency when reading the CDROM?
If not, then is there a better program out there?
[EMAIL PROTECTED]
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: Most secure code for US Citizen.
Date: Wed, 31 Jan 2001 22:46:48 GMT
What are you talking about? He didn't ask for perfect security, just
the current best! I'll admit the context of this encryption is not
known, but you don't need to jump on the man...
- Andrew
In article <959tlp$hi9$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bill Unruh) wrote:
> In <959lkv$pd2$[EMAIL PROTECTED]> Michael Robbins
<[EMAIL PROTECTED]> writes:
>
> >Pardon my naivate, I guess you guys will give me the straight dope.
>
> >Where can I get the most secure encryption code (C/C++).
>
> No such thing, Unless you want to use a one time pad. But that
requires
> and external source of random stuff, and requires you to securely
> exchange it with your counterpart.
>
> If you told us what you were doing we might be of more help. As it is
> your request makes little sense.
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: 31 Jan 2001 15:03:05 -0800
"Joseph Ashwood" <[EMAIL PROTECTED]> writes:
> "Paul Rubin" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Just program a second module to be able to verify the MAC's but not
> > sign new ones.
> Not gonna work. Then we depend on the security of the storage medium.
That's not logical. Public key algorithms also depend on the security
of the storage medium, since the private key has to be stored somewhere.
> > Look, what's the purpose of the signatures on the logs? To safeguard
> > against security breaches on the logging machine, right? Well, if the
> > logging machine can be breached, what makes your boss think the signing
> > machine can't also be breached?
> And to safegaurd against an untrusted verifier from tampering, and
> protecting an attacker from altering prior logs if they attach a debugger,
> etc, etc, etc. There are a massive number of attacks that are being dealt
> with here, even the construction of the input to hash function has been
> designed for an extra alteration (an embedded hash chain)
Why do there have to be untrusted verifiers? I thought you said you
wanted these signatures to use in disputes. So verification only
needs to be done in that context, with your own techs and/or court
appointed observers present.
> > Whether you use public key or secret key signing algorithms, you
> > should use secure hardware modules, not general purpose computers, to
> > do the signing, if the signatures are expected to be important for
> > something.
> I agree, but that is extra expense that we can't make a profit from, that we
> have to require our customers to pay for. Additionally where would I find a
> module that could only be coerced into performing the MAC operation for my
> program? I can manage the PKI operations because of the passphrase issue
> (the verifier is untrusted). I actually tried to get a MAC version ok'd but
> the trusted verifier was deemed innapropriate. I've gone through all these
> and ended up at the DSA vs RSA decision, I went with DSA. Now I'm looking at
> ECDSA versus DSA, we'll see where it ends up.
I'm afraid your requirements still don't make any sense to me. My
cynical reading is that your boss is being both an amateur
cryptographer and an amateur lawyer, and is specifying technical
solutions that are both impractical to implement and won't satisfy the
intended purpose. Hint: all the cryptographic verification in the
world won't make a defendant cave in, if he's determined to fight.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
