Re: public private key, 3DES

From: Alek Davis (
Date: 03/08/03

From: "Alek Davis" <>
Date: Fri, 7 Mar 2003 16:08:15 -0800


It looks like Michael answered your questions, but I would like to add a
couple of comments you may or may not) find useful.

1. When you want to generate a persistent (i.e. the same) symmetric key, you
normally derive it from a passphrase and initialization vector (IV).
Depending on how you do it, you can also specify salt value, hash algorithm,
and some other parameters. Check these examples: (it uses Rijndael algorithm,
but the process is pretty much the same as 3DES) and By the way, if you do not need to use 3DES, you are
better off using RijndaelManaged. Anyway, whatever you choose, you must
preserve the values from which the key is derived (passphrase, IV, etc), so
you end up with the problem of protecting these values. Here is one way of
doing this is (this sort of how we do it); I am not sure if you can do the
same, but it wouldn't hurt to know. Let's say systems X1 and X2 send info to
system Y. (1) Y generates public/private key. (2) X1 calls Y to get Y's
public key. (3) X1 generates random passphrase, IV, etc and generates a
symmetric key from these values. (4) X1 encrypts info using this symmetric
key and encrypts passphrase, IV, etc using Y's public key. (5) X1 sends data
to Y. (6) Y decrypts passphrase, IV, etc using its private key, generates
symmetric key (assuming that it uses the same algorithm, key size, etc as
X1) and decrypts the actual data using this key. X2 follows the same
procedure as X1. The advantage of this approach is that you do not need to
store passphrase, IV, etc anywhere; you only need to keep a consistent
public-private key (if you are concerned about making it the same between
the program invocations, which I think you do).

2. If you pass small values, using public-private keys is OK; otherwise, it
will be slow and may not work at all.

3. I do not really know how it works in .NET. I used public-private keys in
CryptoAPI, but I did not care if they changed from one program invocation to
another. I think you can do it by specifying a key container. So when your
program starts at the first time, you create a persistent key container
(assuming that it did not exist before), and then you just use it . Again, I
did not do this myself, so I may be wrong, but I think this is how it should
work. Just make sure that you restrict access to this key container.

4. Don't quite understand what you are asking. 3DES keys are 168-bit long
(or 192-bit depending on which bits you are counting).

If you are interested in security and cryptography, read "Building Secure
ASP.NET Applications" (; it is more about security
than cryptography, but it also has very good examples (which are easy to

-- Alek

"Thorsan" <> wrote in message
> Hi
> We are developing a distributed network monitor application. We have x
> number of services collecting different values from routers, the
> information is then sent using MSMQ to our server. I have successfully
> encrypted the msg's using 3DES, and decrpyted it, but...
> I have a couple of questions relating to this last point.
> 1. I seem to understand that I am supposed to supply a key and a IV ?
> I dont I I just use a password.
> If so how does one generate these values, can I base the keys
> on a secret phrase to generate them ?
> 2. I have read up on the subject of Private and public keys, this
> seems to be what I need, since my collecting services only need to
> encrypt the messages, and the server is the only who needs to read
> them. Correct?
> 3. The private key is not to be distributed or saved, how do I then
> read messages in a que after generating a new private key in the event
> of lets say a reboot of the server ?
> 4. 3DES needs a 16bit key as far as I understand, but before I became
> aware of this i just used string pass = "Hello", the message was
> malformed(encrypted), then decrypted to original state why, I think I
> missed something here?
> Hope some of you can help me with these questions, and if anyone can
> refere a good book relating this issue it would be most appreciated. I
> would also appreciate if you could reply to my email provided below,
> as well to this group(I will reply in the news group so that others
> can benefit from the thread of course)
> Thanks in advance
> Thor Ingham