Transferência de chave simétrica para chave assimétrica

Question

Não sou um especialista em criptografia; na verdade, só tenho um pouco de experiência em usá-la.De qualquer forma, chegou o momento em que um dos meus aplicativos exige que eu tenha alguma criptografia configurada.Observe que o programa não gerenciará nada supercrítico que possa causar muitos danos.

De qualquer forma, eu estava apenas tentando ver se esse esquema que estou usando é comum e se há falhas (das quais pode haver um design completamente estúpido e terrivelmente defeituoso, é por isso que estou perguntando).

Ok, tenho uma comunicação cliente -> servidor.O Cliente I pode codificar na parte pública de uma chave RSA de 2.048 bits.Quando o cliente deseja iniciar uma conexão segura, ele envia seu nome de usuário, hash md5 de sua senha e um hash de um UUID aleatório, todos criptografados com a chave pública do servidor.O servidor recebe as informações e descriptografa usando sua chave privada.Verifica o banco de dados para ver se seu login + senha funcionam e, se funcionarem, cria uma nova entrada na tabela "Sessões" do banco de dados.Isso inclui um SessionID, UID (ID do usuário) e o hash UUID.Usando o UUID do ID da sessão correspondente como a frase -chave, o servidor enviará de volta uma mensagem que tem a palavra criptografada "Sucesso!" + Um UUID aleatório (esta mensagem é assinada digitalmente para que possamos determinar se ela veio do servidor ou não).A partir desse ponto, quando o cliente enviar informações para o servidor, ele será com um sess_id em texto simples e incluirá uma mensagem criptografada Blowfish, usando o segredo blowfish do ID de sessão correspondente (armazenado criptografado no banco de dados) como chave para criptografar/descriptografar.

Especificamente, estou curioso para saber se este sistema "deveria funcionar" ou se alguém percebe que é evidente que existe uma vulnerabilidade, como o MITM.

Answer 1

Questões que posso ver de cara (embora você tenha deixado de fora a maioria dos detalhes, que é onde o diabo reside):

• Se você estiver usando um gerador UUID em vez de um RNG criptográfico real, provavelmente ele terá entropia insuficiente.Não descarte isso - no mundo real, a forma preferida de enfraquecer secretamente um sistema de criptografia tem sido enfraquecer o RNG;

• Sua criptografia RSA inicial parece ser suscetível a um ataque de pequeno expoente e, potencialmente, a outros ataques criativos.Há muita estrutura lá para ser confortável;

• Parece que existem inúmeras oportunidades para ataques de repetição;

• Qual modo de cifra de bloco você está usando com Blowfish?

Eu recomendo usar TLS/SSL - ele tem olhos muito mais amigáveis ​​olhando para ele por muito mais tempo do que qualquer coisa que você mesmo construa.

Answer 2

Basta usar SSL ou DTLS, IKEV2, HIP, EAP ou algum protocolo padrão adequado. Não tente inventar seus próprios protocolos de criptografia, ninguém tem experiência suficiente para fazer isso por conta própria. Seu protocolo não tem entropia suficiente, até onde posso ver, então suas chaves resultantes serão bastante fracas.

Answer 3

A partir desse ponto, quando o cliente envia informações para o servidor, ele será com um texto simples sess_id e incluir uma mensagem criptografada de Blowfish, usando o ID da sessão correspondente como a chave para criptografar / descriptografar.

Se você está enviando o ID da sessão no texto sem formatação e usando -o como chave de criptografia, como isso é seguro?

Não vejo razão para que você não possa usar a autenticação SSL padrão e deixar o implementador da biblioteca se preocupar com o handshaking.