encryption (passwords)

[Gumuz]

Actually, I am trying to create a sort of simple instant messenger
server+client.

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
this, too.



"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
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.