encryption (passwords)

Steve Holden sholden at holdenweb.com
Sat Sep 7 20:33:07 CEST 2002

"Gerhard Häring" <gerhard.haering at opus-gmbh.net> wrote in ...
> Gumuz wrote:
> > I am quite a newbie regarding encryption stuff. There are some issues
> > boggling my head and I suppose these come from the fact that I have no
> > clue how to apply encryption in a real-life situation.
> >
> > I am using network-sockets to communicate between two(or more) python
> > applications. I want to encrypt these messages, or at least a part of it
> > e.g. password and such.
> Ok. I'd recommend to use SSL instead of inventing your own crypo layer.
> probably go with PyOpenSSL.
I'd agree that implementing your own encryption technique is unlikely to be
secure. Use the work that's already been done.

> > My limited understanding of encryption tells me that I need a 'key' to
> > decrypt stuff.
> There are two kinds of encryption:
> - symmetric encryption
> - assymemtric encryption
> Symmetric works by both ends having the same key. The sender encrypts the
> message with the key, the receiver decrypts it using the same key. The
> problem is that you have to distribute the keys first, and have a secure
> way of distributing the keys.
In other words, a second (secure) channel is required to comunicate the key
to be used on the first channel. Fortunately teh second secure channel can
be the same channel but using public-key (asymmetric) encryption.

> Asymmetric encryption works by splitting the key up into a private and a
> public key. The private key can only be used for decrypting, the public
> only for encrypting messages.
Not strictly true, it depends on the requirements. Aysmmetric encryption can
be used to provide three different features:

1. Privacy. In this case the sender encrypts the message with the
recipient's public key. Since it can now only be decrypted by the holder of
the corresponding private key, the assumption is that only the intended
recipient will be able to decrypt it. This is the case Gerhard describes.

2. Authentication. Here the sender encrypts the message with their own
private key. Anyone with access to the sender's public key can decrypt it,
and since the decryption process gave a legible message it is reasonable to
assume that it really was encrypted by the holder of the corresponding
private key.

3. Integrity. Here the sender generates a message digest (some function
computed from the content of the message, ideaaly using a recognized
cryptographic hashing function). The digest is of fixed length, and with a
"good" hashing function it won't be possible to generate arbitrary message
digests with a particular digest value. The sender then encrypts the digest
value with their private key, producing what is normally calles a "digital
signature". The recipient decrypts the digest with the sender's public key,
and independently verifies (by generating another message digest locally)
that the message they received has the same digest value as that inserted by
the sender. If this is not the case then either the content or the digest
has been tampered with, and the message content should not be trusted.

Steve Holden                                  http://www.holdenweb.com/
Python Web Programming                        pydish.holdenweb.com/pwp/
Previous .sig file retired to                    www.homeforoldsigs.com

More information about the Python-list mailing list