# Tag Info

4

You can get what you want programmatically. No special ciphers or modes needed. You say there is a single, continuous subset that needs to be encrypted. Thus, you could have a function where the programmer specifies the start of the portion of the plaintext that needs to be encrypted and the number of bytes to encrypt. The function could pull that part out, ...

3

I am wondering if using Skein or the Keccak hash algorithm in this construction (as a stream cipher) is secure: In the case of Skein and Keccak it should be secure. However, both of those have defined their own cipher modes which you should IMO prefer. (For compatibility, if not security.) The Skein one is defined in section 4.10 of the paper. It uses ...

1

If you replace $H$ with a MAC that is build using $H$, i.e. NMAC, then it will be provably secure. Encryption will be $C_i = MAC_k(IV | i) \oplus P_i$. You are guaranteed by the MAC security property (existential forgery) that an adversary cannot generate any of the key stream on his own and so you are left with a secure stream cipher. Just using $H$ by ...

2

On your earlier questions: 1) How secure is this method for generating one-time pads in block- or stream-ciphers? This method in itself is not secure, as the output weakly random entropy source, not a TRNG; there is entropy in the keystrokes, but without any whitening and extraction taking place, the output is - for instance - not well distributed. The ...

3

As correctly pointed out in a comment, the authenticated encryption model assumes that the attacker knows the algorithm; the attacker can query the encryption oracle with any plaintext $P$ (and a unique nonce $N$) and get MAC-then-Encrypt ciphertext $C$; the attacker can query the decryption oracle with any string $C$ pretending to be a ciphertext. No ...

Top 50 recent answers are included