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.
Related
I am doing an experiment for an essay in computer science and my topic is encryption. I want to compare the file sizes of files encrypted using AES Crypt and Blowfish. I need to calculate the BigO for both of these as a requirement for my essay. I am unsure on how to do this, I would much appreciate it if someone could help me.
I also would like some opinions on justification for this topic, i am looking at which algorithm produces the smallest file sizes and to see if the results are linear. I have some justification such as businesses may want to reduce the use of memory and resources, talk about transmission is faster with smaller files and downloading is faster. Thank you.
Encryption algorithms such as AES and Blowfish by themselves produces one output byte for each input byte so AES and Blowfish produce the same output sizes.
Except: Both are block based algorithms and depending on the encryption mode the input size may need to be padded to a multiple of the block size so the output is that much larger. For AES the block size is 16-bytes and for Blowfish the block size is 8-bytes so the output may be up to one block size larger than the input.
Try some encryption, there are online tools such as Online encrypt tool that support several encryption algorithms. Note: AES is essentially Rijndael-128.
Opinion: There is no justification for this topic, it is well understood and documented, there is essentially no encrypted size reason to choose one over the other. But, Blowfish is not considered as secure as AES so AES should be chosen, even the author of Blowfish states he used AES.
Note: Many CPUs have optimization instructions for AES so AES is in general the best choice.
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.
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.
Imagine I have this:
$cdata = AES_256($data, $pass);
AES_256 implements the AES algorithm.
If I know the content of $cdata and the content of $data and also have
the AES_256() code, can I reverse engineer and find $pass?
Simple answer: NO.
This has been tested, and mentioned in the Wiki link.
A related-key attack can break up to 9
rounds of 256-bit AES. A
chosen-plaintext attack can break 8
rounds of 192- and 256-bit AES, and 7
rounds of 128-bit AES, although the
workload is impractical at 2128 -
2119.
Or put it another way: you have a better chance of being struck by lighting... on the same day you win the Lottery, than breaking it!
This is called a known-plaintext attack. A good cipher like AES should be immune to it, as the others explained.
If $pass is actually a password and not a 256-bit key, you may be in luck.
While it is far from trivial to perform, a brute-force attack against a normal password is much faster than brute-forcing a 256-bit key.
So modify one of the many password-brute-forcing tools, and you have a attack that (depending on the strength of the password) might take weeks to several years - but that is fast compared to 3x10^51 years...
Another quote, from Wikipedia:
AES permits the use of 256-bit keys.
Breaking a symmetric 256-bit key by
brute force requires 2^128 times more
computational power than a 128-bit
key. A device that could check a
billion billion (10^18) AES keys per
second would require about 3 x
10^51 years to exhaust the 256-bit
key space.
Brute forcing when you know the original text might be faster but still, 3 x 10^51 years is a long time. Plus there's the problem of probably not having a device that can check a billion billion (10^18) keys/second.
In short: everything is possible, but this is not feasible in the world we are now living in.
You could brute force it, but it would take a long time. As in decades or even longer. That's the point of encryption algorithms like AES.
AES, like all good crypto algorithms, doesn't rely on security through obscurity.
In other words, there are no "secrets" in the code, so you having the code won't help you particularly.
Known plaintext is a separate issue, which I don't know much about so I'll leave that up to the other answerers.
Of course not - the only approach is brute force.
Do you really think NIST is so stupid as to choose a cipher that is so easily cracked for a new standard?
with the power of super computers the time to crash AES encryption with be dramatically shortened.... I heard...
2x2^256 possible combinations is a lot to bruteforce. But bruteforcing is the only way. It would actually take about 3 decades. AES is the best Encryption possible right now I'd say. But that would only take that much time using a CPU. Because GPU's (Graphic Processing Units) are strictly math based, people have been making programs that only use the GPU to crack math based algorithms much more quickly than a CPU could. In other words AES might not last 3 decades. If only eternity codes were possible. Well looks like dynamic encryption may be the only way people can really hide their information in the near future.
Triple DES or RC4?
I have the choice to employ either one.
As a high level view the following comments on both should be useful.
It is extremely easy to create a protocol based on RC4 (such as WEP) that is of extremely low strength (breakable with commodity hardware in minutes counts as extremely weak).
Triple DES is not great in that its strength comes though excessive cpu effort but it is of considerably greater strength (both theoretically in real world attacks) than RC4 so should be the default choice.
Going somewhat deeper:
In the field of encryption with no well defined target application then the definition of 'best' is inherently hard since the 'fitness' of an algorithm is multi variant.
Ease of implementation
Can you run it on commodity hardware?
Are implementations subject to accidental flaws that significantly reduce security while still allowing 'correctness' of behaviour.
Cost of implementation
Power/silicon/time to encode/decode.
Effort to break
Brute Force resilience. Pretty quantifiable
Resistance to cryptanalysis, less quantifiable, you might think so but perhaps the right person hasn't had a try yet:)
Flexibility
Can you trade off one of the above for another
What's the maximum key size (thus upper limits of the Brute Force)
What sort of input size is required to get decent encryption, does it require salting.
Actually working out the effort to break itself requires a lot of time and effort, which is why you (as a non cryptographer) go with something already done rather than roll your own. It is also subject to change over time, hopefully solely as a result of improvements in the hardware available rather than fundamental flaws in the algorithm being discovered.
The core overriding concern is of course just that, is it secure? It should be noted that many older algorithms previously considered secure are no longer in that category. Some are so effectively broken that their use is simply pointless, you have no security whatsoever simply obscurity (useful but in no way comparable to real security).
Currently neither of the core algorithms of RC4 and TDES is in that category but the naive implementation of RC4 is considered extremely flawed in protocols where the message data can be forced to repeat. RC4 has several more significant theoretical flaws than TDES.
That said TDES is NOT better than RC4 in all the areas listed above. It is significantly more expensive to compute (and that expensiveness is not justified, other less costly crypto systems exist with comparable security to TDES)
Once you have a real world application you normally get one or both of the following:
Constrains on your hardware to do the task
Constraints imposed be the data you are encrypting (this is used to transmit data which needs to be kept secret only for X days... for example)
Then you can state, with tolerances and assumptions, what can achieve this (or if you simply can't) and go with that.
In the absence of any such constraints we can only give you the following:
Ease of implementation
Both have publicly available secure free implementations for almost any architecture and platform available.
RC4 implementations may not be as secure as you think if the message can be forced to repeat (see the WEP issues). Judicious use of salting may reduce this risk but this will NOT have been subject to the rigorous analysis that the raw implementations have been and as such should be viewed with suspision.
Cost of implementation
I have no useful benchmarks for RC4 (it is OLD) http://www.cryptopp.com/benchmarks.html has some useful guides to put TDES in context with RC5 which is slower than RC4 (TDES is at least an order of magnitude slower than RC4) RC4 can encrypt a stream at approximately 7 cycles per byte in a fast implementation on modern x86 processors for comparison.
Effort to break
Brute Force resilience of TDES is currently believed to be high, even in the presence of many encryption outputs.
RC4 brute force resilience is orders of magnitude lower than TDES and further is extremely low in certain modes of operation (failure to discard initial bits of stream)
Resistance to cryptanalysis, There are publicly known flaws for Triple DES but they do not reduce the effectiveness of it to realistic attack in the next decade or two, the same is not true for RC4 where several flaws are known and combined they have produced reliable attacks on several protocols based on it.
Flexibility
TDES has very little flexibility (and your library may not expose them anyway)
RC4 has a lot more flexibility (the key used to initialize it can be arbitrarily long in theory, though the library may limit this.
Based on this and your statement that you must use one or the other you should consider the RC4 implementation only if the CPU cost of TripleDES makes it unrealistic to implement in your environment or the low level of security provided by RC4 is still considerably higher than your requirements specify.
I should also point out that systems exist which are empirically better in all areas than RC4 and TDES.
The eSTREAM project is evaluating various stream cyphers in the order of 5 or less cycles per byte though the cryptanalysis work on them is not really complete.
Many faster, stronger block cyphers exist to compete with TDES. AES is probably the best known, and would be a candidate since it is of comparable (if not better) security but is much faster.
Sorry - triple DES is no longer considered best practices. AES is simply a better algorithm so if you can use it then you should. For an easy implementation, go here.
I strongly suggest that you learn more by reading up on TDES on Wikipedia. The money quote is:
"TDES is slowly disappearing from use,
largely replaced by the Advanced
Encryption Standard (AES)."
RC4 is, honestly, just not an acceptable option for any application where security is important.
Agreed -- DES is largely outdated, so unless there is a good reason to use it, go with AES. If that's not an option, TDES would be the better choice, unless you're dealing with streaming data (ie, data which cannot be broken into blocks), then RC4 is the way to go (out of the given options).
Of course, I feel like I should mention... Cryptography is really, really hard to get right, and even the strongest algorithm can be broken easily if you get something even a little wrong (see, eg, older Kerberos or WEP).
This might not be the most informative answer, but during my 4 year employment term with a very large telco, Triple DES was the encryption standard for all sensitive applications, others were simply not allowed. It was Triple DES or the application does not go live. Hope that helps.
Both are secure, well... enough. RC4 is faster so if that's important to you...
After reading other peoples answers (which are all correct), it's clear that it really depends on your context. There are so many other questions that could influence your decision. If it just needs to be fool proof, if it's not really something sensitive and you have a lot of data and speed is the factor, go for RC4.
Otherwise, if you need something a bit more secure and easier to implement or as you say "tougher to screw up" :) then go for 3DES, which is, as far as I remember, secure enough (!) till 2020-2030, or something like that.
Are those your only two options? If you can use AES (also known as Rijndael) then use it instead. DES is slow, and now considered obsolete (AES is the replacement for it).
RC4 sucks, don't use it. It's a stream cipher but you can use a block cipher instead, just pad the final block of data (Google PKCS#5 padding scheme).
Lately I've only seen DES being used in embedded devices (firmware), because the implementation is simple and it uses very little memory. Even in JavaME you can use AES.
One factor in deciding between 3DES and RC4 is language support. Java doesn't natively support RC4 and you would need to grab an open source library such as BouncyCastle to implement. MS doesn't have this same challenge.