# Tag Info

-1

In handshake process it will always not be a case that key exchange protocol will be diffie-hellman, it could be RSA also. yes I agree, that public part of key exchange protocol are being exposed, but one can not directly communicate with server from MAC part. It has to go step by step. And for every handshake server also provides session ID which will give ...

1

It is not hard to construct a secure MAC where $f(k) = \textsf{MAC}(k,0)$ is not one-way. Take any secure $\textsf{MAC}$ and define a new one as $$\textsf{MAC}^*\Bigl( (k_1,k_2), m \Bigr) = \textsf{MAC}(k_1,m) \oplus k_2.$$ It should be relatively clear that $\textsf{MAC}^*$ is also a secure MAC. Now given arbitrary $m$ and $t$, it is easy to find a key ...

1

If a PPT adversary can influence the key of a MAC function, is it still secure? In general probably no if you make no restrictions on the ways the key can be influenced. In particular the answer is "no" when you rely on your MAC actually being a PRF for your security proof (like HMAC does). This means that if your MAC relies on this then you need some ...

1

I want to know if the following would also be equally secure Yes, both schemes are equally secure. Also for what you are trying to achieve you really shouldn't puzzle things together yourself but rather use pre-made modes like AES-GCM, AES-EAX or ChaCha20-Poly1305. In fact, we can prove the above claimed security equivalence. Because Encrypt-then-MACis ...

Top 50 recent answers are included