Quel algorithme Blowfish est le plus 'correct'?

Question

Je cours Windows Server 2k8 (peut-être que c'est la moitié du problème?) De toute façon, je reçois différentes valeurs de différents modules Blowfish dans diverses langues. Y en a-t-il un qui puisse être utilisé comme standard? Pour les exemples suivants, supposons que la clé est password et le texte en clair 12345678.

a. Le Online Encrypt Tool avec l'algorithme défini sur Blowfish mode ECB et Base64 Encode the output vérifié donne 2mADZkZR0VM=. J'ai utilisé ceci un point de référence, sage ou autre.

b. Le code suivant Perl utilise Crypt::ECB et MIME::Base64

use MIME::Base64; 
use Crypt::ECB; 
$crypt = Crypt::ECB->new; 
$crypt->padding(PADDING_NONE); 
$crypt->cipher('Blowfish') || die $crypt->errstring; 
$crypt->key('password'); 
$enc = $crypt->encrypt("12345678"); 
print encode_base64($enc); 

Ce sorties 2mADZkZR0VM= avec PADDING_NONE (qui compare bien avec 'a.' Ci-dessus). Toutefois, lorsque le remplissage est défini sur PADDING_AUTO, il génère 2mADZkZR0VOZ5o+S6D3OZw==, ce qui est, à mon avis au moins, un bogue car le texte en texte brut comporte 8 caractères et n'a pas besoin de remplissage.

c. Si j'utilise Crypt::Blowfish comme ci-dessous

#! c:\perl\bin 
use Crypt::Blowfish; 
use MIME::Base64; 

my $key; 
my $plaintext; 

$key = "password"; 
$plaintext = "12345678"; 

my $cipher = new Crypt::Blowfish $key; 
my $ciphertext = $cipher->encrypt($plaintext); 
my $encoded = encode_base64($ciphertext); 
print $encoded; 

je reçois 2mADZkZR0VM= qui correspond 'a.' au dessus. Le problème avec ce module est que l'on doit segmenter les choses en morceaux de 8 octets pour l'encodage; il n'a pas de chunker de son propre chef.

d. Si j'utilise la source à http://linux.die.net/man/3/bf_ecb_encrypt (ce que j'ai fait pour un projet PHP récent), alors j'ai la même réponse que 'a.'. Je suis enclin à faire le plus confiance à ce code tel qu'il est utilisé dans SSLeay et OpenSSL.

e. Le BlowfishEx.EXE dans le Blowfish: a Visual Basic version de la gestion de DI avec le remplissage PKCS#5 donne 2mADZkZR0VOZ5o+S6D3OZw== qui est le même que les résultats de Crypt :: ECB avec PADDING_AUTO. Avec Rembourrage réglé sur None, j'obtiens 2mADZkZR0VM= qui correspond à 'a.'

J'ai partiellement répondu à ma propre question en écrivant ceci: il me semble qu'il me suffit de modifier le code de DI Management pour le projet VB6. Et peut-être suggérer la même chose à l'auteur de Crypt :: ECB.

Mais la question demeure: existe-t-il une plateforme de référence blowfish digne de confiance?

Answer 1

Votre problème ne semble pas être de savoir s'ils implémentent l'algorithme Blowfish correctement. Dans la variante "pas de remplissage", ils semblent tous produire des résultats identiques.

Cela laisse une question de savoir si une entrée de 8 octets devrait être complètement rembourrée. La réponse à cette question est assez simple: PKCS # 7 exige qu'il y ait toujours au moins un octet de remplissage ajouté à l'entrée. La raison en est simple: du côté de la réception, il doit y avoir un moyen non ambigu de retirer le rembourrage. Dans le cas de PKCS # 7, la valeur des octets de remplissage est toujours le nombre d'octets de remplissage qui doit être supprimé par le destinataire. Ainsi, lorsque vous recevez du matériel qui a été complété avec PKCS7, vous décryptez le bloc, puis regardez le dernier octet dans la sortie décryptée, et supprimez autant d'octets du bloc.Sans un bloc de rembourrage à la fin, le récepteur devrait normalement regarder le dernier octet des données réelles, et quelle que soit la valeur que cet octet contenait, enlever autant d'octets (bien qu'il devrait probablement vous dire qu'il y a un problème si le numéro est plus grand que 8). Dans tous les cas, pour assurer un fonctionnement correct, il doit toujours y avoir au moins un octet de rembourrage. Dans votre cas, cela signifie que l'entrée est étendue à 16 octets au lieu de 8.