Your analogy, to the extent that only you understand what remains after applying the standardized decryption, actually has one more cipher at the end that the attackers don’t know, which puts it into the “unknown cipher-text” case.
Maybe. But I don’t know that at that point it’s a question about what cipher was used… just how to make the resultant data useful for, as you said, predict future data.
You seem to be specifically asking about how to “crack the code”—I’m saying that even if you “cracked the code”, you would still need to understand what’s going on with the underlying plaintext.
Maybe put it this way… assume that the underlying text is a data dump of (x,y) coordinates and to “predict future data”, you need the equation of the best fit line. We very well might be saying the same thing, but here’s how I see things:
Me: You arrive at this record encrypted with a cipher. You decrypt it. But then you still don’t know how to make the data useful because mathematics is not currently advanced enough to produce a curve for the best fit line.
You: You arrive at this record encrypted with a cipher. You decrypt it. The fact that you can’t make it useful means it’s still encrypted.
Does that seem like an accurate representation?
If so, then perhaps it’s not exactly encryption, but “writing an interpretation program that can take what we don’t yet see as a useful data-stream and making it useful.”
Thus, we could look at whatever it is in nature you want to look at, run some program on it, and have an increase in prediction abilities.
Put one last way, imagine that MS Word has not been invented yet but “nature” writes her secrets in a .doc file and then encrypts it. I think we’re disagreeing primarily on whether or not once it’s decrypted if the resultant file is still “encrypted” or not.
I get the sense that you’re saying it is, and I’m saying it’s not. According to nature, it’s right there for the taking. According to you, we still need one more level of “decryption”—inventing MS Word.
Put one last way, imagine that MS Word has not been invented yet but “nature” writes her secrets in a .doc file and then encrypts it. I think we’re disagreeing primarily on whether or not once it’s decrypted if the resultant file is still “encrypted” or not.
I get the sense that you’re saying it is, and I’m saying it’s not. According to nature, it’s right there for the taking. According to you, we still need one more level of “decryption”—inventing MS Word.
Yes, I think that’s a fair representation of my position, and let me say a few words in defense of it. Messages (and, in the realm of security, assets in general) always exist within the context of a larger system that gives them significance. For example, to evaluate the effectiveness of a lock on a shed, you must be mindful of the value of the assets in the shed and the cost of breaking the lock.
Likewise with messages: if you’ve “decrypted” a message, but don’t understand its relationship to the real-world assets the message is predicated on, your decryption is not complete. Hence the problem of steganography: you may be able to plainly read that a postcard says “the dolls are on hold because of a problem in the north, but the scarves are in production”, but it’s still employing a species of encryption to the extent that you don’t recognize that “dolls are on hold … in the north” means that the San Franciso harbor lost production capacity.
Likewise with foreign-language plaintexts. If your guys don’t know Japanese, and don’t know how to translate, the Japanese plaintext is still effectively encrypted. And whether or not you want to still claim that it’s not “really” encrypted, your team will have to do the exact same things to extract its meaning that you would do if it were “really encrypted”—i.e., discern the relationship between “ciphertexts” (the Japanese language) and the desired form of plaintext (English).
Btw, some followups: I’ve corrected an error in the previous post that fortunately didn’t cause a misunderstanding.
Also, I’ve argued the same thing you have—that you can improve encryption by adding an additional layer of plaintext uselessness. (One idea I presented in another forum was to talk in l33tsp34k so that you waste a human’s time deciphering the message even if they can get to the plaintext. It bothered me that my idea was dismissed without explanation.)
One of my goals in learning crypto is to know if and when this actually would improve security, and as best as I can tell, it doesn’t—as ciphergoth suggested to me, it makes your cryptosystem weaker where it’s already the weakest and stronger where it’s already strong enough. And it’s the weakest link that matters.
Yes, I think that’s a fair representation of my position, and let me say a few words in defense of it.
I think you’ve done well at that, and it makes sense. As a result… I’m just not sure I know at present how one might apply these principles to eliminate any forms of encryption and make anything in nature useful for improving prediction!
One of my goals in learning crypto is to know if and when this actually would improve security, and as best as I can tell, it doesn’t—as ciphergoth suggested to me, it makes your cryptosystem weaker where it’s already the weakest and stronger where it’s already strong enough. And it’s the weakest link that matters.
Could you explain if this was sort of an “aside continuation” re. the leetspeak comment or about encryption in general? In other words, are you saying that it doesn’t help to add an “underlying” layer of additional encryption, or that encryption, in general, doesn’t doe anyone much good?
Could you explain if this was sort of an “aside continuation” re. the leetspeak comment or about encryption in general? In other words, are you saying that it doesn’t help to add an “underlying” layer of additional encryption, or that encryption, in general, doesn’t doe anyone much good?
First, just to make clear, those were separate events, far removed in space and time. Ciphergoth’s remark was not directed at my leetspeak idea, but the principle applies just the same.
Encryption does accomplish the goal of raising the cost of accessing your messages to the point of infeasibility, and I wasn’t trying to deny that. To expand on the point about the underlying encryption: generally, the published cipher you use to encrypt your data is far stronger than it needs to be to keep your data safe; any succesful method of attacking it would go after the implementation of it, and in particular the people that need to make it work. Hence this comic.
So let’s look at your idea. Another relevant weakpoint of a cryptosystem would be the difficulty for the user of not messing it up, and this critically relies on you being able to access your (full) key. If you have to simultaneously do the work of remembering this secret language, this can mentally exhaust you and increase your rate of error in implementing the protocol—so it adds a weakness to the weakest part of the system (the human) just to strengthen the part that’s already the strongest (the encryption itself).
First, just to make clear, those were separate events...
Yup.
Also have seen that comic. So, you were basically saying:
encryption helps, and the actual encryption is the strongest point
the weak points are the people (prone to messing up) and (filling in my own list) things like leaving your computer on and unattended, only locking your screen vs. shutting down, having non-encrypted swap/var/etc, and the like.
further, trying to strengthen the weak points is generally accomplished via a method that further increases susceptibility to human error, whereas the encryption itself was fine as it its.
That’s correct, except your last bullet (to be clearer, if this is what you meant) should say that you can strengthen the weak points by making the system less susceptible to human error.
I was about to say no, but realize that I did write that incorrectly. To re-write, it would have redundantly said:
trying to strengthen the strong points is generally accomplished via a method that further increases susceptibility to human error (you have to implement “hand-done” encryption), whereas the encryption (the existing strong point) was fine as it was.
Does that help? I did have it wrong, thinking that implementing some form of hand-done encryption was an attempt to strengthen the weak points… but such activity would actually be in the “already-strong” category.
Maybe. But I don’t know that at that point it’s a question about what cipher was used… just how to make the resultant data useful for, as you said, predict future data.
You seem to be specifically asking about how to “crack the code”—I’m saying that even if you “cracked the code”, you would still need to understand what’s going on with the underlying plaintext.
Maybe put it this way… assume that the underlying text is a data dump of (x,y) coordinates and to “predict future data”, you need the equation of the best fit line. We very well might be saying the same thing, but here’s how I see things:
Me: You arrive at this record encrypted with a cipher. You decrypt it. But then you still don’t know how to make the data useful because mathematics is not currently advanced enough to produce a curve for the best fit line.
You: You arrive at this record encrypted with a cipher. You decrypt it. The fact that you can’t make it useful means it’s still encrypted.
Does that seem like an accurate representation?
If so, then perhaps it’s not exactly encryption, but “writing an interpretation program that can take what we don’t yet see as a useful data-stream and making it useful.”
Thus, we could look at whatever it is in nature you want to look at, run some program on it, and have an increase in prediction abilities.
Put one last way, imagine that MS Word has not been invented yet but “nature” writes her secrets in a .doc file and then encrypts it. I think we’re disagreeing primarily on whether or not once it’s decrypted if the resultant file is still “encrypted” or not.
I get the sense that you’re saying it is, and I’m saying it’s not. According to nature, it’s right there for the taking. According to you, we still need one more level of “decryption”—inventing MS Word.
Yes, I think that’s a fair representation of my position, and let me say a few words in defense of it. Messages (and, in the realm of security, assets in general) always exist within the context of a larger system that gives them significance. For example, to evaluate the effectiveness of a lock on a shed, you must be mindful of the value of the assets in the shed and the cost of breaking the lock.
Likewise with messages: if you’ve “decrypted” a message, but don’t understand its relationship to the real-world assets the message is predicated on, your decryption is not complete. Hence the problem of steganography: you may be able to plainly read that a postcard says “the dolls are on hold because of a problem in the north, but the scarves are in production”, but it’s still employing a species of encryption to the extent that you don’t recognize that “dolls are on hold … in the north” means that the San Franciso harbor lost production capacity.
Likewise with foreign-language plaintexts. If your guys don’t know Japanese, and don’t know how to translate, the Japanese plaintext is still effectively encrypted. And whether or not you want to still claim that it’s not “really” encrypted, your team will have to do the exact same things to extract its meaning that you would do if it were “really encrypted”—i.e., discern the relationship between “ciphertexts” (the Japanese language) and the desired form of plaintext (English).
Btw, some followups: I’ve corrected an error in the previous post that fortunately didn’t cause a misunderstanding.
Also, I’ve argued the same thing you have—that you can improve encryption by adding an additional layer of plaintext uselessness. (One idea I presented in another forum was to talk in l33tsp34k so that you waste a human’s time deciphering the message even if they can get to the plaintext. It bothered me that my idea was dismissed without explanation.)
One of my goals in learning crypto is to know if and when this actually would improve security, and as best as I can tell, it doesn’t—as ciphergoth suggested to me, it makes your cryptosystem weaker where it’s already the weakest and stronger where it’s already strong enough. And it’s the weakest link that matters.
I think you’ve done well at that, and it makes sense. As a result… I’m just not sure I know at present how one might apply these principles to eliminate any forms of encryption and make anything in nature useful for improving prediction!
Could you explain if this was sort of an “aside continuation” re. the leetspeak comment or about encryption in general? In other words, are you saying that it doesn’t help to add an “underlying” layer of additional encryption, or that encryption, in general, doesn’t doe anyone much good?
First, just to make clear, those were separate events, far removed in space and time. Ciphergoth’s remark was not directed at my leetspeak idea, but the principle applies just the same.
Encryption does accomplish the goal of raising the cost of accessing your messages to the point of infeasibility, and I wasn’t trying to deny that. To expand on the point about the underlying encryption: generally, the published cipher you use to encrypt your data is far stronger than it needs to be to keep your data safe; any succesful method of attacking it would go after the implementation of it, and in particular the people that need to make it work. Hence this comic.
So let’s look at your idea. Another relevant weakpoint of a cryptosystem would be the difficulty for the user of not messing it up, and this critically relies on you being able to access your (full) key. If you have to simultaneously do the work of remembering this secret language, this can mentally exhaust you and increase your rate of error in implementing the protocol—so it adds a weakness to the weakest part of the system (the human) just to strengthen the part that’s already the strongest (the encryption itself).
Does that make sense?
Yup.
Also have seen that comic. So, you were basically saying:
encryption helps, and the actual encryption is the strongest point
the weak points are the people (prone to messing up) and (filling in my own list) things like leaving your computer on and unattended, only locking your screen vs. shutting down, having non-encrypted swap/var/etc, and the like.
further, trying to strengthen the weak points is generally accomplished via a method that further increases susceptibility to human error, whereas the encryption itself was fine as it its.
Sound good?
That’s correct, except your last bullet (to be clearer, if this is what you meant) should say that you can strengthen the weak points by making the system less susceptible to human error.
I was about to say no, but realize that I did write that incorrectly. To re-write, it would have redundantly said:
Does that help? I did have it wrong, thinking that implementing some form of hand-done encryption was an attempt to strengthen the weak points… but such activity would actually be in the “already-strong” category.
You have it correct now. :)