New answers tagged

1

First since E is an encryption algorithm, it has a Decryption counterpart, lets name it D. From the correcntess equation we get that $E(x,D(x,c)) = c$ for every $x$. Then we can easily see that if $$y= x \oplus D(x,c)$$ then $$f_2(x,y) = E(x, y \oplus x) = E(x, x \oplus D(x,c) \oplus x) = E(x,D(x,c)) = c$$ Again this holds for every $x$. So we have just ...


2

With such a small block size there is no way to employ RSA padding modes such as PKCS#1 v1.5 padding or OAEP. You could however see the encryption as ECB mode encryption. In that case you could apply padding mechanisms that have been constructed for symmetric block ciphers. Those padding modes however have been defined for bytes rather than characters. ...


0

This is an issue with any block cipher. One solution is to pad the message. This means that, first you split it into blocks and then you will have some remaining characters at the end that are not one whole block. So lets say that the block length is L and you have n characters. You can add at the end of your message L-n extra characters so that with those, ...


2

1) and 2) Either S0, or S1 is used for each 4-bit long part of block depending on key bits. 16 S-boxes are used in each round (because you split 64-bit-long block into 16 parts of length 4) of the Lucifer cipher, so each round needs a 2 byte long subkey. Example: 16 starting bits of the key (the first subkey): 0 0 1 0 1 1 1 1 0 0 1 0 1 0 0 1 (2 bytes ...


4

The obvious answer to your question is "yes". The kernel mode implementation pointed to by otus clearly shows that it can be done. That it can be done doesn't mean it gets done however. Many Google searches for sourcecode don't show any OpenSSL code that implements this functionality. In general, OpenSSL doesn't rely on the crypto code of the kernel. So, ...


0

I depends probably about your computer. If you are able to speed up AES with HW instruction then your computer has certainly a processor where the Intel AES-NI instructions are available. Also Camellia is less popular than AES so it will be maybe more difficult to find compliant HW for this. (Here an interesting paper which explains that HW accelerations ...


1

Remember that the initial value is split into two halves, and each half is shifted independently. If all the bits in each half are either 0 or 1, then the key used for any cycle of the algorithm is the same for all the cycles of the algorithm. This can occur if the key is entirely 1s, entirely 0s, or if one half of the key is entirely 1s or the other half is ...


4

Some amount of known or controlled plaintext is clearly required for the attacker to get the block cipher output. Actually, that's not much of an issue; we can often get a reasonable amount of known plaintext from real encrypted messages. In fact, the known plaintext for each message doesn't have to be the same, and you don't have to have completely ...


4

One of the basic security requirements of a block cipher mode of operation is that it is indistinguishable under chosen plaintext attack (IND-CPA). Essentially, this means that, if an attacker chooses two messages $m_A$ and $m_B$ and the defender randomly returns either $\text{Encrypt}(K, m_A)$ or $\text{Encrypt}(K, m_B)$ (with $K$ kept secret from the ...


1

You do not get semantic security; a chosen plaintext attack can (with high probability) distinguish this mode from random. Consider the case where you are encrypting a two block message $(B, B \oplus 1)$ (for an arbitrary value B). Then, if IV (which I assume is selected randomly) happens to have an lsbit of 0 ($p = 0.5$), then the two ciphertext blocks ...


1

In essence it seems to be a sort of mixture of CFB and CTR. I see a possible issue where encrypting sequential values will show up as repeating patterns in the ciphertext. Consider the following 4 bit example. $$PT_0 = 1010$$ $$PT_1 = 1011$$ $$PT_2 = 1100$$ $$PT_3 = 1101$$ $$IV = 1110$$ Assuming $PB$ is the plaintext block directly before encryption. ...


4

What you are looking for is a definition of PEM, privacy enhanced mail. Obviously PEM is not just used for mail anymore. The definition of the header lines seems to be best described by section 4.6: "Summary of Encapsulated Header Fields" of RFC 1421: "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication ...


1

As fgrieu hints at in the comments, it is not in general possible to find $\operatorname{Enc}$. Otherwise you would be able to break an arbitrary block cipher, because the key of any block cipher can be cast as part of the algorithm instead. Even if you ignore the computational cost, there is no way to find $\operatorname{Enc}$ given values for only one ...


1

I am afraid there are no efficient methods of knowing the padding methods deployed unless it is specifically provided by description from whomever authored the original codes. You have to try bruteforcing the padding scheme to estimate what padding schemes are used.


5

AES is a block cipher and would return wrong data when a wrong key is used. It only works on a single block of data (16 bytes). The default CBC mode of operation enables you to encrypt multiple blocks of data. The padding then enables you to encrypt plaintexts of arbitrary length. The padding has to be removed somehow after the decryption. You're seeing a ...


2

If you want to construct a PRF for arbitrarily-long inputs using AES, then just use CBC-MAC (while prepending the message length in the first block). I don't see any advantage in what you are proposing and therefore don't see any point in trying to analyze something non-standard.



Top 50 recent answers are included