I have never done a particularly large amount with Paypal. It's come up occasionally but I've always done the hastiest job possible, perhaps pasting some code from PaypalTech.com or something. This time I've been working in Python with Django so I've had to develop everything from scratch with the M2Crypto OpenSSL wrapper. Paypal's developer documentation lacks sufficient detail for a clean-room implementation (thought there are numerous examples to be found, none exactly corresponded to M2Crypto/Python). Furthermore, it does not give useful error messages, which can make it extremely troublesome to integrate with.

This is how I made EWP work.

1. Paypal expects data to arrive as a set of key-value pairs, which you should already have/know about. The documentation for these is extensive.
2. Make the payment system work unencrypted, using input fields with the corresponding names and values to the key-value pairs. This ensures that the information PayPal needs to receive is correct before you start faffing with encrypting that data. If you do not have a PayPal account, you can sign up for a "sandbox" account, then register as many scratch accounts as you like. Note that PayPal does not email you the confirmation emails for sandbox account; they appear in the sandbox interface under the "Emails" tab.
3. Generate an SSL keypair in PEM format with openssl genrsa . If you view this file, it is titled as "PRIVATE KEY", but it does contain both private and public keys. The exact commandline arguments for this command are documented in the PayPal Website Payments Standard Integration Guide.
4. Generate a self-signed SSL certificate from your keypair with openssl req. An SSL certificate contains your public key, some details about the owner, and one or more cryptographic signatures. Again, this is well documented.
5. Exchange certficates with PayPal by logging in and visiting "Encrypted Web Payments" under "Profile". You save PayPal's certificate to a file, and upload your own. Paypal assigns a certificate ID to your certificate, which you must now add to your key-value pairs under the key cert_id . It displays this certificate ID in the table and will also email you a copy. Recall however, that PayPal's sandbox development server does not actually email you; "emails" are stored and are available on the web interface under the "Emails" tab.
6. Generate the plaintext for the signing by encoding the key-value pairs as key=value , separated only by linefeed (\n, ASCII 0×0a) characters. CR-LF does not work.
7. Sign the plaintext using S/MIME. This requires both your private key (for the cryptography) and your certificate (to identify whose signature it is). Use these options:
   • Use binary input mode, which prevents OpenSSL munging its input.
   • Encode the data in opaque form. This implies that the text to be signed is encoded along with the signature, as opposed to detached, which doesn't encode the plaintext.
   • Output the resulting PKCS7 structure in DER (not PEM, nor S/MIME) format. This is a binary format.
8. Encrypt the resulting DER using PayPal's certificate (ie. public key):
   • Again, use binary input mode
   • Use the 3-key triple-DES, CBC mode block cipher. OpenSSL calls this des-ede3-cbc or just des3.
   • Output the resulting PKCS7 structure in PEM format, which is a base64-encoded format.
9. Insert the PEM blob into a form field named encrypted. There must also be a hidden value form field, named cmd, with value _s-xclick.

MP3 streams consist of a bundle of frames. Frames begin with a 12-bit string of zeros, then there is a brief header which gives the bitrate and length of the frame, then the frame data. MP3 players should wait for the 12-bit sync, then read the frame, then wait for another sync (in most MP3 data this follows immediately).

It should be possible to bung in random bytes in there between frames and have players ignore it completely.

What if the bytes you stick in there comprise a filesystem? Say you use 10 6MB MP3s and pad them by say 10% with the filesystem data. 6MB filesystem! Enough for your most important secrets, and nobody is going to look for it there. Security through obscurity. Still, that's only version 1 of the protocol (ie. it occurred to me first).

Version 2: use a block cipher to encrypt the filesystem. Obviously, this is important as otherwise plaintext bytes are readily visible.

Version 3: hide the MP3s that you've used to create the filesystem in a collection of MP3s – a large but random number of MP3s that have been similarly padded, but with junk. Now you need the right MP3s in the right order. Choosing r MP3s in the right order from a set of n gives ⁿP_r combinations, which, for r << n is approximately n^r. For example, choosing 10 (in order) from a relatively modest collection of 500 (~ 2⁹) is roughly equivalent to a 90-bit passphrase or a 15-character random password consisting of A-Z,a-z,0-9. But the nice thing about this is that humans should be good at reconstructing playlists from memory, even with thousands of MP3s to choose from.

Version 4: Stripe the bytes between different MP3s. Ensure that cipher blocks are split between MP3s. This ensures that you can't run a brute force crack attempt against part of the encrypted data because you can't dig a whole block out of any one file.

Version 5: (optionally) use some acoustic element of the assembled MP3 playlist as part of the passphrase for the block cipher. Entering one 'digit' of passphrase might be the equivalent of selecting a riff in the right song, or one particular lyric. Say you have to choose a 5-second segment from your 10 3-minute MP3s – that's about 8.5 bits of passphrase.

Version 6: swap some, but not all of your MP3s with P2Ps. There is an element of deniability – the random data may or may not be yours. Most MP3 collections I've seen have been collected from hundreds of different sources – and anyone using the system will have lots of MP3s with a mixture of junk and real padding, so to find many MP3s containing junk on any one system does not mean they have encrypted data. It just means they are guilty of piracy.
Told you it's completely ridiculous. But isn't it fun?