Je viens de me replonger dans le code, et je constate qu'il y a clairement une faiblesse au niveau de la taille de la clé. Ça m'emmerde un peu de le constater moi-même, mais il est évidant qu'il serait possible de brute-forcer les données partielles en réunissant par exemple 30 qrcodes sur 32, puisque dans ce cas là chaque qrcode contiennent 1 octet de la clé de chiffrement...
Je ne comprends pas moi-même comment j'ai pu laisser passer une telle aberration sachant que 32 octets sont réservés sur chaques qrcodes, il serait tout à fait possible de généré une clé de chiffrement à 32 * n qrcodes sans revoir le format des données.
Je vais travailler à corriger ça, la prochaine version aura bien 32 octets de données de clé sur chaque qrcode, ce qui devrait rendre le format bien plus solide que ce qu'il est maintenant.
[^] # Re: Méthod de Shamir
Posté par Anonyme . En réponse au journal QRaidCODE, stocker des données sécurisée sur qrcodes. Évalué à 1.
Je viens de me replonger dans le code, et je constate qu'il y a clairement une faiblesse au niveau de la taille de la clé. Ça m'emmerde un peu de le constater moi-même, mais il est évidant qu'il serait possible de brute-forcer les données partielles en réunissant par exemple 30 qrcodes sur 32, puisque dans ce cas là chaque qrcode contiennent 1 octet de la clé de chiffrement...
Je ne comprends pas moi-même comment j'ai pu laisser passer une telle aberration sachant que 32 octets sont réservés sur chaques qrcodes, il serait tout à fait possible de généré une clé de chiffrement à 32 * n qrcodes sans revoir le format des données.
Je vais travailler à corriger ça, la prochaine version aura bien 32 octets de données de clé sur chaque qrcode, ce qui devrait rendre le format bien plus solide que ce qu'il est maintenant.