No haría esto y no entiendo qué problema estás tratando de resolver (a menos que sea una pregunta puramente académica).
Encrypt-then-MAC donde definimos ciphertext=encrypt(K_enc, msg) y el envío ciphertext||MAC(K_mac, ciphertext) detectará cualquier error de transmisión o manipulación malintencionada por alguien que no conozca la clave MAC secreta K_mac con una probabilidad abrumadora; por ejemplo, si usó un MAC de 80 bits, la probabilidad de manipular un mensaje y hacer que el MAC pase es 1 en 2 ^ 80 ~ 8 x 10 ^ -25, lo cual es insignificante. Por ejemplo, si alguien genera un billón mensajes falsos cada segundo, pasarán unos 3,2 millones de años antes de que tengan un 8% de probabilidad de una falsificación exitosa (o unos 26 millones de años antes de que tengan un 50%). posibilidad de una sola falsificación exitosa).
Por lo tanto, el MAC de 80+ bits proporciona una gran seguridad contra falsificaciones exitosas o errores de transmisión por sí mismo.
Mientras tanto, el hash CRC32 no criptográfico no criptográfico de 32 bits no proporciona ninguna verificación de integridad adicional contra alguien que manipula deliberadamente un mensaje de texto sin formato que puede adivinar, al menos con cifrados de flujo (o cifrados de bloque que actúan como un cifrado de flujo) como CTR o el teclado de una sola vez) donde XORAR un cambio en el texto cifrado modifica los mismos bits en el texto plano. Por ejemplo, como los CRC32 no implican ningún secreto, pueden adivinar el mensaje original m , calcular su CRC32, tomar su mensaje intencionado deseado m' y calcular su CRC32, y luego modificar el texto cifrado en tránsito al c' = c XOR (m || CRC32(m)) XOR (m' || CRC32(m')) . Por supuesto, el MAC con clave proporcionado por el cifrado autenticado evita este ataque. Sin embargo, si tuviera una implementación incorrecta que dijera que proporcionó información (ya sea a través de un mensaje de error o cambio en el tiempo) de una diferencia entre el MAC que falla y el CRC32 que falla o cuando el MAC falla y el CRC32 pasa, debilitaría la seguridad de su sistema (y los atacantes podrían explotar esto).
La única protección contra la que el CRC32 podría protegerse es la corrupción accidental de la memoria en su computadora entre el cálculo del CRC32 del mensaje de texto sin formato y el cifrado de dicho mensaje, aunque la posibilidad de que eso suceda también es insignificante.
En resumen, si esto se implementa de manera deficiente (por ejemplo, el atacante puede darse cuenta de que el CRC falló / pasó incluso cuando falló el MAC), esto puede filtrar información. Si esto se implementa a la perfección, no brindaría ninguna seguridad adicional, ya que el MAC con clave es la parte que frustraría a un manipulador dedicado.