gumuz at looze.net
Wed Sep 4 07:14:15 EDT 2002
Actually, I am trying to create a sort of simple instant messenger
although this is just a play-learn-project and security is not really an
issue, i'd like to include encryption in it as well to get experience in
"Paul Rubin" <phr-n2002b at NOSPAMnightsong.com> wrote in message
news:7xd6ru2gfi.fsf at ruckus.brouhaha.com...
> "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
> > get over the idea that if my application becomes open-source anyone
> > 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
> 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
> 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.
More information about the Python-list