In the answers in this question I found a reply: TurboPower LockBox 3: AES128 and padding ISO 10126
(2) For most chaining modes, TPLB3 will automatically add salt. This is normally a good thing, but if you need it without, you can remove the option for it.
How can I do that? Namely I need encryption which has the same cipher text length as the plain text length.
Assuming that you are not using ECB, the simplest way would be to remove the first 8 bytes of the ciphertext. The first 8 bytes (64 bits) is the salt nonce. It is also the low 64 bits of the IV. The high 64 bits of the IV are zero.
Please note: Not salting your messages is very bad practice and a security weakness. (Refer to wikipedia for more information). You say you need encryption which has the same ciphertext length as the plaintext length. This is basically saying, you want weak encryption. It's up to you, but my advice is the think about your requirements very carefully before proceeding.
An alternative technique would be to create your own chaining mode and register it in the cryptographic library. For example, if you wanted CBC without salt, create a class descendant from TCBC (unit TPLB3.CBC) and just override the ChainingFeatures() function to add the cfNoNounce feature. Refer to in-line comments in unit TPLB3.BlockCipher. However, my recommendation is the first method.
You might also like to read answers to related questions:
AES Encrypt/Decrypt Delphi & PHP
TPLockBox3 and PHP - AES Encrypt in Delphi, Decrypt in PHP
Turbopower Lockbox3 - Can I control initialization vector and padding for AES-256 encryption?
Also note that if you are using ECB chaining mode, there is no salt, was this mode has the cfNoNounce feature automatically. (ECB is bad. Don't use it, except for testing purposes).
Footnote:
I am the main author of TPLockBox 3, and I maintain the version of the library at:
http://tplockbox.googlecode.com/
http://lockbox.seanbdurkin.id.au/HomePage
I assume that you are using that version, and not the SourceForge one. I am expecting to release version 3.6.0 on 7-Nov-2014.
Related
Could someone explain a couple of scenarios where the system design can justify the use of an encryption solution, respectively, as 3DES and Blowfish?
I'll add a few, one related to the backwards compatability: if you have a hardware implementation that only does 3DES (many older smartcards) then 3DES could be preferred over AES. Hardware accelerators can be used for both speedups and security (side channel attacks, see below).
3DES implementations may be less vulnerable to side channel attacks (although it certainly is not immune from it). AES is harder to get right - as I've come to understand - because of it's internal design (table accesses). AES better algo, bigger blocksize or key size does not mean much when confronted with a good side channel attack.
3DES has a 8 byte blocksize compared with 16 bytes for AES which can lead to a bit more overhead when using it in block mode encryption. Of course, this one can be mitigated by using a stream mode cipher, and we're only talking about a few bytes for the last block. This is an extremely thin argument for this reason.
I'll be a bit shorter on Blowfish: variable key size and sometimes faster than AES, less likely to be implemented in hardware, but backwards compatibility may be reasons, and the 8 byte blocksize again.
None of the three reasons above is generally enough to choose 3DES or Blowfish over AES of course.
Just one: backward compatibility with existing data or services/API that requires them.
Otherwise keep it simple and just use AES :-)
Note that people often suggest that using older algorithms gets better performance (not a very good tradeoff IMHO) but that's generally not the case (you'll need to test it against the library you use) and AES ends up way faster (at least from 3DES).
what about replacing the key addition subroutine with 3DES so that each block of the four blocks of eight characters get encrypted and including Blowfish F() inside the DES function F() i.e before the 32 bits is returned by the DES F(), I am actually using this idea to create a number generator to try and crack the lottery and to date have won £106.40, would love to upload the code but there is no way to do it here anyway.
I heard some time that encryption and cipher are not the same thing, if so, what's the difference?
a cipher is a method (algorithm) used for encryption of some text. But english speakers have that habit of making verbs from nouns... hence ciphering became a synonym of encrypting.
Now, the fun part. If you consider decrypt and decipher, now they have different meanings.
decrypt means applying the decryption key to some code
decipher means finding the meaning of some text that was not deliberately encrypted.
In France (I'm french) we also have funny confusion with similar words. We have "chiffrer" (very similar to "cipher") that is the correct word and means encrypt, but we also use the verb "crypter" that means the same thing but is considered as an anglicism (verb built from english "crypted"). When we go for the opposite words "décrypter" and "dechiffrer" we also have different meanings but not like the english ones... "déchiffrer" means the same that both english words decrypt and decipher depending on the case, but "décrypter" is used when you try to get the clear text without the code (it means breaking the code). I believe there is no english word that means that.
Looking at my answer, I wonder if things were not clearer before it.... natural language is definitely some kind of encryption.
You might take a look at this article on the difference between Encryption and Cryptography. It also addresses the definition of cipher in the process.
Excerpts:
What is Cryptography?
In simple terms, cryptography is the science concerned with the study of secret communication.
What is Encryption?
...
... "encryption" basically is some process or algorithm (known as a cipher) to make information hidden or secret. And to make that process useful, you need some code (or key) to make information accessible.
A cipher is an algorithm of encryption. Ex. substitution cipher, permutation cipher, etc.
Encryption is just the process of obfuscating information.
So in a simplistic sense of the idea, you use a cipher to encrypt stuff. :)
The iPhone supports the following encryption algorithms
enum {
kCCAlgorithmAES128 = 0,
kCCAlgorithmDES,
kCCAlgorithm3DES,
kCCAlgorithmCAST,
kCCAlgorithmRC4,
kCCAlgorithmRC2
};
I want to use only symmetric algorithm since asymmetric encryptions requires more computation overhead.
So I want to know which of the ones listed is the best algorithm and also what is the key-length in order to avoid excessive computation overhead.
Key length
Bruce Schneier wrote back in 1999:
Longer key lengths are better, but
only up to a point. AES will have
128-bit, 192-bit, and 256-bit key
lengths. This is far longer than
needed for the foreseeable future. In
fact, we cannot even imagine a world
where 256-bit brute force searches are
possible. It requires some fundamental
breakthroughs in physics and our
understanding of the universe. For
public-key cryptography, 2048-bit keys
have same sort of property; longer is
meaningless.
Block ciphers
AES
It's the current standard encryption algorithm. It's considered to be safe by most people. That's what you should be using if you haven't got a very deep knowledge in cryptography.
DES
DES is the predecessor of AES and is considered broken because of its short key length.
3DES
Is a variation of DES with a longer key length. It's still in use but there are some known attacks. Still it's not yet broken.
RC2
It's considered to be weak.
Stream ciphers
RC4
It has some known vulnerabilities but is still used today, for example in SSL. I recommend not to use it in new products.
Conclusion
Use either RC4 or AES, depending if you need a stream or a block cipher.
Of those algorithms you list, I believe RC4 is the fastest. In addition, the speed of RC4 does not depend on the key length once it has been initialized. So you should be able to use the maximum key size for that one without worrying about runtime cost.
RC4 is probably the fastest, but it has some security issues.
If security is an important factor, I would recommend going for AES128. AES is the standard solution and on the top of excellent security you might expect the implementations to get faster over time as people are still actively working on them. Maybe future CPUs will also include support for it, just like new Intel desktop processors will.
Is there any ways to try to guess encryption algorithm used to encrypt the ciphertext?
Yes. There are some differences:
Is it a block cipher or not can be guessed from the length.
Block length
Entropy of the output (are all characters equally present? / can patterns be found?)
Recurrences (CBC or not...)
The entropy of the string is probably the best hint. A simple method to determine it is probably trying to compress it. Some methods can be found here: http://www.random.org/statistics/ They use them to make sure their numbers are as random as possible.
I've got no idea if it's really possible to determine the encryption using these methods.
Tools to see it:
PEiD with the Krypto Analyzer (KANAL) plugin
IDA Pro with the Findcrypt plugin
OllyDbg with the SnD Crypto Scanner
x3chun's Crypto Searcher
Keygener Assistant
Hash & Crypto Detector (HCD)
Draft Crypto Analyzer (DRACA)
but all to executables.
found here : http://fwhacking.blogspot.com.br/2011/03/bfcrypt-crypto-scanner.html
Quite often this information is readily available - in a good encryption scheme, only the key needs to be secret, not the algorithm used.
There are analyses you can can perform to test for particular encryptions, consult a textbook on cryptanalysis for details!
You can try fbcrypt which will scan for known hash & crypto signatures: http://fwhacking.blogspot.com/2011/03/bfcrypt-crypto-scanner.html
For now it supports MD5, CRC32, Blowfish, DES and SHA256, but more will be added soon. Anyway as the source is available you can also add your own.
It depends if you're talking about "raw encrypted data" (in that case you can use methods such as listed by "gs" in the other answer) or an encrypted file in some standard format (the most common are CMS/PKCS#7 and OpenPGP); in the latter case the encryption algorithm is explicitly indicated in the metadata contained in the very file.
For CMS you need an ASN.1 decoder such as command-line dumpasn1 program or my own web-based Javascript decoder while for OpenPGP you can use pgpdump.
How to write a BlackBerry program for AES/CBC with Initialization Parameter ecncryption and Decryption
and this encryption and decryption should work independent on Programming language
Ex= If I encrypt some data using BlackBery I must be able to decrypt the same data using Java Program.
Thanks
Deepak
The decryption half of your question is answered here: decrypting data with AES/CBC/PKCS5Padding using blackberry
It should be easy to figure out encryption using the same pattern (use Encryptor instead of Decryptor engines, etc).
Have you read this KB article? http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800332/800779/How_to_-_Use_Basic_Encryption.html?nodeid=800640&vernum=0
You will also need to use net.rim.device.api.crypto.CBCEncryptorEngine on top of the AESEncryptorEngine (and similar for decryption).
CBCEngine allows you upto 16 bytes for across platform. so donot use CBC. try to use the default supported cipher engine.
I think ECB will be great if you use.
Thanks
Sunil Kumar sahoo
Actually, you write your own code for AES algorithm and CBC mode, it is quite simple, around some hundreds of code lines. And, there should be reference implementation in Java language.