Quote: |
There had to be some tradeoff betrween security and efficiency. |
Quote: |
certainly as far as security goes at least. I believe most people, even yourself would have chosen “Serpent” over Rijndael AES. |
JustinT wrote: |
You must be careful when using the notion of "security margin." It's important that you understand how to view it. Obviously, given the ratio of rounds covered by attacks as opposed to the total number of rounds, Serpent has a larger margin of security than Twofish, which has a larger margin of security than Rijndael. However, each of these block ciphers is semantically unique; what takes place during a round transformation is based on unique design strategies which meet particular security goals. Don't make the mistake of taking things too literally, by comparing apples with oranges. Consider, for example, that two rounds of Rijndael provide a "complete" diffusion effect, in a sense; some block cipher structures only achieve this after three or so rounds. Also, the number of rounds specified may affect the number of rounds necessary through which a propagation trail is to be located, which is a point of exploit for differential and truncated differential cryptanalysis, as well as linear cryptanalysis and even a saturation attack (i.e., structural, Square, et cetera). This is just to hint that a "margin of security" can be specific to the semantics of an individual algorithm, just as it can be the generic notion it is usually taken for. The generic notion only echoes the obvious, which is the current resilience of the block cipher against known attacks; there is no assurance of resilience against cryptanalytical advances or unknown attacks. Rijndael's security, as it is specified in the AES, does rely on the hope that no further improvements in known attacks will occur, as well as unknown attacks; this applies to any block cipher for which attacks exist, essentially. Based on this generic notion, it is, however, particularly worrisome that the standard carries the smallest margin, given its subjection to perhaps the most rigorous cryptanalysis. Either way, while it may be reasonable to say that Rijndael, as specified in the AES, has a "less conservative" generic margin of security, or is even more fragile, I don't believe it's justifiable to mark it off as weak, in the practical sense, such that it isn't suitable for the security of most conventional threat models. Its modularity, as with Square, would make it quite trivial to increase the number of rounds, if need-be, in the event that the standard is, or needs to be, altered. If you use the AES, use it because it is the standard; consider the affect on cryptanalysis and implementation efficiency that being a standard invokes. |
Quote: |
Hehe. No worries. I welcome criticism, as it provides new perspective on ideas. New perspective leads to the opening of new avenues of thoughts, and is beneficial to the learning process of which we will forever be a part of. |
Quote: |
So, thanks for perusing through the paper and sharing your opinion! It is appreciated. |
huh wrote: |
Why do I have to log in once then login again after submitting then again log in to re-submit? |
Quote: |
-Should I stop layering by encrypting more than once using PGP 8.1? PGP does NOT have ceaser's cipher (ehh i dont think anything does) but this was just an e.g to show the concept. |
Quote: |
If so, what alternatives do I have to reinforce the encryption and it susteptibity to attack/crack... should I just rely on one encryptio using PGP using a 4096 size key? Whats the best combination. |
Bungle wrote: |
I apologise in advance for compressing your very comprehensive last post down in a very over simplified way, but I was wondering am I correct in saying the following ? “Serpent and Twofish are probably the most secure at the moment but Rijndael has more potential for improvement in the future.” |
JustinT wrote: |
(While the following comments are not in objection, as I mostly agree with the quoted statements above (as have been documented, almost verbatim, in various publications), I believe there's a little more to it, than writing it off as overly complex. There are several good, simple, principles behind it.) And so goes the opinionated commentary that flourished throughout the AES selection process. The MARS team was an advocate of comments such as the difficulty of analyzing Twofish based on its construction; as such, there are opposing arguments by the Twofish team, and so on and so forth, for all teams with finalist AEA candidates. In other words, that's looking at it subjectively, when it requires objective thinking to appreciate it, as a whole. It's too opinionated not too. Elegance is subjective. The agitated animadversion-induced scrutiny that each block cipher faced was marked by such contravention, that you're almost forced to understand the mathematics behind the AEA candidates, to properly weigh each perspective, and understand the balance between design criteria and trade-offs. I think "complex" would be more appropriate than "too complicated", simply because there is a certain level of complexity that was intended, and in all actuality, there is a certain level of simplicity behind the components that Twofish consists of; there is nothing that difficult to understand about the components in the F function, such as pseudo-Hadamard transforms, or maximal distance separable matrices, in the g and h functions. These have been realized as cryptographic components for a decade or longer, so there is a bulk of the cipher that isn't really as complex as it's made out to be. This, in turn, sparks regurgitated comments by the cryptographically uneducated, which causes them to fail to see beyond a comment they read, thus lacking a balanced perception of it. Complexity is also partly subjective; if you look at components separately, as opposed to how they interact, there may be a world of difference. The peculiar key-dependent substitution tables are, essentially, where this notion of complexity sinks in, but that's nothing we didn't know about already; this is a trade-off that better fit the design rationale, which included meticulously crafted S-boxes, for known attacks (i.e., statistical), and a level of secrecy and key-dependency, for unknown attacks. While the latter may be impossible to actually build to resist, it's not outlandish to assume a certain level of confidence in such. Also, complexity may be seen throughout the various routines (e.g., rotations) and the mixture of algebraic groups represented, and how this affects approximations and their respective accuracy; however, sometimes, when you're addressing other criteria, some complexity will sneak in, inevitably, and sometimes, some complexity isn't necessarily bad. Breaking up structure has its benefits. |
JustinT wrote: |
(You can view Twofish as having either key-dependent or key-independent S-boxes; they are built from fixed permutations. Learn how they work, to understand that “double perspective.”) Sure; it's possible. He has also pointed out instances where they increase security over other constructions. A S-box can be poor - key-dependent or not, fixed, random, meticulously chosen, or however you cook them; just as well, it's possible to realize secure instances of these different constructions, under certain conditions. Structurally, if the underlying block cipher is especially susceptible to differential or linear cryptanalysis, no S-box of any form may be sufficient enough to resist it. Aside from how they are built, it depends on how they interact with various other components in the primitive. That's pretty obvious stuff. Key-dependency can be rather appealing, cryptographically, when done correctly. With key-dependency, it's also possible to make building linear or differential characteristics more difficult. “Correctly” is defined by “how”, “where”, and “why” it's used. It helps to understand the criteria for which they are designed to satisfy – the context. I believe Twofish uses a design strategy that is not only successful, but useful as a "blueprint" for future designs using similar concepts. Key-dependent S-boxes play a large role in that (e.g., take a look at how key-dependency affects diffusion of the key into the state of output). So, that statement alone is a bit empty, without some sort of context; the context usually depends on which algorithm is in question and what is expected of the S-box(es), given the design rationale. But, overall, yes – there is nothing invalid about saying that the structural semantics of Twofish are somewhat difficult to analyze, and this did come into play during the selection process, but there is a counter-argument for that; the designers acknowledge both points. Both simplicity and complexity have the tendency of being either “just right” or “too much.” Which, exactly, isn't always obvious. While a certain level of simplicity, on the one hand, is vital in the design of a primitive, too much simplicity, structurally, may facilitate analysis not only for academic cryptanalysts, but for unknown adversaries. On the other hand, while a seemingly complex structure may make analysis difficult for academic cryptanalysts, our approximations may suffice, and this same difficulty may make analysis just as difficult for an unknown adversary, by reducing overly simplistic structures that may otherwise facilitate attack strategies. Again, it's a trade-off, and one that, I think, serves Twofish well, in a myriad of cases. Of course, to a certain extent, I find it valid to look at this from an opposing perspective, since it's one of those issues that is still open. It's possible to justify both simplicity and complexity, if kept reasonable; this is especially so for complexity, since it truly is, in excess, the cardinal sin of an allegedly, cryptographically, secure system. Keep things as simple as they can be, given your design rationale, which should be reasonable. You have to know when and where to be either. There is, however, enough understanding for, and literature available on, the individual components, and general Feistel structure, to make a significant effort at analyzing it. My concern is for those who merely read opinionated remarks made during the conferences for the selection of an AEA for the AES, without the realization that Twofish was one of the more rationale-induced candidates. As aforementioned, the perception should be objective, to fully appreciate the design. Cryptanalysis, as we conceptualize these days, is largely theoretical, as are notions of a “margin of security”, which, albeit a useful formulation, is extremely volatile, as are many assertions being made for block cipher security in general. Thus, it's good to explore different routes that lead us to different, sound strategies. The contest was successful – quite a bit more so than many expected. What we're left with is a design that is among the most flexible we've seen, in terms of trade-off versatility, with a simple, modular concatenation of components, that not only holds up well, but performs well. This is a necessity in a conventional primitive – to secure and perform. So, in conclusion, I feel that the simplicities and complexities of Twofish are decently balanced, and conform quite nicely to the “math and muddle” approach, thus rendering a strategy that has proven to be practically robust, thus far; in fact, it's one of the best performance-driven block ciphers we have, considering the notion of “margin of security.” Once you [the uninformed, in general] comprehend Twofish, and understand what's going on in the functions it is built around, I suppose, then, it may all become blatantly obvious. After all, a clue hasn't been known to jump up and bite someone! (I'm not partial towards Twofish, for any non-cryptographic reason; these are just observations I've made during mathematical research and a cursory glance at publications. Any level-headed cryptographer (i.e., an academic) should invest a little time into learning these things. Even though recommending the current AES is reasonable, it's just as reasonable to appreciate the design strategy of other finalist AEA candidates, including Twofish, which is one of the most important. Looking at it objectively, and thoroughly, will require a proficiency in the mathematics that compose these primitives, as well.) |
Quote: |
If so, what alternatives do I have to reinforce the encryption and it susteptibity to attack/crack... should I just rely on one encryptio using PGP using a 4096 size key? Whats the best combination. |
Quote: |
The way that block ciphers are implemented with PGP, it doesn't seem likely that you will have your blocks lining up precisely, so if you are encrypting to the same key twice with off the shelf PGP, you will not receive any additional security, I doubt that you would have any additional weakness though, because PGP does attempt compression before encryption, etc. We could probably have a long debate on the subject and have no real answers--just conjecture.
If you wrote a program that would apply AES-128 twice with the same key, you would only get 129 bits of effective encryption. If you did the same thing, but applied the algorithm 1024 times, you would get an effective keylength of 138 bits, heres were the real debate about relative strength and possible cryptanalytic breaks that could be derived from repetative uses of the same key would come in... What it comes down to in the end is that real improvement of security for multiple rounds of encryption require different keys as is demonstrated with Triple-DES. By performing operations with multiple keys 3DES does create an effectively longer keylength to overcome the weakness that it originally faced with a 56-bit encryption key. (Unfortunately 3DES is also incredibly slow.) My point in summary is that you probably won't gain any security from running the encryption more than once. You probably want to think about bigger key-lengths as a means of achieving greater security in the actual data-encryption. |
comrade wrote: |
Dont bothering trying to layer encryption.
You have bigger worrys. |
huh wrote: | ||
another member against encryption layering! why? pgp support says it works what are these other worries, if i may ask |
comrade wrote: |
A hot chick offering sex for said pass. |
output generated using printer-friendly topic mod, All times are GMT + 2 Hours