This package worthless. The author falsely claims that multiple encryption increases security: that's snake oil.
It seems to be throwing in data generated by rand(). Not very secure at all.
Installation of other crypto packages with complex dependencies is a false reason for promoting this package: it's eas yto install many of them, even on a Windows machine with no compiler.
Whether other packages have more complicated interfaces is no reason to provide a simple interface with a junk algorithm.
This module really does nothing else but XOR-ing the plaintext with the key. The key is repeated if the message is longer than the key, which means the encryption can be broken if the message is long enough. The module even helpfully adds a (partially known) string to the message. Creating a good encryption method is a task for specialists; judging from his reply to the previous review, the author probably isn't one, and judging from his module, he certainly isn't. DON'T USE.
As emphasised on CPANs documentation, Crypt::Lite is *not* designed to act as a competitor for the strong algorithms like Rijndael or Blowfish where Rijndael has been elected as the Advanced Encryption Standard (AES) by NIST (See csrc.nist.gov/CryptoToolkit/aes/aesfa....
That user opinion cited Bruce Schneier "...won't stop a cryptanalyst for more than a few minutes.". Well that's true (and well-known) for trivial XOR encryption. Although I think the "few minutes" is a very imprecise conlusion since some certain requirements had to be met; I recommend Simon Singh's "Geheime Botschaften", ISBN: 3-423-33071-6 as a good reading on that matter (also available in English).
[ The documentation suggests using "double or tripple-encryption
with any data to increase the security." However, multiply
encrypting with XOR cannot possibly increase security -- it's the
same as XORing once with the XOR of the two keys used. ]
Wrong for Crypt::Lite.
I'd assume it is pretty challenging to decrypt, even for a crypto analyst and it would take weeks to make the first guesses. In the case the crypto analyst knows it's a German or English sentence, and not "any string".
Again, Crypt::Lite has many other useful purposes than to be a competitor for AES algorithms but in my humble opinion, it should be safe enough, even for sending encrypted passwords over the net.
[ Amazingly, the secret key is included as part of every encrypted
message. That can't be a good idea. ]
The usage of the secret string has a specific intentation. This part of the procedure is beeing improved as o releae 0.82.08.
[ Due to an apparent implementation bug, Crypt::Lite throws away
7/8ths of the secret key. ]
I don't understand the issue.
I never noticed such a problem.
DO NOT USE. This is a poor implementation of Simple XOR encryption. To quote Bruce Schneier from Applied Cryptography, "An XOR might keep your kid sister from reading your files, but it won't stop a cryptanalyst for more than a few minutes."
The documentation suggests using "double or tripple-encryption with any data to increase the security." However, multiply encrypting with XOR cannot possibly increase security -- it's the same as XORing once with the XOR of the two keys used.
Due to an apparent implementation bug, Crypt::Lite throws away 7/8ths of the secret key.
Amazingly, the secret key is included as part of every encrypted message. That can't be a good idea.
The module also can't tolerate tabs in the plaintext or secret key strings.
1 hidden unhelpful review