11 research outputs found

    Tweaking Generic OTR to Avoid Forgery Attacks

    Get PDF
    This paper considers the security of the Offset Two-Round (OTR) authenticated encryption mode \cite{cryptoeprint:2013:628} with respect to forgery attacks. The current version of OTR gives a security proof for specific choices of the block size (n)(n) and the primitive polynomial used to construct the finite field F2n\mathbb{F}_{2^n}. Although the OTR construction is generic, the security proof is not. For every choice of finite field the distinctness of masking coefficients must be verified to ensure security. In this paper, we show that some primitive polynomials result in collisions among the masking coefficients used in the current instantiation, from which forgeries can be constructed. We propose a new way to instantiate OTR so that the masking coefficients are distinct in every finite field F2n\mathbb{F}_{2^n}, thus generalising OTR without reducing the security of OTR

    Forgery attacks on ++AE authenticated encryption mode

    Get PDF
    In this paper, we analyse a block cipher mode of operation submitted in 2014 to the cryptographic competition for authenticated encryption (CAESAR). This mode is designed by Recacha and called ++AE (plus-plus-ae). We propose a chosen plaintext forgery attack on ++AE that requires only a single chosen message query to allow an attacker to construct multiple forged messages. Our attack is deterministic and guaranteed to pass ++AE integrity check. We demonstrate the forgery attack using 128-bit AES as the underlying block cipher. Hence, ++AE is insecure as an authenticated encryption mode of operation

    Forgery attacks on ++AE authenticated encryption mode

    No full text
    In this paper, we analyse a block cipher mode of operation submitted in 2014 to the cryptographic competition for authenticated encryption (CAESAR). This mode is designed by Recacha and called ++AE (plus-plus-ae). We propose a chosen plaintext forgery attack on ++AE that requires only a single chosen message query to allow an attacker to construct multiple forged messages. Our attack is deterministic and guaranteed to pass ++AE integrity check. We demonstrate the forgery attack using 128-bit AES as the underlying block cipher. Hence, ++AE is insecure as an authenticated encryption mode of operation

    A fundamental flaw in the ++AE authenticated encryption mode

    No full text
    In this article, we analyse a block cipher mode of operation for authenticated encryption known as ++AE (plus-plus-AE). We show that this mode has a fundamental flaw: the scheme does not verify the most significant bit of any block in the plaintext message. This flaw can be exploited by choosing a plaintext message and then constructing multiple forged messages in which the most significant bit of certain blocks is flipped. All of these plaintext messages will generate the same authentication tag. This forgery attack is deterministic and guaranteed to pass the ++AE integrity check. The success of the attack is independent of the underlying block cipher, key or public message number. We outline the mathematical proofs for the flaw in the ++AE algorithm. We conclude that ++AE is insecure as an authenticated encryption mode of operation

    Tweaking generic OTR to avoid forgery attacks

    Get PDF
    This paper considers the security of the Offset Two-Round (OTR) authenticated encryption mode [9] with respect to forgery attacks. The current version of OTR gives a security proof for specific choices of the block size (n) and the primitive polynomial used to construct the finite field F2n. Although the OTR construction is generic, the security proof is not. For every choice of finite field the distinctness of masking coefficients must be verified to ensure security. In this paper, we show that some primitive polynomials result in collisions among the masking coefficients used in the current instantiation, from which forgeries can be constructed. We propose a new way to instantiate OTR so that the masking coefficients are distinct in every finite field F2n, thus generalising OTR without reducing the security of OTR

    Fault attacks on XEX mode with application to certain authenticated encryption modes

    Get PDF
    The XOR-Encrypt-XOR (XEX) block cipher mode was introduced by Rogaway in 2004. XEX mode uses nonce-based secret masks (L) that are distinct for each message. The existence of secret masks in XEX mode prevents the application of conventional fault attack techniques, such as differential fault analysis. This work investigates other types of fault attacks against XEX mode that either eliminate the effect of the secret masks or retrieve their values. Either of these outcomes enables existing fault attack techniques to then be applied to recover the secret key. To estimate the success rate and feasibility, we ran simulations for ciphertext-only fault attacks against 128-bit AES in XEX mode. The paper discusses also the relevance of the proposed fault attacks to certain authenticated encryption modes based on XEX, such as OCB2, OTR, COPA, SHELL and ElmD. Finally, we suggest effective countermeasures to provide resistance to these fault attacks

    A fault-based attack on AEZ v4.2

    No full text
    This paper investigates differential fault attacks against AEZ v4.2 authenticated encryption scheme. AEZ uses three different 128-bit keys (I, J, L) and can potentially work without a nonce or with a repeated nonce. Under these conditions, this paper identifies the best place to apply differential fault attacks. We exploit the structure of AEZ to minimise the total number of faults required for key recovery. We propose an approach that can reduce the number of fault injections required to retrieve all three AEZ keys, I, J and L, from six to four such that these keys are uniquely determined. As a second step, we further reduce the fault injections to three without reducing the success rate of the key recovery attack. This improvement to differential fault attacks on AEZ makes these attacks more practical. The attacks in this paper are verified experimentally using a generic implementation of AEZ v4.2 developed in C
    corecore