I've never used PGP, and if they were my customers, I wouldn't force
them to install PGP, but ... I hear that PGP has password-based
symmetric file encryption using the -c option on the command line. This
option is viable even if the customers are overseas, since you would not
export the PGP code.
  If the recipients are all where you don't need an export license and
you want to write it yourself, you need an implementation of SHA-1 and
an implementation of a block cipher, such as AES, or stream cipher, such
as RC4 (which IMHO needs too much coddling for a secure implementation).

  The basic plan for each file is,
  generate an AES encryption key using SecureRandom.
  Generate an HMAC-SHA1 authentication key using SecureRandom.
  Encrypt the file using AES in counter mode. The initial counter value
can be fixed, say 0. Each block is ciphertext=plaintext XOR
AES_k(counter++). No need for padding.
  Form the HMAC-SHA1 message authentication code of the ciphertext and
append it or prepend it.
  Post the ciphertext with its MAC to the web site.

  The decryption code first checks the MAC of the ciphertext using the
authentication key, then XORs the ciphertext with the successive
AES_k(counter++) values to recover the plaintext.

  A CD with a OTP is practical, certainly if you're not going to do
this very often. A few lines of Java would suffice for the decoding. You
can run AES in counter mode to generate the pad using a random key, then
throw away the key. You'd still want an MD5 or SHA1 implementation, for
the authentication.
  Note: This wouldn't be a OTP in Shannon's sense. For that, you'd need
something more like SecureRandom.getSeed().

  The interesting part is the key distribution. If you're not going to
put the entire keystream and authentication key onto a CD, you could
  generate the encryption and authentication keys by hashing a
high-entropy password, then distribute the password secretly.
  Generate the keys at random and protect them by XORing with the hash
of a password that you distribute secretly.

  If you have more interaction with the recipients, if in particular
they can generate public/private key pairs, there are more possibilities.
  For RSA, generate the (symmetric) keys at random, pad with OAEP,
encrypt them with each recipient's unique public key, and send (or post)
the results openly.
  For DH, generate an ephemeral public-private key pair for each
recipient, send the public key and the XOR of the symmetric keys and a
hash of the shared secret, to each recipient openly. Then throw away the
ephemeral private key.

  Each of these key distribution methods can be made to work, and each
has its own set of gotchas.

--Mike Amling

If you are already willing to go with HTTPS why not have just have a
secure web site with HTTPS where you need a user name and password to
get to the items they are allowed to download ?

In any case once they get hold of the encrypted bob and they decrypted,
it is out of your hand in term of security and if they wanted to
redistribute it and you would not know about it.

If you wanted security on the destination site because the off site
people are using notebook, and the main users are not people that deal
with security in general, the best solution we found was to use pgpdisk
or some program like that would let you encrypt a whole partition.  So
anything confidential should go to that encrypted drive.

Minh Tran-Le.