# Tag Info

5

Using a Unix Timestamp as the sole source for the nonce would make me nervous. In addition to forged NTP replies (and legitimate operators deliberately resetting the clock for some reason, and I'm not sure whether leap seconds would pose a risk), you also would need to worry about "what if I send two messages within the same second" On the other hand, you ...

1

If you are imagining something like 256+ bits of key -> SHA-256 -> one block keystream that you XOR with the plaintext, that is indeed almost the same as one-time pad. However, there is no advantage to doing that, considering you might as well have used the original key directly as a one-time pad. If, instead you use a password-based hash, a dictionary ...

0

Some stream ciphers (e.g. RC4 and Trivium) are reversible while others (e.g. A5/1) are not, but even in the non-reversible case, the expected number of preimages is always one[1], so in practice you can attempt to 'work backwards', storing all possible ancestors. The number of ancestors you need to store tends to grow linearly, but this can be sufficient ...

1

In any keystream generator, if the state repeats, so does the keystream; which, under some standards assumptions, can be detected, and leads to a serious break (e.g. if the beginning of the plaintext is known for length a little above $k+\log_2k$ bits, where $k$ is the period of the keystream, then the period $k$ and the rest of the plaintext can be found). ...

0

What you are describing is called a stream cipher, and is a common technique, but there are two important requisites that you are missing. First, you need a cryptographically secure random byte generator. Second, you must never reuse a keystream (the sequence of pseudorandom bytes) for more than one message. Real-world stream ciphers usually provide a ...

1

If your pseudorandom generator is good, then yes, this is secure (against passive attacks, for a single encryption). In fact, you can make that "if and only if": the questions of whether a pseudorandom generator is good and of whether this encryption method is secure (against passive attacks, for a single encryption) are fundamentally the same.

1

If these things are enough to obscure a file very much depends on who you are obscuring it for. As indicated in the previous question, there are still quite a few people that have ample knowledge on bits and bytes. If you are targeting not-so-tech-savy people then basically anything would suffice (as long as it doesn't show much in the default application or ...

2

XORing a plaintext with a random stream of the same size is a secure way to encrypt it. A stream cipher works in this way. The issue in your design is the random source. If the random stream does not have the security properties one expects, the systems is not secure. In your implementation, the seed has the role of the key (and potentially the ...

1

No. I actually new how to do such coding on my MSX machine in the mid-eighties (when I was 12). I'm pretty sure I could have decoded it back then. Note that binary code was much more used at that time; you had to code in assembler to get any kind of performance. It was also pretty common to compress things in such a way because you did not have much memory ...

0

To answer your question, I obfuscated 1MB of data that consisted of a single 1 followed by all 0's, using your technique, and fed the results to ent: Entropy = 0.000039 bits per byte. Optimum compression would reduce the size of this 1048576 byte file by 99 percent. Chi square distribution for 1048576 samples is 267385856.00, and randomly ...

-1

I would agree with @Biv regarding the strength of XOR encryptions are generally linked to the key. i.e. they are only as strong as the key stream.Conventionally, XOR encryption, relies on bitwise exclusive OR operation to generate the ciphertext since it is hardware efficient. In LTE, ciphering of user data takes place in the Packet Data Convergence ...

1

Some vocabulary (to answer your comments): Obfuscation is used in computer science to hide source code while maintaining it executable see here. The idea is to hide the source code and make it hard to copy, disassemble. Steganography is to hide a message such as the attacker does not know its existence. By having a encrypted file, this defeat this purpose ...

2

It sound like you're using something like an XOR cipher to obfuscate your code. It will appear to be encrypted, but this can still be broken by frequency analysis since the use of a constant shift means that the encryption effectively has no key. An example of how to break a similar XOR cipher can be found here. As @iismathwizard mentioned, decryption ...

4

Why is symmetric lightweight cryptography only about block ciphers and not about stream ciphers? Why that assumption? There is a lot of work concerning stream ciphers for lightweight cryptography (LWC). You can find a relevant list here. Plus, last week the ChaCha20-Poly1305 cipher suites (which are considered as lightweight) have been standardized in ...

Top 50 recent answers are included