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.
Related
I am doing an extended essay in computer science and i am stuck on what to do. I am interested in the topic of the AES algorithm or any encryption algorithms. However as computer science is a science subject i must conduct an experiment. However i am unsure as to how i should test it.
I thought about encrypting different types of files eg. videos, photos and word files ect, and testing the data transmission speeds or encryption speeds compared to other encryption algorithms. I wondered if any of you could tell me how to do this or recommend a different experiment. It cannot be too difficult that i cannot do nor too easy that it is not worthy of a good grade. Thanks. P.S. I a 17 (Year 12)
Certainly there is a wealth of opportunity for research here. Good for you for being curious about this and looking into it. You will likely want to control for a few variables and test along the following lines:
symmetric vs. asymmetric encryption (i.e. AES vs. RSA)
different symmetric algorithms (i.e. Rijndael (current AES algorithm) vs. Blowfish, DES, TDES, etc.)
different block cipher modes of operation (i.e. CTR vs. CBC vs. GCM, etc.)
different data sizes (i.e. does it scale linearly? Does it take exactly 1000x as long to encrypt 16 bytes vs. 16_000 vs. 16_000_000?)
You'll want to run these experiments on the same hardware, under the same load, in the same language, many times in order to get decent data. Especially considering that modern CPUs have the AES-NI instruction set, and custom registers for encryption data, remember to seed your experiments, or subsequent runs could have different performance profiles.
If you do not have previous coding experience, Java, Ruby, and Python all have very popular cryptography libraries and a broad community which is happy to support you if/when you run into challenges. If you're already familiar with one or more specific languages, I'd suggest using one of those, as it will be tricky enough to learn the cryptographic-specific instructions; learning a new language is probably an unnecessary burden to add on at this time.
I think this is sufficiently vague that you will still have to do the research and investigation for your paper, but should provide a starting point. Feel free to follow up with specific questions if you need.
I'm trying to implement AES. I currently have implemented subByte(), shiftRow(), mixColumn(), addRoundkey() and generation roundkey of 8-bit AES, and that is working. But its performance is not good. So I want to implement 32-bit AES in software, but generating the extended s-box is confusing me. How does data entering as 8-bit come out as 32-bit? I can't find a 32-bit implementation of AES in software.
I suggest implementing it in a bit sliced manner. Bit sliced implementations do not only scale very well, they have also very good properties regarding timing attacks. I know this requires a redesign of your functions. And a performance gain can only be archived if you calculate multiple AES operations in parallel.
The fastest AES implementation (without Intel AES instructions) is bit sliced:
http://eprint.iacr.org/2009/129
With Google you will also find the source code.
I'm currently investigating the use of curve25519 for signing. Original distribution and a C implementation (and a second C implementation).
Bernstein suggests to use ECDSA for this but I could not find any code.
ECDSA is specified by ANSI X9.62. That standard defines the kind of curves on which ECDSA is defined, including details curve equations, key representations and so on. These do not match Curve25519: part of the optimizations which make Curve25519 faster than standard curves of the same size rely on the special curve equation, which does not enter in X9.62 formalism. Correspondingly, there cannot be any implementation of ECDSA which both conforms to ANSI X9.62, and uses Curve25519. In practice, I know of no implementation of an ECDSA-like algorithm on Curve25519.
To be brief, you are on your own. You may want to implement ECDSA over the Curve25519 implementation by following X9.62 (there a draft from 1998 which can be downloaded from several places, e.g. there, or you can spend a hundred bucks and get the genuine 2005 version from Techstreet). But be warned that you are walking outside of the carefully trodden paths of analyzed cryptography; in other words I explicitly deny any kind of guarantee on how secure that kind-of-ECDSA would be.
My advice would be to stick to standard curves (such as NIST P-256). Note that while Curve25519 is faster than most curves of the same size, smaller standard curves will be faster, and yet provide adequate security for most purposes. NIST P-192, for instance, provides "96-bit security", somewhat similar to 1536-bit RSA. Also, standard curves already provide performance on the order of several thousands signature per second on a small PC, and I have trouble imagining a scenario where more performance is needed.
To use Curve25519 for this, you'd have to implement a lot of functions that AFAIK aren't currently implemented anywhere for this curve, which would mean getting very substantially into the mathematics of elliptic curve cryptography. The reason is that the existing functions throw away the "y" coordinate of the point and work only with the "x" coordinate. Without the "y" coordinate, the points P and -P look the same. That's fine for ECDH which Curve25519 is designed for, because |x(yG)| = |x(-yG)|. But for ECDSA you need to calculate aG + bP, and |aG + bP| does not in general equal |aG - bP|. I've looked into what would be involved in extending curve25519-donna to support such calculations; it's doable, but far from trivial.
Since what you need most of all is fast verification, I recommend Bernstein's Rabin-Williams scheme.
I recently shared the curve25519 library that I developed awhile back. It is hosted at https://github.com/msotoodeh and provides more functionality, higher security as well as higher performance than any other portable-C library I have tested with. It outperforms curve25519-donna by a factor of almost 2 on 64-bit platforms and a factor of almost 4 on 32-bit targets.
Today, many years after this question was asked, the correct answer is the signature scheme Ed25519.
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.
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.