New answers tagged

0

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 has not the security properties one expects the systems is not secure.


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 ...


1

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 ...


2

I should have started here: sub scrypt_hash { my ($key, $salt, $N, $r, $p) = _scrypt_extra(@_); return undef unless defined $key && defined $salt && defined $N && defined $r && defined $p; return "SCRYPT:$N:$r:$p:" . MIME::Base64::encode($salt, "") . ":" . MIME::Base64::encode($key, ""); } It explains that the last ...


1

No, there is no checksum built-in to the RSA keys per se. There is no need for that. Does this breaks the key ? Or changes the key internally, without breaking it ? [EDIT] It was rightfully pointed out to me that at least one of the statements I typed (in haste) was plain wrong. Now that the answer has served its initial purpose, I've removed my ...


1

Another danger of error correction followed by is the following. If we follow Kerchoff's principle, the error correction method/code as well as the encryption method should be public. Thus the only unknown is the secret key, assuming a symmetric scheme. Most error correction codes are linear and thus introduce dependencies between symbols that are input to ...


2

The correct procedure is Compress $\to$ Encrypt $\to$ ECC $\to$ Transmit. You would have no hope of error recovery if you were to apply error correcting information prior to encryption. It is the design goal of a cipher to introduce bit flips with probability ${1}\over{2}$ and Shannon's noisy channel coding theorem tell us we cannot communicate at all if ...


8

With some modes you can encode then encrypt, specifically stream cipher modes (CTR, OFB). Bit errors during transmission translate to identical bit errors in the encoded plaintext, and error correction will work as intended. However, with standard block cipher modes (ECB, CBC), the entire block is encrypted, and a 1 bit error in the ciphertext creates many ...



Top 50 recent answers are included