3 ms·
As everyone said, you have created a stream cipher. But I feel that I have to add that your idea (OTP with small key) is usually implemented this way: the small
by devcpp 13y ago
As everyone said, you have created a stream cipher. But I feel that I have to add that your idea (OTP with small key) is usually implemented this way: the small key is a counter used an input to some PRNG specifically designed for this (you should try AES in CTR mode), which you increment every time.
This produces a sequence which is always the same for each session, but because the keyspace is so large (2^128 with AES-128), this is acceptable because these PRNGs are actually cryptographically secure hash functions, which makes them very hard to reverse. Therefore, the only efficient way to crack your session is to either catch the key (your counter) or to brute force it by using every value of the counter and test whether this leads to a successful decryption. Not only are there 2^n possibilities, but every possibility is extremely expensive to test and then you have to accurately check whether the decrypted values are coherent (this is difficult with packets with a fixed header and nearly impossible with raw binary data).
The big disadvantage is having to store your small key until decryption.
- quelsolaar 13y agoI have always been curious why encryption keys are so small. with todays networks/memory 10kbytes key should not be un noticable.
- duskwuff 13y agoIf a cryptographic algorithm is fundamentally secure, a small (128 - 256 byte) key will be all it needs to be secure. If an algorithm can't be secure with a key that size, giving it a bigger key is likely to only make it marginally better.
- quelsolaar 13y agoYes but it removes the entire discussion about when a particular algorithm becomes viable to break brute force.
- duskwuff 13y agoNo, that's simply not true. A 128 - 256 bit key is already infeasible to brute-force, so long as the algorithm uses the key appropriately.