Discussion :

[François DORIN]

Bonjour à tous,

Je viens de constater quelque chose qui m'étonne. La fonction DECRYPTBYPASSPHRASE n'est pas déterministe, empêchant ainsi son utilisation dans une vue indexée par exemple.

J'avoue être très surpris de cet état de fait et aimerait savoir si quelqu'un sait le pourquoi de la chose ? Autant pour ENCRYPTBYPASSPHRASE je le conçois parfaitement, autant pour DECRYPTBYPASSPHRASE c'est inquiétant car c'est une fonction de déchiffrage...

[SQLpro]

C'est parfaitement normal... Si vous connaissez l'historique du cassage de code par Turing à Bletchley, vous devriez savoir que la plus simple attaque pour déchiffrer est celle par analyse fréquentielle.

Connaissant la fréquence des noms des personnes, vous pourriez en déterminer la clef !!!!

Donc, SQL Server auto sale les cryptogramme de manière à éviter de casser le code.

Néanmoins, il vous reste "allwaysEncrypted" qui supporte une méthode non salée....

A +

[François DORIN]

Merci pour la réponse, mais je crois qu'on ne s'est pas compris. Que le chiffrement ne soit pas déterministe, j'en convient parfaitement (notamment pour la raison que tu cites).

Mais le déchiffrement ?

Néanmoins, il vous reste "allwaysEncrypted" qui supporte une méthode non salée....

Malheureusement non. Always Encrypted n'est disponible qu'à partir de la version 2016 de SQL Server. Je suis actuellement bloqué sur une version 2012. Et je ne peux pas installer une version ultérieure car c'est dans le domaine de la santé (donc avec un hébergement agréé de santé) et que le serveur est bloqué sur Windows 2008r2 à cause des logiciels de supervision...

Pourtant, j'ai déjà demandé des devis pour une monté en gamme. La temporalisation des données m'intéresse fortement par exemple !

[SQLpro]

Merci pour la réponse, mais je crois qu'on ne s'est pas compris. Que le chiffrement ne soit pas déterministe, j'en convient parfaitement (notamment pour la raison que tu cites).

Mais le déchiffrement ?

C'est pareil puis que la fonction d'entrée n'est pas déterministe, celle de sortie (fonction inverse) non plus, car il faut désaler. Elle ne dépend donc pas seulement du cryptogramme et de la clef mais d'un facteur complémentaire non présent en tant qu'argument de la fonction et donc susceptible de varier !

A +

[François DORIN]

C'est pareil puis que la fonction d'entrée n'est pas déterministe, celle de sortie (fonction inverse) non plus

Euh... Ca c'est du n'importe quoi. Désolé de te le dire

La fonction "inverse" peut très bien être déterministe alors que la fonction initiale ne l'est pas. Plutôt qu'un long discours, voici deux fonctions qui illustre mes propos :

Exemple tout bête :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
CREATE OR ALTER FUNCTION F(@Str VARCHAR(50)) RETURNS VARCHAR(54)
AS BEGIN
   RETURN SUBSTRING(CONVERT(VARCHAR(50), HASHBYTES('MD5', CONVERT(VARCHAR(50), SYSDATETIME())), 1), 1 ,4) + @Str;
   END
GO
CREATE OR ALTER FUNCTION F_inv(@Str VARCHAR(50)) RETURNS VARCHAR(50)
AS BEGIN
   RETURN SUBSTRING(@Str, 5, LEN(@Str) - 4);
END

f n'est pas déterministe (elle ajoute 4 caractères aléatoires), tandis que f_inv (qui retire les caractères) l'est !

, car il faut désaler. Elle ne dépend donc pas seulement du cryptogramme et de la clef mais d'un facteur complémentaire non présent en tant qu'argument de la fonction et donc susceptible de varier !

Je pense tu ne t'es pas relu, car ce que tu dis implique :

• qu'une chaîne encodée via ENCRYPTBYPASSPHRASE n'est garantie d'être déchiffrable que sur la base de données où elle a été chiffrée (l'aspect facteur complémentaire);
• qu'une chaîne chiffrée peut demain ne plus être déchiffrable (car le facteur complémentaire est susceptible de varier) !

Et heureusement que ni l'un ni l'autre n'est vrai !


Je suis 100% d'accord pour dire que l'opération de salage créé de l'indéterminisme (et donc que l'opération de chiffrement soit non déterministe). Par contre, pour l'opération inverse non, car si c'était le cas, alors cela sous-entendrait que la valeur obtenue après déchiffrement puisse être différente de la valeur initiale ! D'où mon incompréhension sur le fait que la fonction DECRYPTBYPASPHRASE soit non déterministe. Pour expliquer cela, je vois deux cas possibles :

• il y a une raison qui m'échappe, car mathématiquement parlant, la fonction doit être déterministe
• il s'agit d'une "erreur" (parler d'un bug serait peut être un peu fort) liée à la définition de la fonction (par exemple, les fonctions CLR peuvent être définies comme déterministe ou non via l'ajout d'un simple attribut sur une méthode)

[François DORIN]

Après une rapide discussion sur les forums Microsoft, le MVP Ronen Ariely me confirme que la fonction devrait être déterministe et a ouvert un rapport de bug pour interroger l'équipe de développement de SQL Sever. Il est disponible ici : https://connect.microsoft.com/SQLSer...-deterministic