in reply to Safe symmetric encryption - Crypt::CBC + Crypt::Blowfish?

Hi, I'd like to add two questions of my own as I need to do two encryptions in an app I am building (asap) now.

The needs are encrypting forms and encrypting some credit card numbers.

1. Encrypted Forms. This is mainly to obfuscate so that a casual cafe user can't read user data, as SSL is used if delicate info is needed.

I have a module I built for myself, which I've used in a couple of recent projects to encrypt multipage form data. Part of it I made after looking at the EncryptForm module on CPAN. I freeze a hash, websafe pack it, encrypt with CBC (Blowfish) and drop it into a hidden input field on the next HTML::Template generated page.

As I understand the thread, it would be totally unsafe to use RC4, in particular that would allow someone to detect the server's password and potentially use that later to get other people's session info. Whereas Blowfish would be okay, or better yet AES. Presumably changing server password every few months also not needed with Blowfish/AES keyspace sizes. Is this correct? Some machines only RC4 worked.

2. "A few Credit Cards". Highest priority question for me. I have a seminar signup system which will accept credit cards for the overseas users. In the future if everyone was allowed to do so I could have hundreds of credit cards per seminar.

The idea is that user data will be stored in a CSV text file but the credit card number will be encrypted. Site management staff can download all or part of the CSV and have it open in Excel, with the credit card numbers still encrypted. Or, they can first type in a password, which will then cause the credit card number column in the spreadsheet to be completely decrypted and you can view the plaintext of the spreadsheet including cc#'s in Excel just fine.

This would seem to require a public key system. Which module would be best? Consider this system must run on an old perl on a cheap provider, I can compile modules though would rather not have to build openssl if not crucial. While I only expect under 20 cc#s this time, in the future I might want to have thousands. I wonder if the pure perl modules I see on CPAN here would be fast enough to decrypt them before browser timeout.

So right now I would like to find the easiest to install/use package to solve this answer and do more later if I need faster. I've used perl/openssl for live credit card authorization in the past, it's a bit much for now. I'm thinking about Crypt::OpenPGP. Thanks for your help.

  • Comment on **Another 2 questions: Encrypting forms and credit card numbers

Replies are listed 'Best First'.
Re: **Another 2 questions: Encrypting forms and credit card numbers
by diotalevi (Canon) on Feb 09, 2003 at 16:28 UTC

    On the general question I asked — theorbtwo had a wonderful suggestion that lets me completely avoid having to deal with encryption at all. If I had to use encrypted data then I wouldn't be able to cycle through keys at will since other people would be holding the encrypted data. The best comprimise might be to use new keys for new data and switch as the opportunity arised.

    If you're curious, theorbtwo suggested that I store all the data myself and only pass out tokens which reference the stored data. To do this, I'd store a key, an incrementing counter and then publish counter values and the Digest::SHA1 value of counter+secret. This also lets me change the key at will since all I have to do is store the expected counter and hash. Since random data is precious I have no idea how often I'd get a new secret but its also overkill for this application.

    Now, mattr. This whole credit card deal is a tricky business. My first suggestion to you is to subscribe to the secprog list on You are about to step right from the deep-end of the swimming pool into the Atlantic ocean. You are going to need to be well armed when you go back to your client and change the requirements (what you've described so far requires an unsecure configuration). Read the archive and especially read the entire thread named "PGP Scripting". It sounds like that person's problem somewhat parallels yours.

    Now here's my inexpert analysis (but augmented by what I've learned from being on that list). You cannot allow the server to decrypt the data. Ever. The key ideas to follow here are obfuscation and barriers. You're installing a level of obfuscation by doing things that might make the job technically more difficult but will not stop a determined attacker (oh yes, you must also write up an attack summary). This includes any use of encryption on the server where an attacker can decrypt your data.

    The other level: a barrier is where you need to get to. The difficulty is that this is difficult. In general, your best bet is to use some form of encryption on the unsecure server, send the data elsewhere and on unrelated networks, only then can you decrypt the data and it never goes back to the front-facing server. This of course, implies that your application can never deliver plaintext card data. Your user cannot enter a password to get the data. That's just bad design. What you might do is restrict access to the encrypted data and then have your user do the decryption.

    I think your question is too important and too hairy to be addressed by me in a response thread to an unrelated question. Ask in a new SoPW question and ask on the secprog list. I'm suggesting both because while the secprog list will probably furnish better answers the perl folk here will benefit by whatever gems are mentioned in responses but since secprog is chock full of people whose job it is to think of these problems, it'll have superior answers, generally.

    Seeking Green geeks in Minnesota

      Thank you very much for your detailed response. I understand what you are saying and of course I could provide a perl app to run on the adminitrator's local machine which would decrypt a downloaded csv file.

      I do require ssl and a login to get to the management page, though hearing your opinion I would be inclined to be doubly sure I am not storing password as plaintext. Also I have a different login/password for the staff and for the manager(s) at the company who actually need to see the credit card numbers. Question of whether that is enough or not. Considering it's just a junky virtual host account somewhere I guess the admin can do many bad things to it, but I think getting the cc numbers would require that either he can listen in on the script's decrypting process (possible if he changes my code) or crack the ssl session (I don't think so but hey it's his openssl).

      My insights so far: I need to ask a SOPW and immediately plan on providing a perl utility (hopefully perlcc since installing perl might be a hassle) then try some perl gui-ness.. can you spell ballooning?

      Oh the insights from that thread, right.. it is not tamperproof hardware, memory is not safe especially since I'm not root. Also I don't have time to look at strings /dev/kmem or looking at /proc/*/kmem or ptrace which I guess maybe someone could do if they're really quick while script is executing for a few seconds a day. Realistically this is really not a problem for my current app but what if I used the same system for something bigger in the future.. Okay I'm only half way through and it is a long thread. I think the question to ask (think I know the answer already though) is how safe is perl when decrypting from remote machine over ssl? If I get more insights from rest of thread will update here. Thanks.

      This post I'm not familiar with the systems he mentions. Sounds like something a bit magical which is definitely not going to be available on a cheap provider anyway.

        Prepended I am going to follow this up with more detail later - I'm off to work and don't have time to drop anything except the briefest of notes

        Actually... that was the really short and abbreviated answer. I gave only the merest sketch of an outline of where the answer might be. From what you've said it sounds like you should be paying a billing company to handle this for you. You are not equipped to solve this problem given the resource limits you've intimated at. You have no business taking people's credit cards at whatever site this is. Shame on you if you do. This is a good time to familiarize yourself with Abigail's Oath.

        Seeking Green geeks in Minnesota