Tag Info

New answers tagged

7

One obvious thing that it is vulnerable to a known plaintext attack that truncates the known message. This attack is quite simple; suppose the attacker knows a message $(P_1, P_2, ..., P_n)$ and the corresponding ciphertext $(C_1, C_2, ..., C_n, T)$ (using some IV; we don't care what it is). Here is how the attacker can generate a ciphertext that would ...


0

The really important thing is, not encrypt-and-mac. The other two, you can debate, but both are at least theoretically sound -- one might just practically be better than the other. Encrypt-and-MAC falls apart for a very simple reason, though: the MAC is not meant to keep the plaintext secret. The MAC is based on the plaintext. Authentication is not designed ...


0

Yes, I don't see why this scheme would not be secure. It uses a MAC over known data - protected against replay. If that data is received or calculated locally shouldn't matter. But as you already showed yourself, you bring down the security of the tag with the amount of bits required to calculate the options. So in the end you could as well just CTR-encrypt ...


0

I understand the system as follows: data blocks are enciphered per AES-CTR, using key encryption_key, with an IV made by concatenating device_id and a counter held in Flash or EEPROM, incremented at each use; that enciphered data is integrity-protected by a 256-bit mac_tag computed using HMAC-SHA256 and mac_key. That's theoretically sound if device_id ...


1

There are two parts to this proposal: the use of a code book and a scheme to send short confidential and authenticated messages utilising an existing shared symmetric key. A code book can be used alone to provide a degree of confidentiality, or can be used to ascribe specific pre-agreed meanings to short messages, in combination with any scheme for sending ...



Top 50 recent answers are included