encryption (passwords)

[Paul Rubin]

"Gumuz" <gumuz at looze.net> writes:
> My limited understanding of encryption tells me that I need a 'key' to
> decrypt stuff. So I figure that this key will bey written(hard-coded?)
> somewhere in my Python-script and it needs to be known at both sides in
> order to encrypt and decrypt. Somehow, I can't believe this is true. I can't
> get over the idea that if my application becomes open-source anyone could
> see the key and decrypt my messages.
> 
> I am fairly certain that it probably doesn't work this way, but I have
> really no idea. Cann someone clarify this for me?

OK, first of all, that type of question is probably better asked on
sci.crypt rather than the Python group.  

Second, a word of advice: don't try to implement encryption protocols
with your present state of knowledge, and especially don't try to
design protocols yourself.  It's extremely easy to make mistakes that
mess up security.  Even experts make those mistakes, all the time.

I'll sketch out answers to your questions but basically I think your
best approach is to use an unencrypted protocol between your Python
scripts, and tunnel it through an encrypting socket layer that someone
else has already debugged.  The two most popular choices of encryption
layers are SSL and SSH.  SSH has a "port forwarding" feature that lets
you set up local ports on both machines, that communicate through an
encrypted tunnel.  Your Python program would just open the local port
and send unencrypted data to it, and the same data would appear at the
other end transparently decrypted.  SSL is a fancier protocol that
doesn't incorporate forwarding, but there's a program called stunnel
that implements forwarding over SSL.  

Between the two, I'd say SSH is a easier to set up if you're just
trying to secure a single socket pair between two machines.  If you're
trying to have a bunch of machines that talk to each other, and/or
they're not all controlled by the same people (e.g. you're a vendor
that needs to exchange secure traffic with various different
customers), you probably want to use SSL.  That type of network is
called an extranet and various books have been written about how to
build and manage them.  If you say more specifically what you're
trying to do, I or someone else here might be able to advise you more
usefully.

Finally, if you're building any kind of secure system that's intended
to protect valuable data, I recommend you read "Security Engineering"
by Ross Anderson all the way through before deploying your system.  It
will give you an idea of what you're up against and what kinds of
measures you can take.

Re your basic questions:

Yes you're correct that you need a secret decryption key.  The key
should be unique for your specific installation, NOT part of the
program that gets distributed.  It's like the password that you log
into your computer with.  The login program is distributed freely as
source code, but your password is not part of it.  You install the
program, THEN set your password for your specific account.

Then there's the problem of how to store the key, so your program can
use it.  There are several approaches, each with good and bad points:

    1) Include the key, in cleartext form, as part of the program
    configuration that gets loaded at program startup.  Good points:
    convenient.  Bad point: anyone with access to the config file
    (possibly gotten by breaking into your system) gets the key.
    This method is not recommended if the data being protected is valuable.

    2) Use a passphrase as a key that you enter when you start the
    program, so it stays in memory and doesn't get stored on disk.
    Good point: better security (key not stored).  Bad points: you
    have to enter the key every time you start the program.  If you
    want someone else to start the program for you, you have to tell
    them the passphrase.  If the program has to start without human
    attention at reboot if the system crashes, you're hosed.

    3) Encapsulate the key in a special hardware device that does the
    cryptography.  This can range from a $5 smart card or USB dongle, to a
    multi-kilobuck sealed module on your PCI or SCSI bus.  This is the
    preferred method for high security applications (banking, etc.).  Good
    points: best security of all, key can't be stolen without physical
    access to the machine, can implement its own access controls, etc.
    Bad points: special hardware required; cheaper devices are slow.