Cryptography-Digest Digest #959, Volume #12 Thu, 19 Oct 00 13:13:01 EDT
Contents:
Re: "Software TEMPEST" explained (John Savard)
Re: A journal about crypto history (Derek Bell)
Re: Rijndael implementations (Robert Harley)
What is desCDMF? ("Yonghan, Yoon")
Re: Q: Message length in RSA (Bob Silverman)
Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom (Scott Craver)
Re: Q: Message length in RSA (=?iso-8859-1?Q?Tom=E1s?= Perlines Hormann)
Re: A journal about crypto history (Jim Reeds)
Re: How about the ERIKO-CHAN cipher? (Musashi)
Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom (Mathew Hendry)
Re: ECDSA (Robert Harley)
Re: Code Book Cipher Challenge Cracked (Mark VandeWettering)
Does RIPA require algorithm disclosure? (Richard Heathfield)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (nemo outis)
Re: What is desCDMF? (JCA)
DLL TripleDES and MD5 on Win32 ("Robert Hulme")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: "Software TEMPEST" explained
Date: Thu, 19 Oct 2000 13:09:05 GMT
On Wed, 18 Oct 2000 12:13:52 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>I've revised the page since this posting to point out that I'm
>discussing a very simplistic scheme, that falls far short of the
>sophistication of the measures discussed in the paper by Markus Kuhn
>and Ross Anderson.
Having added a second illustration of my simplistic scheme, I'm now
starting to wonder if it has been actually used, as I vaguely recall
seeing a computer display that looked sort of like it, on some TV
science-fiction or gadget spy show.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Derek Bell <[EMAIL PROTECTED]>
Subject: Re: A journal about crypto history
Date: 19 Oct 2000 14:12:38 +0100
Jim Reeds <[EMAIL PROTECTED]> wrote:
: Yes, a very interesting journal, but as its title indicates,
: not exclusively about the history of cryptography. In fact
: none of the articles I've seen have very much in the way of
: technical details of the sort often seen in the historical
: articles in Cryptologia.
It would give a good idea of historical contexts ciphers were
used in, though?
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]
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: Rijndael implementations
Date: 19 Oct 2000 15:09:33 +0200
"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
> > Welcome to the year 2000, Doug.
> Where literacy has reached such a nadir that people turn to
> Webster (a common-usage based dictionary) as authority for
> technical terminology?
It even has such technical terms as "fogey". Look it up.
Rob.
------------------------------
From: "Yonghan, Yoon" <[EMAIL PROTECTED]>
Subject: What is desCDMF?
Date: Thu, 19 Oct 2000 22:32:27 +0900
what is Commecial Data Mask Facility ?
How to implement 40-bits des key?
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Q: Message length in RSA
Date: Thu, 19 Oct 2000 13:51:58 GMT
In article <8smnia$plv$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> > I have a question regarding RSA signing and encrypting.
> > If I take a 160 bit SHA-1 hash and sign it with my private key (1024
> > bits), how long is the signature going to be?
> > And if I encrypt another message (some session key) which is e.g.
256
> > bits long? How long is this message going to be?
> > Is there a difference in the length of my private key and my public
> key?
A clarification:
There are two components to each of these keys. The public key
is (N,e), the private key is (N,d). [although N is redundant in the
second case]
One typically (and loosely) refers to the length of the public key as
the length of N while the length of the private key is generally
considered to be the length of d, even though both keys have more than
one component.
> > Everybody speeks about 1024 bit keys, but I read somewhere that both
> > lengths are different. Is this true?
>
> Arrg... so many misconceptions so little time.
>
> If your RSA modulus is 'n-bits' long then all of the RSA messages
> are 'n-bits' long regardless of how many bits you fill up. For
example
> decrypting (signing) the 160-bit hash can be considered as signing
160-
> bit hash + n-160 bits of padding. The result is always n-bits long.
>
> Your RSA private key is the decryption exponent and is the same size
as
> well. Your RSA public key will most likely consist of the encryption
> exponent (257 or 65537) and the modulus.
Tom does it again. Opens his mouth in ignorance and puts his foot in it.
When will he learn??? Tom, do us all a favor and SHUT UP until you learn
this material.
(1) Contrary to TOm's claim, all encrypted messages are NOT n bits long.
m^e mod N will be n-1 bits with probability approximately 1/2, will
be n-2 bits with probability 1/4, etc. Indeed, some standards allow
or require m^e mod N to be replaced with N - m^e mod N, whichever is
smaller, so in fact the final message or signature is ALWAYS 1 bit less
than the modulus (X9.31 for example)
(2) Similarly, the private exponent need not be exactly n bits long. If
e is the public exponent, the private key must be at least n - lg(e)
bits long, but can be shorter than n bits. [lg = log base 2] It need
not always be n bits.
--
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] (Scott Craver)
Crossposted-To: talk.politics.crypto
Subject: Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom
Date: 19 Oct 2000 14:33:00 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
>...such that the idea that someone had
>many encrypted messages and that they could not decrypt them so that
>they would like the original machine to do the trick.
>Not everyone has the know how or means to write the software and run
>it, etc. Secrecy might also have been a high priority.
Consider the risk and expense of having the machine stolen.
Would that not have been at least worth hiring someone
to write a computer program instead? And if secrecy were
a high priority, this high-profile theft would be a lot
worse than quietly enquiring about the machine's innards.
>Perhaps the person who might want this particular Enigma, again,
>might have many if not most or even all the unencrypted Enigma
>messages known and or unknown others. This person or persons might
>also have the keys. But the keys are useless without the actual
>machine with the proper rotors.
The keys are a big help! So are the unencrypted messages!
Unencrypted messages especially simplify brute-force
searching a great deal. And knowing 1/26th of the total
permutation at each step is also a big help.
>Perhaps the person commissioned to make the heist fulfilled his
>part of the bargain by supplying the rotors alone. But this
>"master" decided to get more money by ransoming the remaining
>machine.
I am reminded of "Relic Hunter," a cheesy Indiana Jones type TV
show here in the States. Every episode the characters go looking
for some rare lost item, and occasionally this requires some
secret key or magical artifact to open a vault doorway leading
to the treasure. It never occurred to anyone to try a crowbar
in the hundreds of years the door has sat there.
The situation is analogous with the enigma machine. This is
the big plot hole in the romantic encrypted message story.
-S
------------------------------
From: =?iso-8859-1?Q?Tom=E1s?= Perlines Hormann <[EMAIL PROTECTED]>
Subject: Re: Q: Message length in RSA
Date: Thu, 19 Oct 2000 16:47:12 +0200
Thanks to both of for your clarification. It helped me a lot.
Bob Silverman wrote:
>
> In article <8smnia$plv$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>,
>
> > > I have a question regarding RSA signing and encrypting.
> > > If I take a 160 bit SHA-1 hash and sign it with my private key (1024
> > > bits), how long is the signature going to be?
> > > And if I encrypt another message (some session key) which is e.g.
> 256
> > > bits long? How long is this message going to be?
> > > Is there a difference in the length of my private key and my public
> > key?
>
> A clarification:
> There are two components to each of these keys. The public key
> is (N,e), the private key is (N,d). [although N is redundant in the
> second case]
>
> One typically (and loosely) refers to the length of the public key as
> the length of N while the length of the private key is generally
> considered to be the length of d, even though both keys have more than
> one component.
>
> > > Everybody speeks about 1024 bit keys, but I read somewhere that both
> > > lengths are different. Is this true?
> >
> > Arrg... so many misconceptions so little time.
> >
> > If your RSA modulus is 'n-bits' long then all of the RSA messages
> > are 'n-bits' long regardless of how many bits you fill up. For
> example
> > decrypting (signing) the 160-bit hash can be considered as signing
> 160-
> > bit hash + n-160 bits of padding. The result is always n-bits long.
> >
> > Your RSA private key is the decryption exponent and is the same size
> as
> > well. Your RSA public key will most likely consist of the encryption
> > exponent (257 or 65537) and the modulus.
>
> Tom does it again. Opens his mouth in ignorance and puts his foot in it.
> When will he learn??? Tom, do us all a favor and SHUT UP until you learn
> this material.
>
> (1) Contrary to TOm's claim, all encrypted messages are NOT n bits long.
> m^e mod N will be n-1 bits with probability approximately 1/2, will
> be n-2 bits with probability 1/4, etc. Indeed, some standards allow
> or require m^e mod N to be replaced with N - m^e mod N, whichever is
> smaller, so in fact the final message or signature is ALWAYS 1 bit less
> than the modulus (X9.31 for example)
>
> (2) Similarly, the private exponent need not be exactly n bits long. If
> e is the public exponent, the private key must be at least n - lg(e)
> bits long, but can be shorter than n bits. [lg = log base 2] It need
> not always be n bits.
>
> --
> 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.
--
Quick answering: mailto:[EMAIL PROTECTED]
Check it out: http://www.weh.rwth-aachen.de/~tomas
Do it Now!
:o) Tom�s Perlines (o:
------------------------------
From: [EMAIL PROTECTED] (Jim Reeds)
Subject: Re: A journal about crypto history
Date: Thu, 19 Oct 2000 14:41:36 GMT
About the journal "Intelligence and National Security,"
in article <8sms06$43b$[EMAIL PROTECTED]>, Derek Bell <[EMAIL PROTECTED]>
writes:
...
|>
|> It would give a good idea of historical contexts ciphers were
|> used in, though?
|>
|> Derek
Oh yes. It is a professional historians' research journal,
so it will assume a certain amount of background information.
Questions like "how were the policy decisions affected by
the result of cryptanalysis" are addressed, and questions
like "how was the cryptanalysis accomplished" or "how did
the cipher work" are usually not.
--
Jim Reeds, AT&T Labs - Research
Shannon Laboratory, Room C229, Building 103
180 Park Avenue, Florham Park, NJ 07932-0971, USA
[EMAIL PROTECTED], phone: +1 973 360 8414, fax: +1 973 360 8178
------------------------------
From: Musashi <a [EMAIL PROTECTED]>
Subject: Re: How about the ERIKO-CHAN cipher?
Date: Thu, 19 Oct 2000 11:05:26 -0400
Well, not only does the government use things like cryptography in, say,
a battlefield radio, but other techniques too. I have no idea what
crypto the SINCGARS radioset uses, but I know that in addition to it, it
changes frequencies every second (synched with the other radios on the
net). Seems to me that it's a good idea not to put "all the eggs in one
basket".
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: Mathew Hendry <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom
Date: Thu, 19 Oct 2000 16:22:23 +0100
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] (Jim) wrote:
: On Wed, 18 Oct 2000 01:25:23 +0100, Mathew Hendry
: <[EMAIL PROTECTED]> wrote:
:
: >Three of the four rotors are missing. (Why steal only those?)
:
: Further ransom?
Maybe, except that no ransom has yet been paid...
--
Mathew Hendry, Programmer, Visual Sciences Ltd.
Work <[EMAIL PROTECTED]>, Home <[EMAIL PROTECTED]>
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: ECDSA
Date: 19 Oct 2000 17:47:02 +0200
"Jesper Stocholm" <[EMAIL PROTECTED]> writes:
> I am working with ECDSA for the moment, and currenty I am studying the paper
> by Alfred Menezes (et al) at [...]
That's quite a good paper, but be aware that one part has been rendered
obsolete by recent developments.
In particular, in section 5 they say:
"[...] cryptographically suitable elliptic curves over fields whose
orders are as large as 2^200 can be randomly generated in a few hours
on a workstation"
and:
"[...] counting the number of points on a randomly generated
elliptic curve is a complicated and cumbersome task"
This is no longer the case with the new Satoh-FGH algorithm and the
ECPC program that implements it very efficiently (written by yours truly :).
A curve over a field with order 2^200 takes less than 5 seconds on a
fast workstation and generating a cryptographically suitable one takes
a few minutes.
For more info see the Web site: http://www.xent.com/~harley/
Bye,
Rob.
.-. [EMAIL PROTECTED] .-.
/ \ .-. .-. / \
/ \ / \ .-. _ .-. / \ / \
/ \ / \ / \ / \ / \ / \ / \
/ \ / \ / `-' `-' \ / \ / \
\ / `-' `-' \ /
`-' http://www.xent.com/~harley/ `-'
------------------------------
Subject: Re: Code Book Cipher Challenge Cracked
From: [EMAIL PROTECTED] (Mark VandeWettering)
Date: Thu, 19 Oct 2000 16:17:34 GMT
In article <[EMAIL PROTECTED]>,
JPeschel <[EMAIL PROTECTED]> wrote:
>All 10 stages of Singh's Code Book Cipher Challenge
>have been cracked.
Well, I had a lot of fun with this. I only got 7 out of 10, (all
the easy and semi easy ones). I had a great deal of fun playing
with genetic algorithms to break the playfair, struggled mightily
with stage 3 before figuring out the one key bit, wrote, debugged,
and finally cracking stage 8 in just a few minutes of CPU time,
and in general learning more about traditional cryptanalysis than
any human probably has to know anymore. :-)
In retrospect, it is surprising to me that more people didn't get
stage 5, but all puzzles are easy once you know the answers. :-)
Great fun.
Mark
--
This signature has eight As, two Cs, three Ds, thirty Es, eight Fs, seven
Gs, nine Hs, fourteen Is, four Ks, two Ls, four Ms, nineteen Ns, thirteen Os,
two Ps, fifteen Rs, thirty one Ss, twenty four Ts, seven Us, six Vs, seven
Ws, two Xs, and four Ys. Mark VandeWettering <[EMAIL PROTECTED]>
------------------------------
Date: Thu, 19 Oct 2000 16:15:33 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Does RIPA require algorithm disclosure?
Some questions re RIPA (I've had a long hard look but can't find the
answer elsewhere).
[I am aware that cryptographer != lawyer, by the way...]
Er... let me Alice and Bob this. I hereby introduce Peter, from the
police, and George from GCHQ.
Alice sends Bob the message C = E(P, K). Bob knows D() and K (and, as it
happens, E(), but that's more or less irrelevant) so he could use D(C,
K) to extract P.
George has a copy of C, which he got from Bob's ISP or from a data tap
or whatever.
George (perhaps via the Home Secretary) asks Peter to pay a visit on
Bob, invoking RIPA powers, and using whatever formal channels are
necessary.
Peter formally requires Bob to hand him K. Bob (reluctantly) does so,
and promises faithfully not to tell Alice that he has done so.
(a) Does RIPA **require** Bob also hand over D() and/or E() to Peter?
Followup questions:
Alice and Bob have agreed on a series of keys and algorithms to use,
using the rule that either of them may, at any time, change either the
key or the algorithm to the next in the series (it's reasonably trivial
for either of them to work out that, if D1(C, K1) doesn't work, then
either D2(C, K1) or D1(C, K2) or perhaps D2(C, K2) is going to work
instead).
(b) Is Bob required to inform Peter of this agreement? If so, would Bob
have to hand over those keys and algorithms too?
(c) If Bob moves on to D2() or K2, does this constitute illegally
informing Alice that Peter has paid a call (given that they are already
in the habit of changing D and/or K from time to time on general
principles)?
(d) Has anyone actually met Alice or Bob? They seem to be getting into a
heap of trouble nowadays... ;-)
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: [EMAIL PROTECTED] (nemo outis)
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
Date: Thu, 19 Oct 2000 16:42:34 GMT
If you cannot keep a computer (or at least its hard disk) physically secure at
all times (perhaps in a work environment) then here are some suggestions:
You need to verify the computer to a "known-good" state at the start of a
session (usually the state in which you left it, but perhaps an older state)
to prevent modified executables, keyloggers, etc. being installed.
Use something like a zip disk (from an external parallel-port drive if the
computer doesn't already have one) with a home-rolled "verification suite"
consisting of verification programs and data, as well as clones of key files,
encryption software, and so forth. This disk must be kept physically secure
at all times (perhaps by being always carried on your person).
The core of this suite would be a program that does a SHA-1 (MD5, etc.)
verification of all executable and related files (EXEs, COMs, DLLs, VXDs,
java, macros, etc.) and which also looks for any new or missing ones.
(Verifying all files on the drive is better but rather slow and you may be
tempted to skip the step. The greatest weaknesses in most schemes are not the
strength of the encyption algorithms and procedures but laziness,
carelessness, thoughtlessness, and other human foibles.) The registry and key
ini files, etc. would also be either backed up in their entirety or
hash-verified, as well as the master boot records. (Some commercial programs,
e.g., Norton, provide some of these features in a convenient package.) A full
directory list for the hard drive would also be helpful. Needless to say any
important data files should be encrypted and/or hash-verified or backed up
also. The verification suite would be run at the beginning of a session
(daily?) and the final state markers copied to the zip disk at the end of a
session. (It might be desirable to keep a rolling backlog of the last several
end-of-session states, and a master "recovery" state.)
It is also necessary to verify the hardware state of the machine as well as
the software state. Hardware state is important because, for instance,
hardware keyboard transmitters are readily available. In a corporate
environment one must also watch out for the whole keyboard being swapped.
A simple method for hardware checking is near-imperceptible "tamper
indicators" such as a human hair lightly glued across seams of case and
keyboard entry panels. The orientation of screw slots may also be recorded
for comparison. Nothing so tedious to check that it will be sloughed over
(which largely precludes regularly opening everything for inspection).
There is also the possibility of micro-video keyboard/screen observers being
installed in the general environment. Tough to spot. As a minimum cover the
keyboard with a towel, etc. when entering master passwords for scramdisk, etc.
You may also wish to supplement the "state" validation with a "process" method
during use (quite helpful when you leave the machine for a few minutes but
don't want to re-run the whole validation suite). Your own keylogger (which
logs to an encrypted file) might provide a little additional protection.
Other programs such as filemon and regmon do a great job of catching
software-based spyware in action if they do sneak past your state check.
None of this is good enough to thwart a three-letter-acronym opponent (who may
even use Tempest methods, etc.) but it will significantly harden the machine
against garden-variety foes (e.g., snoopy sysadmins in a corporate
environment).
Regards,
In article <s1uH5.1287$[EMAIL PROTECTED]>, "bubba"
<[EMAIL PROTECTED]> wrote:
>Backdoor BIOS passwords for many computers can be found on the
>net. In addition, I doubt many BIOS password schemes involve
>modern encryption algorithms. But your worry seems legitimate. I
>could build a PGP replacement executable that operated normally
>and correctly, except that it maintained a stealth list of all passwords
>entered.
>
>
>"pgp651" <Use-Author-Address-Header@[127.1]> wrote in message
>news:[EMAIL PROTECTED]...
>> -----BEGIN PGP SIGNED MESSAGE-----
>>
>> When you need to protect PC [ win95/98 is running on it ] against physical
>> tampering [ to sneak into PC some backdoor software, software key loggers,
>> replacements of encryption binaries ... ] on PC that has wide & open
>> physical access to it, what would be the most cost effective solution ?
>>
>> The people in question are using & are customized with encryption for
>> e-mail, PGP and with hard disk encryption, PGPdisk.
>>
>> They have good protection in case of virus infection, the online active
>> VShield is intercepting all disk activities.
>>
>> The possible problem of less protected exposure exists when booting
>process
>> is transferring access from DOS to WIN operating system. This time all can
>> be suspended, software added to not encrypted disks [ win95/98 is not
>> running from encrypted disk ], executables replaced, software installed.
>> They are very comfortable with PGPDisk encryption and would like to stay
>> with it when possible.
>>
>> One of the first option that has been suggested, is BIOS password. It is
>> very short, about 5 characters long, but it could created about 60 minutes
>> buffer.
>>
>> From description how the PC is used, users are estimating that window of
>> intrusion could be no longer than 60 minutes, except the PC is stolen. In
>> the event of stolen PC, data is protected by PGPdisk.
>>
>> The solution they are willing to consider would be in the area of knowing
>> that tampering occurred instead, when prohibitively expensive, preventing
>of
>> tampering with.
>>
>> Any suggestions would be welcomed.
>> Thank, pgp651
>>
>> ~~~
>> This PGP signature only certifies the sender and date of the message.
>> It implies no approval from the administrators of nym.alias.net.
>> Date: Wed Oct 18 21:20:41 2000 GMT
>> From: [EMAIL PROTECTED]
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: 2.6.2
>>
>> iQEVAwUBOe4ULk5NDhYLYPHNAQHS4wf/UX9w24DKG8AtZZBfgs9trLpZY+YrgeUb
>> hOJSlhK6jdbxgXnxqu/vRjMi8AsQRuei21uRLRmKj7jwLlIZLlMpNtaCrl6bSKkN
>> E3aIXTKtye3rc2B4ANMd08iXOEjw145yMMSi76N9gyc0TiVFUvIGti+LZuTQ76Hm
>> wKTCDuZqaC8luSj/mvB+2QLWBn/ixwEAKMElzUjT1aoMkjWMxcoxuWImAtAbUoJ7
>> DnWhBKKqGAHpbHdv8W586jz+sMxOWMUJORq4MPpKuWokpIdaKoih9Wfbwuj7pBX9
>> iFmwHj595dBJTYtltTgny68h+S4Qp5WeeyxJn05GfCpU4X+z3SSEFg==
>> =0UiU
>> -----END PGP SIGNATURE-----
>
>
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: Re: What is desCDMF?
Date: Thu, 19 Oct 2000 09:23:09 -0700
"Yonghan, Yoon" wrote:
> what is Commecial Data Mask Facility ?
>
> How to implement 40-bits des key?
Look in Schneir's "Applied Cryptography", 2nd edition, p. 366.
------------------------------
From: "Robert Hulme" <[EMAIL PROTECTED]>
Subject: DLL TripleDES and MD5 on Win32
Date: Thu, 19 Oct 2000 17:57:37 +0100
Hi,
Could someone please help me - I' having loads of trouble.
I'm implementing a system where I'm using the mcrypt library with PHP on a
Unix system to decrypt data stored in a database with TripleDES and
passwords stored with the MD5 hash.
The program that prepares the data though needs to run in Windows NT
(Win32)... I'm using VB to write the application that manages and encrypts
the data ready for going on the webserver. The problem I'm having is finding
a DLL or some VB code that will encrypt with TripleDES and MD5. I can use
mcrypt, but not on Win32 - there is a Win32 port of mcrypt - but its a
command line program - I need like a DLL or something to link to my program.
Free / GPLd software is really what I'm looking for - as one of the
strengths of the current system is that it only uses GPLd software.
Do you know of a DLL or any VB code that can do this?
Cheers
-Rob
http://www.robhulme.com
------------------------------
** 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
******************************
