On Thu, Jan 20, 2011 at 01:36:55PM +1100, Noon Silk wrote: > Hah. I'm not sure how to take that; if you knew people wouldn't get > the idea from your original message why wouldn't you clarify it up > front?
It's hard to know in what ways people will misunderstand you, for the same reason it's hard to see bugs in code you wrote. But there's a funny thing about cryptographers: If you just state the formal problem, namely my last question(s), they might give you an answer, but you probably won't get any answers (possibly out of lack of a practical purpose), or you might get answers that fail due to lack of context. But if you try and provide some context, often they'll try to provide alternatives, rather than answering the question, often due to misunderstanding the context or inadequacy of explanation. The problem with this is that you then have to go back and re-clarify, unless you rather tediously define all your terms, assumptions and constraints a priori. The problem with that is it wastes time on things that might not need explaining. But sometimes the process can be elucidating, not only in what they don't understand from your explanation, which teaches you how to explain when you want to be better understood, but also because they sometimes present alternatives which might actually work. So this time I just tried my best to explain context, and now I'm having to shore it up, but I have spare time on my hands. ;-) > > OTP won't work - simply XORing a printable character with a non-printable > > won't guarantee a printable, for example, and symbols have to be printable. > > Well no, it won't, but it's surely obvious that you could make it such > that it was in the printable range? That woudl make the obfuscated symbol larger than the non-obfuscated, and that would require altering the structure of the container file, which I can't do. The constraint is not a maximum length, but that the function be length-preserving. > > Furthermore, the symbols have to map to the same thing on subsequent > > releases so crashes can be correlated across releases. > > This last point is just a function of your decoding process. You're > implying that you want to match pre-decryption, not post-decryption. I'm saying if the symbol is "plaintext" and the obfuscated symbol is "obfuscate", it has to be that way for every release, without sharing a database of mappings between releases. This is so that crash dumps across releases can be correlated. > I'd expect you'd want to match post-decryption, otherwise it would be > trivial to correlate your "obfuscation" anyway, no? Obviously, the once you invert the obfuscation, then you should have the original value. I'm not quite following you here, possibly you said "decryption" instead of "obfuscation", in which case I must clarify that we do actually want people to know where the symbols migrated across releases. That is necessary for crash log analysis, though not ideal from a security perspective. PS: Since you might be interested in OTPs, I run the OTP mailing list: http://lists.bitrot.info/mailman/listinfo/OTP -- Effing the ineffable since 1997. | http://www.subspacefield.org/~travis/ My emails do not usually have attachments; it's a digital signature that your mail program doesn't understand. If you are a spammer, please email [email protected] to get blacklisted.
pgpECgIelDVKv.pgp
Description: PGP signature
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
