TechGenix and SolarWinds have partnered to provide a fully-functional, free 21-day trial version of SolarWinds ipMonitor, the WindowsNetworking.com Readers' Choice Award Winner for monitoring applications, servers, and network devices to all visitors who join Security Forums. Sign up to Security Forums and get your copy today! Existing members can pick up a copy from the Members Area.
| View previous topic :: View next topic |
| Author |
Message |
sim0n
Forum Addict
Joined: 10 Jul 2003
Posts: 432
|
 Posted: Thu Jul 10, 2003 7:20 pm Post subject: Twofish, Blowfish, or 3DES Analysis and Review |
 |
|
 Anyone know anything specific about the quality of the twofish algorithm compared to the older and supposedly more reliable ones such as blowfish, 3des, and idea? I've heard that the Rijndael algorithm can be compromised significantly. What's your take on these subjects? Your opinion would be much appreciated.
ty 
Last edited by sim0n on Mon Jan 26, 2004 8:14 am; edited 1 time in total |
|
| Back to top |
|
 |
JustinT
Trusted SF Member
Joined: 17 Apr 2003
Posts: 1227
Location: Charlotte, NC, US / Uberlāndia, MG, Brazil
|
| Posted: Thu Jul 10, 2003 8:39 pm Post subject: Re: Twofish, Blowfish, or 3DES |
|
|
| sim0n wrote: |
Anyone know anything specific about the quality of the twofish algorithm compared to the older, and suppossedly more reliable ones such as blowfish, 3des and idea? I've heard that the Rijndael algorithm can be compromised significantly. What's your take on these subjects? Your opinion would be much appreciated.
ty |
Twofish:
Alright, I'll start with Twofish. Twofish, as you may
already know, is a 128-bit Feistel Network. It's nearly the
same speed as Rijndael, but holds a much higher security
margin. The current best attack on Twofish compromises
8 of the 16 rounds, but that still doesn't deter the algorithm
from retaining its level of security, which is quite sufficient.
Of all the AES finalist candidates, I view this algorithm as
the best, alongside Serpent.
Serpent:
Next, I'll bring up Serpent. This algorithm, in my
opinion, is a much more security-conservative, and better,
choice, as opposed to Rijndael, even though the two are
similar in structure. Ringing in with 32 rounds, it's the most
robust algorithm I've reviewed, in juxtaposition with the other
AES candidates. The best of attacks, thus far as I know, only
cover 10 of the 32 full rounds. The only drawback is its lack
of speed. This is where Rijndael steps in, with its speed and
algebraic simplicity, to reign in the overall efficiency category.
However, had Serpent been as fast as Rijndael, it would be the
current AES, I strongly feel. Again, along with Twofish, I
recommend this algorithm over Rijndael.
Rijndael:
Rijndael is also a 128-bit cipher, although, it is not a
Feistel Network, as Twofish. The primary reasons it was
chosen were based on its speed, efficiency in implementation,
simple algebraic structure, and rather stout resilience to
analysis, at the time before and around induction as AES.
It's not necessarily a bad choice, by any means, as it was
designed by two of the most respected cryptographers in
the world, Rijmen and Daemen. It's just a new cipher,
which lacks the analysis of algorithms such as DES/Triple-DES,
FEAL, or IDEA. The same goes for all AES candidates,
although, some have proven better than others, overall, in
many aspects.
Compromising Rijndael?:
As far as compromising Rijndael, this isn't an imminent
threat, at all. It stems from the relatively new breed of
XSL/XL/FXL, as well as other algebraic, attacks. A recent
paper, proposed by Courtois and Pieprzyk, shows an
interesting way in which to consider the structure of Rijndael.
Their analysis shows that Rijndael can be displayed as a
system of multivariate quadratic equations. Let's suppose
we want to recover a secret key from a 128-bit variant of
Rijndael. This problem can be written as a large system
of 8000 quadratic equations, accompanied by 1600 binary
unknowns. The solution, of which none exists at this point,
is to find an algorithm suitable for exhausting these
equations. So, in part, all the major proposed "breaks" on
Rijndael are highly theoretical, and not thought to be
practical, or even possible, by some, in terms of breaking
the full Rijndael algorithm.
These 3 algorithms I've just mentioned can be classed
together, since they are all 128-bit block ciphers. Now,
we'll move on to the 64-bit class.
Blowfish:
Blowfish, another fine spawn of Schneier's cryptographic
genius, is a 64-bit Feistel Network, of which has seen more
widespread use than most new block ciphers. It's lightweight,
fast, simple, and secure. Enough said, really, as in my opinion,
Blowfish is the best 64-bit block cipher, to date.
IDEA:
IDEA, another 64-bit block cipher, was heavily analyzed and
considered to be one of the most secure block ciphers during
its tenure. Although it is still relatively secure, it is illogical to
recommend its use, as there are much better ciphers available,
which are also much faster, and not to mention, hold a higher
security margin. Besides, it is patented, so that, in itself, is a
cryptographic con.
DES:
Otherwise known as DEA, this time-evolved algorithm has
withstood cryptanalysis and deemed itself as the most widely
used algorithm available. Because of its 56-bit key length,
as adopted by the standard, it is not wise to use this algorithm
in terms of the practicality of being susceptible to a key
exhaust, or brute force. However, in terms of the security
of the algorithm's structure, it is stout and sufficient, overall.
As a standard, it was a good choice. It's structure is respectable,
but its key length makes it practically insecure. It's lacking a
bit in the speed department, as well. So, go with Blowfish,
instead, if speed and security is of the essence.
Now, on to the final algorithm in question, which exhibits
the trait of multiple encryption.
Triple-DES:
Last, but not least, we move on to Triple-DES. The
cream of the crop. The mack daddy of legacy algorithms.
The algorithm that put crypt in ography. As this algorithm
is a concatenation of DES, in a triple succession, it doesn't
behave as an ideal block cipher, therefore, its use is highly
cautioned. Current attack methodology, based on MITM,
theoretically reduces the complexity of Triple-DES from
anywhere around 2^108 - 2^112. However, you are still
working with a key length of 108 to 112 bits, practically, so
all is sufficient, in the security department (2^90 steps of
complexity could be visioned, where certain assumptions
and emphasis are placed). The reason Triple-DES
has become such a legacy, and highly recommended cipher,
stems from the fact that no other algorithm has undergone
such rigorous analysis and surfaced over 30 years later,
retaining a sufficient security margin in today's modern
cryptographic world. I've said it numerous times, and I'll
say it again, Triple-DES provides a user with a level of
confidence and trust that no other algorithm is capable of
doing.
Recommendations:
So, to give you my educated opinion on how you should
utilize the ciphers in question, refer to the following:
Ranging from 1, least favored, to 3, decent choice, to 5,
highly recommended.
The criteria for my choices is based on an overall exhibit of
speed, efficiency, security, and simplicity.
128-bit block ciphers:
Twofish:
Serpent:
Rijndael:
64-bit block ciphers:
IDEA:
Blowfish:
*DES:
* aside from the insecure 56-bit key length, DES has with
retained its security margin, in regards to a slew of cryptanalytic
attacks, over 3 decades.
Triple-DES doesn't behave like an ideal block cipher, as it is
an example of multiple encryption, so I won't place it in the
same class as the above ciphers. However, I will rank it as
follows, in a breakdown of elements:
Triple-DES:
Speed:
Efficiency:
Simplicity:
Security:
Overall:
Although it only received a 3, it is a stout 3, as it will continue
to remain a juggernaut for time to come. The most prominent
cipher, by far, in terms of analysis and respect.
So, here you have it, my opinion on the quality of block ciphers.
If there is anything in particular you have a question about, in
regards to these algorithms, please do let me know, as I'll be
glad to elaborate, if needed.
Hope you enjoy and find benefit from it. :]
_________________
"Strict Avalanche Criterion n. Restrictive clause in ski-insurance policy."
Last edited by JustinT on Sat Jul 31, 2004 5:12 am; edited 3 times in total |
|
| Back to top |
|
|
flw
Forum Junky
Joined: 27 May 2002
Posts: 949
Location: U.S.A.
|
| Posted: Fri Jul 11, 2003 4:57 am Post subject: |
|
|
On your speed rating of 3DES don't you think with the advent of even higher speed infrastructures both public and private along with the servers that makes it less of a issue?
Yes it still slow/takes bandwidth overhead but with the bandwidth available today to individuals homes, small busniesses and large it makes much less difference today than even 5 years ago. It not a non-issue, but certainly seems like a small one in today fibre world.
You also mention brielfly AES but don't go into detail any reason?
_________________
Dan
"Keep your friends close and your enemies even closer" from The Art of War by Sun Tzu
|
|
| Back to top |
|
|
JustinT
Trusted SF Member
Joined: 17 Apr 2003
Posts: 1227
Location: Charlotte, NC, US / Uberlāndia, MG, Brazil
|
| Posted: Fri Jul 11, 2003 6:40 am Post subject: Speed issues... |
|
|
| fastlanwan wrote: |
On your speed rating of 3DES don't you think with the advent of even higher speed infrastructures both public and private along with the servers that makes it less of a issue?
Yes it still slow/takes bandwidth overhead but with the bandwidth available today to individuals homes, small busniesses and large it makes much less difference today than even 5 years ago. It not a non-issue, but certainly seems like a small one in today fibre world.
You also mention brielfly AES but don't go into detail any reason? |
Well, DES was designed for hardware, in the '70s, so it's not going to have the same efficiency ratio in modern processors as fresh algorithm structures will, such as Rijndael or Blowfish. Also, it is unnecessarily slow in software, because of this. Let's assume the following conjecture. Suppose computing power does double, let's say, every 1.5 years and an algorithm becomes 10x faster every 5 years. So, in essence, speed isn't a huge issue, as programmers are making optimizations to algorithms on a regular basis. However, as DES wasn't intended for software, nor modern processors, it is much more difficult to adapt DES or Triple-DES to these environments. With that in mind, the use of DES or Triple-DES in new cryptographic systems is not suggested. So, in terms of comparing with other algorithms, it is an issue. In terms of your point, it's not a huge issue. You are correct. You only start to run into speed issues when you consider the lower end of computing, such as smart cards or embedded systems.
As to why I didn't comment much on AES...
Well, as the original post didn't call for information in regards to Rijndael itself, I chose to briefly mention it, before I elaborated on the comment as to AES being compromised. Overall, I recommend it as my 3rd cipher choice, with Twofish and Serpent holding the 1st and 2nd spots. It's a great cipher overall, but exhibits some characterists that pose interesting concerns. For instance, although simplicity is the prime catalyst of good security, it holds a strikingly simple algebraic structure, of which can be displayed as a formula, closed, over a 256 element finite field. As this isn't a vulnerability, in itself, it does open the door for a new breed of analysis. Until AES, this type of structure, and the analysis that subsides, hasn't been seen in such simplicity, so, it is but only a given that I am skeptical of the security of Rijndael. The current attack methodology that I mentioned is only theoretical, so Rijndael is safe, at the moment, just as Twofish and Serpent. However, I still don't fully trust the algorithm. My confidence lies in the designers, of which are two of the best in the field. However, my trust will be determined based on future analysis. Because this is the standard algorithm, it's good to use it, for compatibility's sake. I just have an uneasy feeling about it, thus far.
As I said, time and analysis will decide.
_________________
"Strict Avalanche Criterion n. Restrictive clause in ski-insurance policy."
|
|
| Back to top |
|
|
aberent
Trusted SF Member
Joined: 08 May 2003
Posts: 128
Location: Toronto
|
| Posted: Fri Jul 11, 2003 3:40 pm Post subject: To algorithm or not to algorithm |
|
|
I think developers often miss amid the algorithm debate that in reality the importance of which encryption algorithm is used is fairly insignificant in the greater scale of things.
Given with a task to recover a plaintext there are better ways to attack. Implementation errors, weak keys, social engineering are just a few areas that are much easier to take advantage of, compared to the task of say breaking AES.
My point is that developers are often distracted with the debate of which algorithm is better while often not paying attention to quality assurance, or password management.
For example I would much rather use AES or even Blowfish in a tight bug free protocol with a strong use of salts and iteration counts and good pass phrase management system, in comparison to using 3DES with none of the above mentioned things, (Even though 3DES is considered more secure).
I think as long as you are using one of the main encryption algorithms mentioned above by Justin, you should be fine as long as you implement then fully without any bugs and with good supporting pass-phrase management techniques suck as salts and iteration counts.
|
|
| Back to top |
|
|
-linux_lad
Trusted SF Member
Joined: 11 Apr 2003
Posts: 71
Location: California
|
| Posted: Fri Jul 11, 2003 5:01 pm Post subject: Re: Twofish, Blowfish, or 3DES Analysis and Review |
|
|
| sim0n wrote: |
Anyone know anything specific about the quality of the twofish algorithm compared to the older, and suppossedly more reliable ones such as blowfish, 3des and idea? I've heard that the Rijndael algorithm can be compromised significantly. What's your take on these subjects? Your opinion would be much appreciated.
ty |
In order to qualify as an officially sanctioned encryption algorithm, the source code has to undergo rigorous review. Rijndael (or AES), was determined to have the best combination of speed, security, and resistance to future attacks. Personally, I have a great deal of faith in all of them. TripleDES is DES with three iterations and two keys. The algorithm has been in existance since the seventies, and is widely considered to be highly reliable. IDEA got wide acceptance when it was part of PGP, and when made available to the general population, the author of PGP found himself the target of government harassment. That tends to suggest that IDEA is also considered fairly secure.
In terms of speed, your own experience is the best measure. TripleDES is the default algorithm in SecureCRT, which I use as my primary tool at work. The NIST has selected Rijndael over the other candidates, so they probably have a good deal of confidence in it. As I always say, unless you are trafficking in the big 3 no-nos, you can be sure beyond the shadow of a doubt that the algorithms will work as advertised and that there is no machine in existance that can crack the algorithm. That does not mean that your passprase might eventually be guesses, however.
Here's a true story to illustrate the point. Here in Sacramento a few years ago, the star of the district attorney's office was a guy named Pete Harned. Mr. Harned was responsible for prosecuting crimes against children, specifically, child molestaion and child pornography cases. DA Harned had a broken PC, and took it to the local Comp USA for repairs. Guess what the repair guy found in the CD-Rom drive? A CDROM of children in provocative poses. Of course, he called the police, and they came and got the machine, and pulled child porn website passwords out of the paging file. Then they got a warrant and went to his house and found one of the largest collections of child pornography ever recorded in the western US. This included about 1700 vhs tapes, some encrypted CDs and thousands upon thousands of photographs. It turned out that this was all evidence from previous cases he had prosecuted, so the evidence discovered to that point could be explained to the satisfaction of a jury.
The prosecutors needed something more solid, so the subpoenaed his credit card statements and found that he had purchased child porn CDs from a business in Denmark. The CDs were encrypted, with an algorithm that was unidentified at the time, so they were sent to Lawrence Livermore Labratory. A brute force machine took two months to find one password.
Pete Harned managed to get all of the evidence tossed, and he was convicted of some minor crimes. The time it took to get one password from a nonstandard (probably low end) encryption scheme was too long to be useful. The lesson here is that powerful, purpose built password recovery machines exist but they are only used on high value targets, and their effectiveness is only marginal. The real threat as far as you're concerned is not any perceived algorithm weaknesses, it's your passphrase.
I hope this helps!
_________________
-linux_lad
|
|
| Back to top |
|
|
JustinT
Trusted SF Member
Joined: 17 Apr 2003
Posts: 1227
Location: Charlotte, NC, US / Uberlāndia, MG, Brazil
|
| Posted: Fri Jul 11, 2003 6:28 pm Post subject: Re: To algorithm or not to algorithm |
|
|
| aberent wrote: |
I think developers often miss amid the algorithm debate that in reality the importance of which encryption algorithm is used is fairly insignificant in the greater scale of things.
Given with a task to recover a plaintext there are better ways to attack. Implementation errors, weak keys, social engineering are just a few areas that are much easier to take advantage of, compared to the task of say breaking AES.
|
Definitely. This is a good point. A vital one, at that. Implementation is the key to proper and secure algorithm deployment. Often times, an algorithm's security can be compromised via factors outside that of actually breaking it, such as social engineering, as aberent has pointed out.
You rarely hear of cryptographic systems failing, or being broken, in practice. This has little to do with the quality of the cryptography in question, but rather, quality at the implementation level. It is significantly much more trivial to exploit a vulnerability on the implementation level, than exploit an algorithm's vulnerability itself. Attackers know this and will approach it from this angle.
| Quote: |
My point is that developers are often distracted with the debate of which algorithm is better while often not paying attention to quality assurance, or password management. |
Agreed. Password management is a whole new ballgame that many forget to play, when implementing cryptography. On the algorithm level, however, it is wise to pay attention as to how the algorithms were designed, in order to determine the ratio of efficiency to the medium in which they are implemented. In all essence, there's nothing wrong with choosing a cipher based on "which is better", as not only are some ciphers better than others, some are more suited for specialized application, than others. For example, to quickly survey the performance of a few block ciphers, based on clock cycles per byte encrypted, you could refer to:
Block Cipher:
Blowfish - 18 cycles/byte
DES - 45 cycles/byte
IDEA - 50 cycles/byte
Triple-DES - 108 cycles/byte
This type of comparison could be used to determine which cipher is "better", in terms of speed, where the data to speed ratio is concerned. Although implementation concerns, password management, and social engineering are all important facets of security to be aware of, it is still highly cautioned to choose a good, well-rounded, analyzed cipher. This is why having a standard is beneficial. The masses will use it, although, a great majority of the mass will have no clue as to how it works, what attack methodology it is resilient to, or even know much of what cryptography even is. This goes for other widely used algorithms, such as Blowfish, which has earned its confidence via a myriad of factors, including the expertise of its designer, implementation efficiency, analysis, et cetera. These are all areas not within the confinement of social engineering, implementation quality, or password management.
You are correct, though, many developers get lost in the battle of the best, while placing the concept of quality assurance, on the implementation level, to the side, often leaving it behind.
| Quote: |
For example I would much rather use AES or even Blowfish in a tight bug free protocol with a strong use of salts and iteration counts and good pass phrase management system, in comparison to using 3DES with none of the above mentioned things, (Even though 3DES is considered more secure). |
Of course, and I would highly recommend this. Although 3DES is considered the most secure algorithm, in both the theoretical and practical sense, it is suggested that one deter from using this design in new cryptographic systems. However, it is still a solid algorithm to have around.
AES and Blowfish are much faster, and efficient, than 3DES, as most ciphers today are. 3DES is a special case, because it isn't an algorithm itself, yet a cascade of another, DES, so it behaves unlike any other ideal block cipher. Because of this cascade, you increase the number of routines, thus increasing the amount of time spent on encryption.
Although this exhibits a much higher security level than single DES, as the key length has now increased to a sufficient size, it carries along the undesirable slow speeds, associated with DES. Even if you deploy a good mixture of passphrase management, cryptographic salts, and key iterations, 3DES is still going to be less efficient than AES or Blowfish.
As for using AES and Blowfish, aberent has also mentioned the inclusion of a stable passphrase management system, cryptographic salts, and key iterations, to further the overall security margin, as a whole, within the system based around these two algorithms. In my opinion, with these facets kept in mind, you can't go wrong with AES or Blowfish, as they reign in their class of 128-bit and 64-bit ciphers, respectively.
_________________
"Strict Avalanche Criterion n. Restrictive clause in ski-insurance policy."
|
|
| Back to top |
|
|
sim0n
Forum Addict
Joined: 10 Jul 2003
Posts: 432
|
| Posted: Sun Jul 13, 2003 3:09 pm Post subject: ... |
|
|
thanks for the info. justin/aberant/linux
i think i'll stay with twofish and blowfish. What methods to do you recommend for passphrase length and usage?
|
|
| Back to top |
|
|
JustinT
Trusted SF Member
Joined: 17 Apr 2003
Posts: 1227
Location: Charlotte, NC, US / Uberlāndia, MG, Brazil
|
| Posted: Sun Jul 13, 2003 7:38 pm Post subject: Re: ... |
|
|
| sim0n wrote: |
thanks for the info. justin/aberant/linux
i think i'll stay with twofish and blowfish. What methods to do you recommend for passphrase length and usage? |
You're quite welcome.
It is normally recommended that a concatenation of uppercase, lowercase, symbols, and numbers be used, as this thwarts the effectiveness of dictionary attacks. This is common, and good, passphrase hygiene.
Here's a decent, and simple, write-up on the subject I came across:
http://security.tao.ca/pswdhygn.shtml
Remember, "phrase" is the keyword here. Typical, short, and common passwords are shunned. Be conservative, yet secure.
(On a side note, if at all possible, use 256-bit key size minimums, for Twofish and Blowfish; 448-bit for the latter, if you can help it.)
Cheers.
_________________
"Strict Avalanche Criterion n. Restrictive clause in ski-insurance policy."
Last edited by JustinT on Sat Jul 31, 2004 5:10 am; edited 1 time in total |
|
| Back to top |
|
|
flw
Forum Junky
Joined: 27 May 2002
Posts: 949
Location: U.S.A.
|
| Posted: Sun Jul 13, 2003 8:30 pm Post subject: |
|
|
| Quote: |
| Although 3DES is considered the most secure algorithm, in both the theoretical and practical sense, it is suggested that one deter from using this design in new cryptographic systems. |
This begs the question as to why? If speed is the main downside but is not a practical issue with todays infrastructure (mentioned in earlier post) then whats up with not continuing the use of 3DES.
I'll draw a analogy. If a application is written for 16 bit OS and contains 1000 lines of code and another application is written for 32 bit OS and contains 10,000 lines of code and they do the same thing as output which is faster? Yes I realize this is not a spot on analogy.
By processing larger chunks of code isn't always faster in the end so it may not be the best. It seems to depend on the need for security being none, low, medium, high or no known (published) breaks ever.
_________________
Dan
"Keep your friends close and your enemies even closer" from The Art of War by Sun Tzu
|
|
| Back to top |
|
|
JustinT
Trusted SF Member
Joined: 17 Apr 2003
Posts: 1227
Location: Charlotte, NC, US / Uberlāndia, MG, Brazil
|
| Posted: Mon Jul 14, 2003 1:33 am Post subject: Why not use 3DES? |
|
|
| fastlanwan wrote: |
This begs the question as to why? If speed is the main downside but is not a practical issue with todays infrastructure (mentioned in earlier post) then whats up with not continuing the use of 3DES.
|
Although you still see DES in applications today, it has outlived its overall usefulness. This isn't breaking news, as the implication of an AES answers the call for an algorithm of sufficiency.
However, DES still finds practical use, in the form of 3DES, be it for legacy purposes, or based on the fact that DES is the best analyzed algorithm, to date. Why not use 3DES? After all, you have a sufficient key size, backed by decades of analytical scrutiny...
Well, the answer isn't quite clear on the surface. In all actual senses, 3DES is still considered a "good" cipher, in terms of analyzed security, and will continued to be used because of this. Deep down, however, there are elements of 3DES that cryptographers find diminishing to its theoretical value. Although, in theory, it has held up, it inherits two properties of DES that keep it from meeting the standards of good, modern ciphers. Not only does it suffer from having a 64-bit block size, it shares the weak keys and complementation property that DES exhibits.
I have said, and will continue to say, 3DES has proven itself as the most confidence-worthy cipher, in theory and practice. Cryptographers won't shun its use, but will also not recommend its inclusion in newer protocols. 128-bit ciphers are the big guys now. They make efficient sense. DES or any of its variants may have retained there legacy as a secure cipher family, but they haven't retained their efficiency nor have they met the criteria for modern cryptographic algorithms. There are more efficient algorithms now, that satisfy the suggested cryptographic criteria. Efficiency comes into play where cryptography is needed most. When the demand arises, the efficiency, or lack thereof, is more noticeable. This is why programmers are constantly optimizing DES/3DES for modern processing. However, cryptographers are pre-optimizing ciphers for modern processing, so programmers and developers don't have to. This is where DES falls short.
So, the reasoning is as follows. DES has the longest track record, therefore, 3DES has proven to be secure. AES has only started in this race to proven security. This does not mean that DES is the most secure. What it does mean, however, is that we can prove the security of DES, because we have thrown it through the cryptanalysis cycle time and time again. We can't, however, prove the security lifespan of AES, nor any other modern cipher, such as Twofish, Blowfish, et cetera. We can only rely on the fact that they have withstood attacks thus far. We, as cryptographers, base our trust and use of a cipher on its analysis, and the time frame of which this analysis takes place. With this reasoning, it is only logical to continue using 3DES, regardless of how inefficient it may be, when compared to modern ciphers.
We can't, however, use it forever. That is why we develop new algorithms and propose new standards for more efficient and secure cryptography. This is why AES exists. The goal is to prove AES worthy, while slowly making a transition from the use of DES/3DES. So, 3DES, is our "backup", so to speak, at the moment. It's like that old truck sitting in the garage. May not be the most fuel efficient or good looking piece of machinery around, but it gets you where you need to go, with no problems, unlike that new car you just bought, supposedly the "best in its class", but is already showing signs of transmission problems. Familiar analogy? It's all about using the best we have until we can justify using something better.
So, why not continue to use 3DES? Well, we still do and will, for years to come, until eventually, the transition from 3DES to a new standard will become more noticeable. An interim standard, if you will.
_________________
"Strict Avalanche Criterion n. Restrictive clause in ski-insurance policy."
|
|
| Back to top |
|
|
|
