Many have questioned whether cryptological strength can be adequately described. Perhaps some unknown method may be found to break a system therefore rendering it useless for serious purposes. And, different qualifiers have been advanced to champion a chosen algorithm. Well, there are only just a couple of considerations that do actually matter, can the whole functional key(s) be derived using chosen text, and how much information is necessary to verify that the true plaintext has been recovered.
While the otp is the best in one category and the worst in the other, see that it as functionally defective, a one-sheet paper plane in a fleet of many birds. Perhaps no other algorithm is so extreme as the otp so as the exception it proves the rule...that other algorithms are a better choice for almost every reason.
Dealing with scaled strength in an intelligent manner is what this posting is about, even that categories of strength can and should be mathematically defined and therefore different algorithms and keys compared as to their ratings.
Remember, one equalizer with the scale is that computer power is not a factor to be taken seriously. If something is beyond solution on information grounds alone, that is just the way it is. Yes, those really good at dealing with marginal data again do prove the point that given the data, they have enough. Practice at solving is built on testing ones abilities to find the patterns that are there but wrong results while being seemingly understandable still means that the data was insufficient.
My rough strength scale is simple and echos an old vernacular: 0 to 1 is trivial or very weak; 1 to 2 is weak; 2 to 3 is marginally strong; 3 to 4 is strong; and 4 to ? is very strong.
See the above ranges? They imply that strength can be even further quantized according to some formula perhaps...and here it is:
SSS# = log base 27 of the approximate amount information of required. The formula would be valid for any information units with the needed mathematical conversion.
As 27 is very close to 26, number of common text letters, it is easy to see level 1 is 27 letters, level 2 is 721 letters, level 3 is 19783 letters, and level 4 is 534441 level 5.
In bits, it would be 128 bits for level 1, 3.5K bits for level 2, 92.6 K bits for level 3, and 2.5M bits for level 4. Shocked? You should be.
We can place many common known algorithms according to their conventional strengths in the scale. I grasp the concept fully and time that you did as well. The formula plays no favorites while it coldly fractures shallow definitions of strength for many touted algorithms.
Much crypto should be written to high criteria for strength and not to flawed mathematical purpose or at least it should be simply specified for what it is. If you really want strong crypto? Shoot higher or you may get your own toes. If you want to play games, that would be obvious but don't discount spy vs. spy. Above all, open your eyes or you will never see the laughter you may have spawned if you have deluded yourself with a blindfold.
Frankly, I enjoy working across the spectrum of strengths, simple to sublime. Then I see how many principles can really be combined to reach the strong poetic stuff whenever desired. All sincere efforts at any level should be applauded in this group so even after many years, I so invite the crypto curious to be here.
> Many have questioned whether cryptological strength can be adequately > described. Perhaps some unknown method may be found to break a system > therefore rendering it useless for serious purposes. And, different > qualifiers have been advanced to champion a chosen algorithm. Well, > there are only just a couple of considerations that do actually > matter, can the whole functional key(s) be derived using chosen text, > and how much information is necessary to verify that the true > plaintext has been recovered.
I disagre. Take fore example an attack not on a block cipher itself, but on its selection of permutation. If the permutation can be identified, this does not necessarily leak the key, but it undeniably breaks the security. It is arguable that this delivers an equivalent key in an equivalent algorithm, but it certainly does not recover the "functional key" of the original algorithm, and may not necessarily be possible to convert to the key itself. Admittedly, this is a significantly unusual form of attack, but it certainly violates the statement that there are "only ... a couple of considerations that do actually matter" by providing an attack that avoids both, but is unarguably security destroying.
> SSS# = log base 27 of the approximate amount information of required. > The formula would be valid for any information units with the needed > mathematical conversion.
> As 27 is very close to 26, number of common text letters, it is easy > to see level 1 is 27 letters, level 2 is 721 letters, level 3 is 19783 > letters, and level 4 is 534441 level 5.
That has to be one of the worst scales I've ever seen. It has no relation to reality, only serves to provide an appearance of thoughtfulness.
> In bits, it would be 128 bits for level 1, 3.5K bits for level 2, 92.6 > K bits for level 3, and 2.5M bits for level 4.
This directly contradicts the earlier metric as well. 27 is only 4.something bits, a far cry from 128. In short your metric is worthless on the surface and gets worse the more you explain it. Feel free to stop.
> Shocked? You should be.
Not really shocked, the evidence so far is that you haven't properly thought it out. Considering that using every atom in the universe for the entire lifetime of the universe at the fastest possible clock the result is still less than 2^350 work, so clearly all of your estimates are about as far from reality as possible.
It will take much, much more than fool-hearty handwaving based on a lack of knowledge will serve no purpose. Joe
> Many have questioned whether cryptological strength can be adequately > described. Perhaps some unknown method may be found to break a system > therefore rendering it useless for serious purposes. And, different > qualifiers have been advanced to champion a chosen algorithm. Well, > there are only just a couple of considerations that do actually > matter, can the whole functional key(s) be derived using chosen text, > and how much information is necessary to verify that the true > plaintext has been recovered.
> While the otp is the best in one category and the worst in the other, > see that it as functionally defective, a one-sheet paper plane in a > fleet of many birds. Perhaps no other algorithm is so extreme as the > otp so as the exception it proves the rule...that other algorithms are > a better choice for almost every reason.
> Dealing with scaled strength in an intelligent manner is what this > posting is about, even that categories of strength can and should be > mathematically defined and therefore different algorithms and keys > compared as to their ratings.
> Remember, one equalizer with the scale is that computer power is not a > factor to be taken seriously. If something is beyond solution on > information grounds alone, that is just the way it is. Yes, those > really good at dealing with marginal data again do prove the point > that given the data, they have enough. Practice at solving is built > on testing ones abilities to find the patterns that are there but > wrong results while being seemingly understandable still means that > the data was insufficient.
It appears from the above exposition that you are attempting to reinvent the idea of "unicity distance" (but, as Joseph Ashwood mentioned, you may have gotten some of the details a bit off, especially with your logarithmic scale).
Unicity distance does have one advantage over modern indistinguishability arguments; it gives concrete lower bounds on security (in contrast, we know how to show things are distinguishable from random, but we still have no proof of indistinguishability).
On the other hand, unicity distance does have some problem. Here some of them from a modern cryptographical perspective:
- Unicity distance is mostly controlled by two things, key size (which is reasonable) and the distribution of possible plaintexts. In modern cryptography, we don't get to pick the plaintexts, that's chosen by someone outside the security area for noncryptographical reasons, and so we as a rule do not make any security assumptions based on what the plaintext looks like. And, if we worse-case the plaintext distribution (say, there is only one possiblity, aka "known plaintext"), then for most ciphers, the unicity distance is pretty close to the key size (and you really don't want to use the ciphers for which this isn't the case).
- It is extremely pesimistic, even if we don't worse-case the plaintext distribution. In most realistic scenarios (with plaintexts and plaintext sizes that are not under the cryptographer's control), it generally requires unrealistically huge keys to make sure that the unicity distance is actually bigger than the ciphertext.
- From a theoretical standpoint (and why do we go with informational-theoretical models unless we're willing to talk theoretical), it can be insufficient. Unicity distance allows ciphers to leak significant amount of information about the plaintext, as long as the information leaked is not sufficient to reduce the number of possible plaintexts to one. To take an extreme (and somewhat silly) example, consider a modified OTP where the first 8 octets of every 64 is replaced by zeros. If we use that to encode an English ASCII message, that allows the attacker to see 8 out of every 64 characters. Since there are lots of ways to fill in the remaining 56 with plausible text, this modified OTP still has infinite unicity distance (for the possible plaintexts of English ASCII messages), but would obviously be totally unacceptable from a security standpoint.
> "WTShaw" <lure...@gmail.com> wrote in message > news:96753b1d-08d4-4ba8-a77e-8cbd419ac817@k30g2000hse.googlegroups.com... >> Many have questioned whether cryptological strength can be adequately >> described. Perhaps some unknown method may be found to break a system >> therefore rendering it useless for serious purposes. And, different >> qualifiers have been advanced to champion a chosen algorithm. Well, >> there are only just a couple of considerations that do actually >> matter, can the whole functional key(s) be derived using chosen text, >> and how much information is necessary to verify that the true >> plaintext has been recovered.
>> While the otp is the best in one category and the worst in the other, >> see that it as functionally defective, a one-sheet paper plane in a >> fleet of many birds. Perhaps no other algorithm is so extreme as the >> otp so as the exception it proves the rule...that other algorithms are >> a better choice for almost every reason.
>> Dealing with scaled strength in an intelligent manner is what this >> posting is about, even that categories of strength can and should be >> mathematically defined and therefore different algorithms and keys >> compared as to their ratings.
>> Remember, one equalizer with the scale is that computer power is not a >> factor to be taken seriously. If something is beyond solution on >> information grounds alone, that is just the way it is. Yes, those >> really good at dealing with marginal data again do prove the point >> that given the data, they have enough. Practice at solving is built >> on testing ones abilities to find the patterns that are there but >> wrong results while being seemingly understandable still means that >> the data was insufficient.
> It appears from the above exposition that you are attempting to reinvent > the idea of "unicity distance" (but, as Joseph Ashwood mentioned, you may > have gotten some of the details a bit off, especially with your > logarithmic scale).
I appear to have forgetten to include a definition of unicity distance. Well, it's the minimum amount of ciphertext for which there exists only one plausible plaintext (or, if you don't like that definition, go with the one on Wikipedia).
> Unicity distance does have one advantage over modern indistinguishability > arguments; it gives concrete lower bounds on security (in contrast, we > know how to show things are distinguishable from random, but we still have > no proof of indistinguishability).
> On the other hand, unicity distance does have some problem. Here some of > them from a modern cryptographical perspective:
> - Unicity distance is mostly controlled by two things, key size (which is > reasonable) and the distribution of possible plaintexts. In modern > cryptography, we don't get to pick the plaintexts, that's chosen by > someone outside the security area for noncryptographical reasons, and so > we as a rule do not make any security assumptions based on what the > plaintext looks like. And, if we worse-case the plaintext distribution > (say, there is only one possiblity, aka "known plaintext"), then for most > ciphers, the unicity distance is pretty close to the key size (and you > really don't want to use the ciphers for which this isn't the case).
Sigh.... I really blew it here: if there is only one possible plaintext, the unicity distance is, of course, 0 (we don't need any ciphertext if we already know the plaintext). I was thinking about the amount of ciphertext you needed to recover the key, but unicity distance isn't about recovering the key, it's about recovering the plaintext.
> Unicity distance does have one advantage over modern indistinguishability > arguments; it gives concrete lower bounds on security (in contrast, we know > how to show things are distinguishable from random, but we still have no > proof of indistinguishability).
> On the other hand, unicity distance does have some problem. Here some of > them from a modern cryptographical perspective:
> - Unicity distance is mostly controlled by two things, key size (which is > reasonable) and the distribution of possible plaintexts. In modern > cryptography, we don't get to pick the plaintexts, that's chosen by someone > outside the security area for noncryptographical reasons, and so we as a > rule do not make any security assumptions based on what the plaintext looks > like. And, if we worse-case the plaintext distribution (say, there is only > one possiblity, aka "known plaintext"), then for most ciphers, the unicity > distance is pretty close to the key size (and you really don't want to use > the ciphers for which this isn't the case).
Maybe thats the failure of modern cryptography, One size does not fit all. To encrypt text or encrypt music or video or images should all be done differently at least if one wants to keep it secure. Also besides key length its really entropy density that you want to maximize.
> - It is extremely pesimistic, even if we don't worse-case the plaintext > distribution. In most realistic scenarios (with plaintexts and plaintext > sizes that are not under the cryptographer's control), it generally requires > unrealistically huge keys to make sure that the unicity distance is actually > bigger than the ciphertext.
So that still is not a reason to not have large keyed systems for those that want more security.
> - From a theoretical standpoint (and why do we go with > informational-theoretical models unless we're willing to talk theoretical), > it can be insufficient. Unicity distance allows ciphers to leak significant > amount of information about the plaintext, as long as the information leaked > is not sufficient to reduce the number of possible plaintexts to one. To > take an extreme (and somewhat silly) example, consider a modified OTP where > the first 8 octets of every 64 is replaced by zeros. If we use that to > encode an English ASCII message, that allows the attacker to see 8 out of > every 64 characters. Since there are lots of ways to fill in the remaining > 56 with plausible text, this modified OTP still has infinite unicity > distance (for the possible plaintexts of English ASCII messages), but would > obviously be totally unacceptable from a security standpoint.
No this would not be an infinite unicity distance. This is an example of what happends when the entropy is not spread through the file. Shanon theory is based on an honest attempt to actually try to hide the text. In your example parts of the message would be known and part would not be known. Its also lossy encryption so the intended does not get to decrypt it either.
However in an attempt to really use Unicity distance the goal would be to compress the input so that a uniform entropy rate occurs. Then Unicity distance could be used to tell how many ciphertext blocks need to be guesed or known to effectively break the cipher.
However the common way to up the entropy rate with compression results into problems one known information is often added during the compression process and two the entropy density is usually bad at strat of compressed data.
Compressing a file with a bijective BWT compressor especially a binary one gives a very solid way to avoid unicity distance problems on long files. Here is why: 1) there is no infomation added to file and the entropy density is more uniform 2) The unicity distance would allow say a ppm compressed encrypted file to have enough information for a break after some small number of blocks. 3) There really would not be really be enough information in the first few blocks of a proper bijective BWT file since if the file is long enough the front part of the compressed file could be anything since what is really there depends on plainttext that was compressed farther down the file. Its like using the trailing plaintext as part of the KEY when one really tries to compure the Unicuty distance. You actually have to think what Shanon was trying to do to use the theory. I guess you could call such a method a univity distacne expander since effectively the plaintext is functioning as part of the key. .That only gets revealed after most of the file is decrypted.
On Jul 16, 6:21 am, "Joseph Ashwood" <ashw...@msn.com> wrote:
> I disagre. Take fore example an attack not on a block cipher itself, but on > its selection of permutation. If the permutation can be identified, this > does not necessarily leak the key, but it undeniably breaks the security. It > is arguable that this delivers an equivalent key in an equivalent algorithm, > but it certainly does not recover the "functional key" of the original > algorithm, and may not necessarily be possible to convert to the key itself. > Admittedly, this is a significantly unusual form of attack, but it certainly > violates the statement that there are "only ... a couple of considerations > that do actually matter" by providing an attack that avoids both, but is > unarguably security destroying.
Functional would mean that which facilitates an attack or solution is the original algorithm accepted so called themes and variation or derivatives. Much would depend on exactly what algorithm was used.
> That has to be one of the worst scales I've ever seen. It has no relation to > reality, only serves to provide an appearance of thoughtfulness.
Contrary to your view, there are good examples of amounts of data necessary to solve different ciphers. Note ACA's list of required lengths of ciphertexts for different ciphers. The examples are at the lower parts of the scale but proven valid over decades. I merely use that notion as a starting concept to extend to some logical point.
> > In bits, it would be 128 bits for level 1, 3.5K bits for level 2, 92.6 > > K bits for level 3, and 2.5M bits for level 4.
> This directly contradicts the earlier metric as well. 27 is only 4.something > bits, a far cry from 128. In short your metric is worthless on the surface > and gets worse the more you explain it. Feel free to stop.
Try not to eat the whole pickle at once );...the math is sound including the log relationships between bases. Each character is a larger set has more absolute information than that of a lesser one.
> It will take much, much more than fool-hearty handwaving based on a lack of > knowledge will serve no purpose. > Joe
Joe,you are intelligent but as it may not serve your purpose, it serves mine.
On Jul 16, 9:22 am, "Scott Fluhrer" <sfluh...@ix.netcom.com> wrote:
> I appear to have forgetten to include a definition of unicity distance. > Well, it's the minimum amount of ciphertext for which there exists only one > plausible plaintext (or, if you don't like that definition, go with the one > on Wikipedia).
I've seen variations on the definition, all getting at much the same thing, solving for the plaintext as you say. I suppose even Shannon did much the same thing while toying with the overall concept. For practical purposes, the formula I use is rather loose as well.
I'll may be getting into examples for other bases and showing direct comparisons and how great amounts of information are packed into just a few characters. I just have to translate the table I use.
> > Unicity distance does have one advantage over modern indistinguishability > > arguments; it gives concrete lower bounds on security (in contrast, we > > know how to show things are distinguishable from random, but we still have > > no proof of indistinguishability).
> > On the other hand, unicity distance does have some problem. Here some of > > them from a modern cryptographical perspective:
> > - Unicity distance is mostly controlled by two things, key size (which is > > reasonable) and the distribution of possible plaintexts. In modern > > cryptography, we don't get to pick the plaintexts, that's chosen by > > someone outside the security area for noncryptographical reasons, and so > > we as a rule do not make any security assumptions based on what the > > plaintext looks like. And, if we worse-case the plaintext distribution > > (say, there is only one possiblity, aka "known plaintext"), then for most > > ciphers, the unicity distance is pretty close to the key size (and you > > really don't want to use the ciphers for which this isn't the case).
> Sigh.... I really blew it here: if there is only one possible plaintext, the > unicity distance is, of course, 0 (we don't need any ciphertext if we > already know the plaintext). I was thinking about the amount of ciphertext > you needed to recover the key, but unicity distance isn't about recovering > the key, it's about recovering the plaintext.
On Jul 16, 9:42 am, biject <biject.b...@gmail.com> wrote:
> ...So that still is not a reason to not have large keyed systems for > those that > want more security.
That is important. If the keyspace is HUGE, there may be many ways to generate a key in it and really no efficient way to search for it. Meanwhile, if given the freedom to customize key generation, the hacker would be at a lost as to where to start.
Scott Fluhrer wrote: >- Unicity distance is mostly controlled by two things, key size (which is >reasonable) and the distribution of possible plaintexts. In modern >cryptography, we don't get to pick the plaintexts, that's chosen by someone >outside the security area for noncryptographical reasons, and so we as a >rule do not make any security assumptions based on what the plaintext looks >like. And, if we worse-case the plaintext distribution (say, there is only >one possiblity, aka "known plaintext"), then for most ciphers, the unicity >distance is pretty close to the key size (and you really don't want to use >the ciphers for which this isn't the case).
There is one limited area of cryptography where the above does not hold true; encrypting random data, either as a method of sending a key to a remote location or in the case where a cryptosystem is constantly encrypting randome data and sending it so as to make traffic analysis more difficult.
