Hi I am working on an application which communicate with devices,sensors etc. In the application end we are using Java. But in device end it may be varied(ruby,python,embedded c etc).So I am searching which encryption and decryption algorithm supports by various programming language. Is there any algorithm like that, if it is kindly suggest that.
The most commonly supported are AES (for symmetric encryption) and RSA (for public key encryption).
There are variants of each of these, though, in terms of padding, block mode, and so on, so you will still need to be careful to make sure you end up with something compatible.
Related
I am pondering creating a hash function (like md5 or sha1) using the RSA crypto algorithm. I am wondering if there are any obvious reasons that this algorithm wouldn't work:
Generate RSA public/private keys.
Discard private key, never store it at all.
Begin with a hash with a length of the block size for the RSA encryption.
Encrypt message using public key, one block at a time.
For each encrypted block of the message, accumulate it to the hash using a specified algorithm (probably a combination of +, xor, etc.)
To verify a message has the same hash as a stored hash, use the saved public key and repeat the process.
Is this possible, secure, and practical?
Thanks for any comments.
RSA encryption is not deterministic: if you follow the RSA standard, you will see that some random bytes are injected. Therefore, if you encrypt with RSA the same message twice, chances are that you will not get twice the same output.
Also, your "unspecified step 5" is likely to be weak. For instance, if you define a way to hash a block, and then just XOR the blocks together, then A||B and B||A (for block-sized values A and B) will hash to the same value; that's collision bonanza.
Academically, building hash functions out of number-theoretic structures (i.e. not a raw RSA, but reusing the same kind of mathematical element) has been tried; see this presentation from Lars Knudsen for some details. Similarly, the ECOH hash function was submitted for the SHA-3 competition, using elliptic curves at its core (but it was "broken"). The underlying hope is that hash function security could somehow be linked to the underlying number-theoretic hard problem, thus providing provable security. However, in practice, such hash functions are either slow, weak, or both.
There are already hashes that do essentially this, except perhaps not with the RSA algorithm in particular. They're called cryptographic hashes, and their salient point is that they're cryptographically secure - meaning that the same strength and security-oriented thought that goes into public key cryptographic functions has gone into them as well.
The only difference is, they've been designed from the ground-up as hashes, so they also meet the individual requirements of hash functions, which can be considered as additional strong points that cryptographic functions need not have.
Moreover, there are factors which are completely at odds between the two, for instance, you want hash functions to be as fast as possible without compromising security whereas being slow is oftentimes seen as a feature of cryptographic functions as it limits brute force attacks considerably.
SHA-512 is a great cryptographic hash and probably worthy of your attention. Whirlpool, Tiger, and RipeMD are also excellent choices. You can't go wrong with any of these.
One more thing: if you actually want it to be slow, then you definitely DON'T want a hash function and are going about this completely wrong. If, as I'm assuming, what you want is a very, very secure hash function, then like I said, there are numerous options out there better suited than your example, while being just as or even more cryptographically secure.
BTW, I'm not absolutely convinced that there is no weakness with your mixing algorithm. While the output of each RSA block is intended to already be uniform with high avalanching, etc, etc, etc, I remain concerned that this could pose a problem for chosen plaintext or comparative analysis of similar messages.
Typically, it is best to use an algorithm that is publicly available and has gone through a review process. Even though there might be known weaknesses with such algorithms, that is probably better than the unknown weaknesses in a home-grown algorithm. Note that I'm not saying the proposed algorithm has flaws; it's just that even if a large number of answers are given here saying that it seems good, it doesn't guarantee that it doesn't. Of course, the same thing can be said about algorithms such as MD5, SHA, etc. But at least with those, a large number of people have put them through a rigorous analysis.
Aside from the previous "boilerplate" warnings against designing one's own cryptographic functions, it seems the proposed solution might be somewhat expensive in terms of processing time. RSA encryption on a large document could be prohibitive.
Without thinking too much about it, it seems like that would be cryptographically secure.
However, you'd have to be careful of chosen plaintext attacks, and if your input is large you may run into speed issues (as asymmetric crypto is significantly slower than cryptographic hashes).
So, in short: yes, this seems like it could be possible and secure… But unless there is a really compelling reason, I would use a standard HMAC if you want a keyed hash.
As mentioned above step 4.) is to be done deterministic, i.e. with modulus and public key exponent, only.
If the hash in step 3.) is private, the concept appears secure to me.
Concerning Step 5.): In known CBC mode of kernel algorithms the mix with previous result is done before encryption, Step 4.), might be better for avoiding collusions, e.g. with a lazy hash; XOR is fine.
Will apply this, as available implementations of known hash functions might have backdoors :)
Deterministic Java RSA is here.
EDIT
Also one should mention, that RSA is scalable without any limits. Such hash function can immediately serve as Mask Generation Function.
Is there a better algorithm than AES-256 ?
AES is an industry standard symmetric algorithm. But theoretically its told to have flaws. Is there any symmetric algorithm (needn't be a standard), that's highly praised for its security? I'm collecting information on algorithms in-order to make a wallet to store some text for a specific device.
I read that Blum Blum Shub is a notable pseudo random generator algorithm, mainly used in cryptography rather than simulation. Here my focus is cryptography. So is it the best PRNG out there or is there any better one? I wanted to implement it for an ARM A8 Core CPU architecture in ARM assembly just from learning the asm, the architecture, and those algorithms in depth.
Does (or is it possible) using a gpu for encryption/decryption any better? My device in interest is N900 tablet (to learn more about the hardware and software).
It is true that AES is not the best and newest security algorithm but it may be the one with the ARM8 because it is part of the supply contract and may not be replaceable - it could be for compliance with FIPS standards in the US or the method the country or province of intended use has specified. You could do simple manipulate or substitute of text or numeric data yourself before sending it to AES and remember to write the code for the reverse process so you can reconstruct the data correctly and write, display or print it out.
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.