Skein or Keccak stream cipher construction I am wondering if using Skein or the Keccak hash algorithm in this construction (as a stream cipher) is secure:


$H$ = Keccak or Skein hash with a 256 bit output
$K$ = The main 256 bit random key, pre-shared between sender and receiver
$K_M$ = A secondary 256 bit random key for creating the MAC, pre-shared between sender and receiver
$IV$ = A per message 256 bit random initialization vector, sent in the clear with the ciphertext and MAC
$i$ = counter starting at 0 for each message which increments by 1 every 256 bit block
$K_i$ = 256 bit block of the generated key for encrypting the corresponding 256 bit block of the plaintext $P_i$
$P_i$ = 256 bit block of the plaintext. The final plaintext block would be padded to the right with 0 bits, thus the 
final concatenated plaintext is a multiple of 256 bits and disguises the true plaintext length.
$C_i$ = 256 bit block of ciphertext
$|$ = concatenation
⊕ = XOR


Encryption:


$K_i$ = $H$($K$ | $IV$ | $i$)
$C_i$ = $K_i$ ⊕ $P_i$


MAC:


$H$($K_M$ | $IV$ | $C_i$ ... $C_n$)


I hope I explained that clearly. 

My other question:

Is there a particular attack on using the same key for encryption and MAC?
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 speed and compatibility, if not security.)


The Skein one is defined in section 4.10 of the paper. It uses the underlying primitive directly rather than hashing the key and nonce.
For Keccak the web site links to a separate paper on an authenticated encryption mode. It uses the sponge to squeeze a larger number of output bits, like the SHAKE modes of the hash function.


Alternatively, in the case of Keccak/SHA-3 you may want to use one of the SHAKE extendable output functions, which produce an arbitrarily long output stream. They may also be faster than repeated calls to the hash function.


  Is there a particular attack on using the same key for encryption and MAC?


You should make sure the MAC invocation can never match an encryption one. I.e. it is not possible for $K|IV|C$ to match any $K|IV|i$. Easiest would probably be to add a string to make them differ, like $H(K|\text{'E'}|IV|i)$ and $H(K|\text{'A'}|IV|C)$.

In that case the MAC and encryption are independent, and a known or chosen plaintext attack cannot leak any extra MAC values.



Generically, your construction is not necessarily secure. First a hash function doesn't have to be a secure MAC when you prepend the key. Second, a stream cipher must be a PRF, which is a stronger condition than unforgeability for a MAC.

For example, you could define a stupid MAC like: $MAC_k(m)||MAC_k(m)$ and it would be just as strong a MAC as the original, but would make a lousy stream cipher.

(In practice most MACs do seem to also claim to be PRF.)