Hi Robert, Thanks for your response: that was for a trivial case :)
Now let's try a curveball. We substitute lines 9 to 12 for the equivalent _somewhere else_ in the code, so it won't be a simple transform. This is based on a rule that a message sent on the 12th day of June would have certain properties, so no memorizing is required. 8 JuNi0jiIA6 9 nS1MSGrUoLv0VInSrfTKpEJtHCN7aksVxIOuiYgJySp6nWM0o8zpVL 10 1g5g8ipqHD45e5cDQOB2bRxqPLF+oUPHE0daaGtzUiccUGlKmuikOPjGlZKpqHQx 11 zVkrE/uEQil6UJMM/lhGXLI+pg4FzleotlWz0Dhc2lLqjqMHGTzt7uxcR6IFsqJT 12 HNkl21JswgxN0DlZaWLhBQeoAKKFbZWpZz4kbN9vYjTsqGhsMnNplH 13 GZvEnQ2oGy 14 qGlhUpW75BKVXgp2SWVqIkWJkws5VUofMQrblF19Pma1rKiK4GXUBK20k36sOj5y Let's consider another scenario where lines 9 to 12 are meaningless code inserted into the message. B has the rule to dispose of it but no one else would know the location and length of corruption. My gut feeling is that the human element throws a spanner into the algorithm. Regards, Tom (Haven't had time to consider the other responses, but many thanks - lots to learn here :) ) On Sun, 2006-06-11 at 23:41 -0500, Robert J. Hansen wrote: > > Since no one apart from A & B knows how the encrypted file has been > > corrupted, this seems to be a method of increasing security. > > There are some serious problems you'd have to hurdle. Let's assume > they're all hurdled, though, and that it works pretty much as you'd > expect. If we make that assumption, then we can talk about this scheme > in the best-case scenario. > > A reasonably long text message might be 3000 characters long. > Transposing the case of one of these letters gives us 3000 permutations. > Two gives us roughly nine million. Three gives us about 25 billion. > It's doubtful that you'd want to transpose more than three letters, due > to the difficulty of someone remembering "was I supposed to transpose > letters 1442, 1991 and 2047, or 1442, 1991 and 2074?" > > Log-2 of 25 billion is about 35. You've just added a factor of 2^35 > difficulty to breaking the message... but that's an _addition_, not a > multiplication. You're going to recover enough plaintext at the > beginning of the message to make it clear when you have the right key or > not. > > If you're going to posit the existence of an adversary who can do 2^128 > work to break your key, do you really think you're gaining anything by > _adding_ 2^35 work? 2^128 + 2^35 is so close to 2^128 as makes > absolutely no difference whatsoever. > > > Question: Is there in theory any way of breaking the corrupted > > encryption through brute force? > > Yes. As shown above, the additional work factor you're introducing is > trivial compared to the work in recovering the key in the first place. > -- _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
