Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Authenticated Encryption should check for tag length

Aberta
#63 17 comentários 4 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
30/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
c, ruby

Direção de pesquisa

Comece rastreando o comportamento existente de Cipher#auth_tag e #final para AES-GCM, incluindo como CipherError é gerado atualmente. Revise o comportamento solicitado de auth_tag_len e os requisitos de documentação; em seguida, compare os caminhos de criptografia e descriptografia. O trabalho estará concluído quando a proposta de API estiver resolvida, os comprimentos das tags forem verificados conforme especificado e o comportamento relevante estiver documentado e coberto por testes.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

The current API for using ciphers with Authenticated Encryption (currently only AES-GCM) is rather misleading and quickly leads to subtle bugs related to the length of auth_tag.

In particular, the current implementation will not check for the length of the auth_tag. Because GCM mode allows arbitrary sizes of the auth_tag up to 128 bytes, only a single byte needs to be supplied to make the authentication pass. This means that an attacker needs at most 256 attempts in order to forge a valid auth_tag.

data = 'secret'

cipher = OpenSSL::Cipher.new('aes-128-gcm')
cipher.encrypt
key = cipher.random_key
iv = cipher.random_iv
cipher.auth_data = 'auth_data'
ciphertext = cipher.update(data) + cipher.final
auth_tag = cipher.auth_tag

auth_tag = auth_tag[0] # single byte is sufficient

cipher = OpenSSL::Cipher.new('aes-128-gcm')
cipher.decrypt
cipher.key = key
cipher.iv = iv
cipher.auth_tag = auth_tag
cipher.auth_data = 'auth_data'
data = cipher.update(ciphertext) + cipher.final

# NO error raised

Currently, the only way to prevent such attacks is to manually assert the correct auth_tag length when decrypting/authenticating.

raise 'incorrect auth_tag length' unless auth_tag.length == 16

I suggest the following improvements:

Documentation should mention the importance of manually checking auth_tag length

This can/should be done immediately even if the API should not change.

Authentication tag length should be an input parameter to the cipher

To improve the usability of the API and unburden users from performing additional manual checks without compromising security, I suggest to add an auth_tag_len accessor. This can be used to determine the size of the auth_tag both when generating and when authenticating the auth_tag. The default value should be 16 bytes (see below).

#auth_tag should use auth_tag_len to determine the output length

During encryption:

If no parameter is given, #auth_tag should return an authentication tag according to the length configured in auth_tag_len.

If a length parameter is given, #auth_tag should use the supplied parameter to determine the length of the authentication tag. Although this parameter is not as useful any more it should be kept for backwards compatibility. Maybe it should be deprecated.

Currently the API supports different tag lengths by passing the length parameter to #auth_tag. This currently defaults to 16 bytes, which should be the default value for auth_tag_len in order to keep backwards compatibility.

#final should use auth_tag_len to assert the correct length of the auth_tag

During decryption:

auth_tag_len should be used to assert that the supplied auth_tag has the correct length. The big difference to the existing API lies here, because users need to actively change the value of auth_tag_len in order to allow shorter tags.

When the check fails, an OpenSSL::Cipher::CipherError should be raised. The same type of error is already raised when authentication fails, so existing users should be fine without having to touch their error handling. A descriptive error message should be helpful. In order to distinguish between such errors and "actual" verification errors, we could also add a descriptive message for the latter.

I'd be happy to implement these changes, but I wanted to discuss them first.


For reference: This issue was copied over from the Ruby Issue Tracker https://bugs.ruby-lang.org/issues/12582

Linguagem predominante
C
Estrelas
276
Forks
201
Merge médio
1d 3h
PRs com merge (30d)
7

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de ruby/openssl

Todas as issues de ruby/openssl

Issues semelhantes

Mais issues de C

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.