leocharre has asked for the wisdom of the Perl Monks concerning the following question:

I have a web app transmitting info via ssl.
This app allows the server to receive client requests to meddle with local files.

The server encrypts "references" (used in the vaguest sense here) to files the client is allowed to meddle with, sends it to them (the list of options, files they can select).

The server receives a selected reference, decrypts it, checks that the user is allowed to screw with it and how much, and proceeds.

I am using Crypt::Lite to encrypt the references and other data, with a randomly generated key (per session).

What I am finding is.. For 500 references, this can take 1.4 seconds.

I compared making the key (the encrypt string) eight chars, four chars, one char.. and it seems to make little difference in expense.

Anybody suggest something faster then Crypt::Lite? Should I use something more mediocre? Maybe even make a half-@zed encryption method myself- since this is already in ssl and they key is random every session.. and.. the reference is checked once decrypted... ??

update: (not sure about this.. but it's deff looking like crypt lite is a bull )

small string, (38 chars)
100 trials of Crypt::Lite::encrypt (186.422ms total), 1.864ms/trial
100 trials of Crypt::Lite::decrypt (191.886ms total), 1.919ms/trial
100 trials of Crypt::CBC::encrypt_Camellia (122.917ms total), 1.229ms/trial
100 trials of Crypt::CBC::decrypt_Camellia (16.598ms total), 165us/trial
100 trials of Crypt::CBC::encrypt_Blowfish (138.889ms total), 1.389ms/trial
100 trials of Crypt::CBC::decrypt_Blowfish (31.868ms total), 318us/trial
100 trials of Crypt::CBC::encrypt_CAST5 (121.867ms total), 1.219ms/trial
100 trials of Crypt::CBC::decrypt_CAST5 (14.445ms total), 144us/trial
100 trials of Crypt::CBC::encrypt_IDEA (122.123ms total), 1.221ms/trial
100 trials of Crypt::CBC::decrypt_IDEA (15.692ms total), 156us/trial
100 trials of Crypt::CBC::encrypt_DES (121.836ms total), 1.218ms/trial
100 trials of Crypt::CBC::decrypt_DES (15.422ms total), 154us/trial
100 trials of Crypt::CBC::encrypt_Rijndael (123.684ms total), 1.237ms/trial
100 trials of Crypt::CBC::decrypt_Rijndael (15.554ms total), 155us/trial
100 trials of Crypt::CBC::encrypt_DES_EDE3 (131.234ms total), 1.312ms/trial
100 trials of Crypt::CBC::decrypt_DES_EDE3 (24.392ms total), 243us/trial

large string, (6490 chars)
100 trials of Crypt::Lite::encrypt (21.259s total), 212.592ms/trial
100 trials of Crypt::Lite::decrypt (22.283s total), 222.829ms/trial
100 trials of Crypt::CBC::encrypt_Camellia (461.235ms total), 4.612ms/trial
100 trials of Crypt::CBC::decrypt_Camellia (371.517ms total), 3.715ms/trial
100 trials of Crypt::CBC::encrypt_Blowfish (668.723ms total), 6.687ms/trial
100 trials of Crypt::CBC::decrypt_Blowfish (611.216ms total), 6.112ms/trial
100 trials of Crypt::CBC::encrypt_CAST5 (723.785ms total), 7.238ms/trial
100 trials of Crypt::CBC::decrypt_CAST5 (622.947ms total), 6.229ms/trial
100 trials of Crypt::CBC::encrypt_IDEA (679.809ms total), 6.798ms/trial
100 trials of Crypt::CBC::decrypt_IDEA (634.063ms total), 6.341ms/trial
100 trials of Crypt::CBC::encrypt_DES (666.129ms total), 6.661ms/trial
100 trials of Crypt::CBC::decrypt_DES (607.540ms total), 6.075ms/trial
100 trials of Crypt::CBC::encrypt_Rijndael (460.238ms total), 4.602ms/trial
100 trials of Crypt::CBC::decrypt_Rijndael (370.174ms total), 3.702ms/trial
100 trials of Crypt::CBC::encrypt_DES_EDE3 (1.497s total), 14.972ms/trial
100 trials of Crypt::CBC::decrypt_DES_EDE3 (1.425s total), 14.251ms/trial


Replies are listed 'Best First'.
Re: Anything faster then Crypt::Lite?
by samtregar (Abbot) on Jul 27, 2006 at 17:21 UTC
    I bet Crypt::Blowfish is faster and I'm pretty sure it'll be more secure too. Crypt::Lite is doing its work in Perl, which seems pretty foolish to me - C is obviously a better tool for this kind of number-crunching.

    Why not give it a try? Put together a benchmark with Benchmark and try out a few alternatives.

    -sam

      Crypt::Blowfish shouldn't be used directly (since it can only encode an 8 byte string, no more no less). It should be used via Crypt::CBC (which handles padding, and uses chaining for a more secure result than encrpyting every 8 bytes chunk with the same key).
      use Crypt::CBC (); my $cipher = Crypt::CBC->new( -key => ..., -cipher => 'Blowfish', ); my $plaintext = 'This data is hush hush'; my $ciphertext = $cipher->encrypt($plaintext);
      use Crypt::CBC (); my $cipher = Crypt::CBC->new( -key => ..., -cipher => 'Blowfish', ); my $ciphertext = ...; my $plaintext = $cipher->decrypt($ciphertext);

      Sam, I'm actually using Benchmark::Timer to get some numbers on these things. Super helpful, quick to implement.

      ( And I'm using HTML::Template.. which is probably one of the most useful modules I've ever tried out. Whomever designed that has my hummility ;-) - I'm thinking to use it more and more. )

Re: Anything faster then Crypt::Lite?
by CountZero (Bishop) on Jul 27, 2006 at 21:01 UTC
    Maybe a stupid question, but if you already use SSL why do you need the additional encryption of Crypt::*?

    CountZero

    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

      Because you can never trust any data coming from "the client". SSL enables that the data between that computer and the server cannot be intercepted and seen by the inbetween points.Great.

      But once logged in, it means that the person in there has used a valid username and password combo (and passed a captcha test ). It means that a human being can act through the rights of user entity x.

      Example:

      User entity x has rights to physical rights on server to file x/y...
      What if the client data received is a request for file f/y ?

      Let's quickly go over how the server offers the client what files they can act upon...

      we will be offering files x/y x/x ..

      • A human logs in as user x, we look up that they can meddle with files x/y and x/x.
      • we encrypt what those choices are. make the 'page', send it to client
      • They select x/y, server receives selection request
      • server decrypts say.. 2387q23895yqguhaejghaerhg to x/y and we verify this really is a valid file request.
      • we lookup that user x really has this right over file x/y
      • now we check the request for stupidity (rename, move, download, whatever) and we are go.

      What if you're a malicious valid user? If you sent the server a request for file y/xx, then we would negate you based on the fact that you don't have rights over file y/xx. But with encryption of the files requested, you can't even ask for file y/xx, because you don't know how to encode the request for file y/xx
      It is likely that my code will have holes somewhere. But encryption is encryption.

      I am freaking paranoid. The data being secured and used is sensitive in nature. I know it's not a valid user sipping tea and petting her kitty while she looks at her files. I know it's really Satan 666. Don't you know that? Obviously you didn't. So..
      Satan (666) just logged in as a valid user. Do you want the selections encrypted? I do.

Re: Anything faster then Crypt::Lite?
by Anonymous Monk on Jul 28, 2006 at 05:54 UTC
    Is Crypt::Lite a joke? It seems to be simple-XOR implemented in the stupidest way possible.
    substr($a, $j, 1) += substr($b, $i, 1); substr($a, $j, 1) = 0 if substr($a, $j, 1) == 2;
    Also, it looks like the secret key is stored in the encrypted message as a message integrity check. Absolutely stunning.

    Verdict: DO NOT USE THIS MODULE. You would be better off with no encryption at all, because that way at least you won't have a false sense of security.

Re: Anything faster then Crypt::Lite?
by gellyfish (Monsignor) on Jul 28, 2006 at 14:13 UTC

    I'd recommend reading the reviews of Crypt::Lite before using it in any sensitive application.

    /J\

      Thanks gellyfish.

      I stopped using it. I'm now using Crypt::CBC defaulted to DES until something better comes up. It's really improved my performance.. by like 40%!