QUOTE
if you think some ascii number shifting is too low-leveled encryption, why don't you use some bitwise operation?
like this example:
1001001 >> 2 = 0010010
Pretty simple. Because bit-shifting like that and storing the extra stuff would require more computation. It's better
off to do a cyclic shift than what you're suggesting.
What I'm saying here is that
any one operand instruction is too simple. You can break the stuff into legible messages
faster than it'd take you to write the original message. Of course choosing one possibility out of n combinations would still
be a slight problem (hence why you'd use a dictionary attack in many cases) but still quite fast.
Now I'm not saying that linear bit-shifts and numerical shifts are bad. They're pretty nice actually,
when they're used properly.
Simple one operation encoders that can be programmed by total newbies don't count as serious stuff.
I don't like to say that - nor am I trying to be condescending towards newbs, but it's what I've seen.
If I were to try to make an encryption program, I'd probably use cyclic shifts (personal preference), xors, and a lookup table with
prime numbers to start. There, code that properly and I'd start worrying about the security of the program when someone gets
a Cray supercomputer to work on this thing and the Riemann Hypothesis has been proven. Methodwise, we know that nothing
is unbreakable, but it's how long it'd take to break that matters. Since that bit shift would probably have O(n) complexity in encoding
and is reversible without serious caveats (check out the last steps in the encoding of Salsa20 if you care to see examples),
I'd say it'd have O(n) time to decode as well. That's low-level cryptography to me.
Reply
Jul 24, 2008
