I'd like to make an encryption in PKCS#7 format using BouncyCastle, by using the org.bouncycastle.cms package.
I need to define the padding and the initial value for encryption, but the classes of cms package don't allow to define this informations,how can i do that?
RFC 5652 Cryptographic Message Syntax (CMS), Section 14, page 54 states:
Implementations must randomly generate content-encryption keys,
message-authentication keys, initialization vectors (IVs), and
padding.
Thus, BouncyCastle implementation follows CMS standard.
Related
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.
I'm trying to encrypt a string in javascript and then decrypt it back in server using c#. I thought of using System.Security.Cryptography.Rijndael on server side and some AES implementation like this or this on client-side.
I don't know much about cryptography, so basically I generate a key and send it to client and encrypt my text with that key and send it back to server.
My problem is that Javascript AES implementations use a key to encrypt a text but c# Rijndael class uses a key and a vector. where does that vector come from?
AES is just a block cipher, which is a cryptographic primitive. Its purpose is to encrypt one single block of data (16 bytes).
Encryption requires a lot more than that. You need a method to encrypt an arbitrary amount of data, and hopefully in a way that doesn't give away any information. To do this, you need to break the amount of data into blocks, pad the last part to a full block, and then somehow encrypt each block in a clever way. Doing that is the responsibility of the encryption mode.
The most trivial mode (electronic cookbook, ECB), just encrypts each block with the same key, but that's horribly dangerous. Other modes require some sort of initialization state, which needs to be random but can be publicly known.
To encrypt and decrypt your data, you must know both the block cipher and the encryption mode, on both sides, and you must find a way to generate the initial state on the encrypting side and to recover it on the decrpyting side to initialize the encoder and the decoder, respectively.
In a nutshell: You need a lot more information about what you're doing!
This isn't perhaps exactly what you are looking for. But I can think that what you actually need to do is implement SSL.
http://en.wikipedia.org/wiki/Secure_Sockets_Layer
This might solve your problem without needing to get involved with coding cryptography.
I am developing a large application and i need encryption when a data is traveling between two machines in different continents. I have never worked on encryption. I want a simple encryption which can be handled in PHP / Ruby / Python without any dependencies.
So i decided to use HMAC SHA1.
$pad=hash_hmac("sha1","The quick brown....","mykey");
This is what i found out after some research on the internet.
How hard it is to decrypt it if someone doesn't know the key? Also, any alternatives to this?
UPDATE - thanks for all the responses. Problem solved.
It's impossible to decrypt it, even if you know the key. HMAC SHA1 is a keyed hash algorithm, not encryption.
A hash is a cryptographic one-way function that always generates a value of the same length (I think SHA1 is 128-bits) regardless of the length of the input. The point of a hash is that, given the output value, it's computationally infeasible to find an input value to produce that output. A keyed hash is used to prevent rainbow table attacks. Even if you know the key you can't reverse the hash process.
For encryption you want to look at AES.
SHA1 is a one-way-hash function, by definition it is not decryptable by anyone. The question becomes if you have a plaintext T that hashes to H. How hard is it to find another T which also hashes to H.
According to Wikipedia, for SHA1, the best known brute force attack would take 2^51 evlautions to find a plain text that matches.
If you need actual encryption where you can reverse the process, you should take a look at AES256.
See:
http://en.wikipedia.org/wiki/Cryptographic_hash_function
For a general discussion on this.
Like Andrew said SHA1 is an hash algorithm and cannot be used for encryption (since you cannot get back the original value). The digest it produce can be used to validate the integrity of the data.
An HMAC is a construct above an hash algorithm that accept a key. However it's not for meant for encryption (again it can't be decrypted) but it allows you to sign the data, i.e. with the same key you'll be able to ensure the data was not tampered with during it's transfer.
Foe encryption you should look at using AES or, if applicable to your application, HTTPS (which will deal with more issues than you want to know about ;-)
SHA-1 , MD-5 are all one way Hashing algorithms.
They just generate a lengthy string. Each and every string when subjected to these functions will yield you a lengthy string which cannot be retained back.
They are far from encryptions.
If you are looking for encryption algorithms , go for AES (Advanced Encryption Standard) , DES (Data Encryption Standard) Algorithms.
As I say, this is a hash, so not an encryption/decryption problem. If you want to implement a straightforward encryption algorithm, I would recommend looking into XOR encryption. If the key is long enough (longer than the message) and your key sharing policy is suitably secure, this is a one time pad; otherwise, it can potentially be broken using statistical analysis.
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.