in reply to Safely Transferring Information on the Internet

Yeah, people are silly animals. They will be afraid to run a perl script from the web, but they do run a huge program called a browser without blinking an eye, even if they cannot inspect the source (be it because it's closed source, or even if they have the source, they either don't understand it (about 99.999%) or because it's just not feasible to do an audit (not everyone has a few weeks to spare)).

Fact is that you need to do something on the client side to decrypt it. You don't need https of course, but then you need to convince the client side to run alien code. Luckely, almost anyone happily runs any Java applet send their way. So, that's an option if you don't want to use https.

Note that https (or rather, the use of certificates) can give you things that PGP or something similar cannot give you: authentication of both the sender and the receiver (PGP can give you authentication of the sender, that is, if you have a way of proving a certain key belongs to a certain person).

But you said "as safe as possible". Even with https, you are still not as safe as possible, because you are merely encrypting your data. What you are not hiding is the fact information is exchanged - or whether that's a small or a large piece of information. There are techniques to make it hard to do any form of traffic analysis, but they aren't easy to do right, and I doubt you will find canned solutions on CPAN.

Abigail

  • Comment on Re: Safely Transferring Information on the Internet

Replies are listed 'Best First'.
Re: Re: Safely Transferring Information on the Internet
by hmerrill (Friar) on Aug 07, 2002 at 13:22 UTC
    At a company I used to work for, we used PGP this way: 
      * client company and our company agree to use PGP to
    exchange private PGP encrypted files.
  * client company and our company (generate if necesary,
    and) exchange PGP public keys
  * client company develops their own methods(manual or 
    automated scripts) for encrypting files to send to
    us, *AND* for decrypting files that we send to them.
  * likewise, our company developed our own software based
    on PGP's command line batch API, for encrypting files 
    to send to clients, and for decrypting encrypted files 
    sent to us by clients.

    [download]

    I haven't personally used Crypt::OpenPGP, but I'd bet that all the tools are there to allow you to script both encrypting and decrypting GPG files.

    What https gives you is security while your data is *being* tranferred from the browser to the server and visa-versa. If you don't have https availability, in my mind the next best thing is encrypting the data on one end, and decrypting data on on the other end. Just my opinion.

[reply]
[d/l]

In Section Seekers of Perl Wisdom