view release on metacpan or  search on metacpan

Encrypted.pm  view on Meta::CPAN

  [... continue using $ftp ...]

example #3 - a POP3 email client session with keys in unguessable places:

  use Mail::POP3Client;
  use Crypt::RSA::Key;
  use Data::Encrypted;

  my $public = new Crypt::RSA::Key::Public::SSH
                 Filename => '~/.ssh/mykeys/public';

  my $public = new Crypt::RSA::Key::Private::SSH
                 Filename => '~/.ssh/mykeys/private'
                 Password => 'The Only Good Computer Is A Dead Computer';

  my $encryptor = new Data::Encrypted ( FILE => './.pop3email',
                                        SK   => $private,
                                        PK   => $public
                                      );

  my $pop3 = new Mail::POP3Client
               ( USER     => $encryptor->encrypted('user'),
                 PASSWORD => $encryptor->encrypted('password'),
                 HOST     => $encryptor->encrypted('host')
               );

example #4 - build a script to send to Bob that allows him to ftp
files from you, without passing along your connection information in
clear text; note that you yourself won't be able to actually use the
script without entering the data each time.  Also note that Bob could
easily read the encrypted information, so it is not secure from him.
It is only secure from prying third-parties.

  use Data::Encrypted;
  use Net::FTP;
  use Inline::Files;

  open(ENCRYPT, "+<") or die $!;
  my $encryptor = new Data::Encrypted FH => \*ENCRYPT,
                                      PK => '~/pubkeys/bob.pub';
  my $ftp = new Net::FTP "ftp.mysite.org";
  $ftp->login($encryptor->encrypted('user'),
              $encryptor->encrypted('password'));
  $ftp->cwd($encryptor->encrypted(q{Bob's directory}));
  $ftp->get($encryptor->encrypted(q{What Bob gets to download}));
  $ftp->quit();

=head1 BUGS/TODO

Inline::Files won't (yet) allow one package (i.e. Data::Encrypted) to
work with virtual files in another package (i.e. main); as a result,
you have to feed your virtual storage file to Data::Encrypted
manually.  Not so much a bug as an interface drawback.

Our usage of Inline::Files-generated filehandles is a bit noisy -
especially when first using "empty" virtual files (a known bug in
Inline::Files).  Damian Conway has said he'd think about trying to fix
it someday.

This idea could be extended to the Tie::EncryptedHash or other
Crypt::CBC-employing methodology, but would lose the fundamental
advantage of not requiring any clear text password or passphrase to
remain associated with the script.  Perhaps people wouldn't mind
typing one "universal" password or passphrase to get at their saved,
encrypted data ... ?

When Data::Encrypted prompts for unknown data, it could ask the user
to repeat their data entry for validation, to cut down on the
possibility of typos.

Currently the data is keyed via the prompt - hence if you use the same
prompt twice, the second piece of data will overwrite the first.

The data could be made to be "application-specific", so that the same
encrypted data storage file could be used for multiple applications
(without overwriting each other's data).  This could be as simple as
adding an additional dimenion to the hash, keying on $0 ...

When someone calls finish(), we close everything up ... but when
encrypted() is called, we don't ever check whether we've already
called finish, so this behavior is, uhmm, undefined I guess.

=head1 COPYRIGHT

Copyright (c) 2001 Aaron J Mackey. All rights reserved.

This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.

=head1 AUTHOR

Aaron J Mackey, amackey@virginia.edu

=head1 ORIGINAL IDEA

William R. Pearson, wrp@virginia.edu

=head1 SEE ALSO

Crypt::RSA, Inline::Files, Term::ReadPassword, File::HomeDir, perl(1).

=cut