Re: best practices for encryption key managment??

On 05/27/2004 05:27:37 AM, Pete Finnigan wrote:
> Hi lawrence,
>
> You have found the problem with encryption, key management.

Basically, that is the problem with ANY encryption. The nature of the problem is this: you have encrypted information which can be decrypted only by using specific key. You have to, somehow, make the intended recipient of the confidential information aware of the key, but without exposing it to the others. One solution is the "code book", which lists which keys to use when. If both parties have the code book and know when to use which key, there is no problem. If, on the other hand, the book gets stolen or copied, the confidentiality is gone. There are numerous stories from WWII about stealing code books. This particular method relies heavily on the physical security and was almost always broken, if only the target was valuable enough. It needs to be noted that, in this method, encryption was used both for transfer the information and authenticate it, because it was assumed that whatever was properly encrypted, was authentic. This is so called "private key" encryption. Opposite of the private key encryption is public key encryption, in which each of the communicating parties have 2 keys: private and public. As the names say, private key is kept secret by its owner, while the public key is made public to all interested parties. Information encoded by someone's public key can only be decoded by his secret key. Public key of the originating person is used to authenticate the message and confirm that it is coming from the right source. Here the certificate authority enters the picture. There needs to be an authority which will confirm or deny that somebody's public key is, indeed, his and not of an unidentified third party, trying to spoof the recipient. The problem with the public key encryption is that all commercial algorithms have been broken by universities and intelligence agencies like NSA. If the information that needs to be protected is valuable enough, the encryption will be broken and the information will reach unintended recipients. That is, in essence, the story of "echelon"

-- 
Mladen Gogala
Oracle DBA



Note:
This message is for the named person's use only.  It may contain confidential, proprietary or legally privileged information.  No confidentiality or privilege is waived or lost by any mistransmission.  If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Wang Trading LLC and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks.
Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity.

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------