-
@freemindtronic Votre implémentation n’est **PAS** valable.Permalink On twitter.com
Mood 0
-
@freemindtronic 1- vous utilisez NFC qui est **NOTOIREMENT** pété. Vous ne pouvez donc pas justifier de votre sécurité par l’usage de NFC.Permalink On twitter.com
Mood 0
-
@freemindtronic 2- Vous devez donc apporter vos arguments crypto comme quoi la sécurité de la com’ ne repose pas sur celle de NFCPermalink On twitter.com
Mood 0
-
@freemindtronic 3- Ça signifie donc que vous devez prouver que votre chiffrement sur le canal NFC est conforme aux exigences cryptoOn twitter.com
Mood 0
-
@freemindtronic 4- Vous utilisez AES sur ce canal, vous devez donc prouver que vous implémenter AES correctement.Permalink On twitter.com
Mood 0
-
@freemindtronic 5- Ça veut dire que vous devez prouvez que votre clef et votre IV est 5.1: non réutilisé 5.2: à forte entropie 5.3: non anticipable en gros que ça sort d’un CSPRNG et non réutiliséPermalink On twitter.com
Mood -3 🙁
-
@freemindtronic Si vous ne prouvez pas ça, par un papier scientifique (et pas un fucking brevet sans aucun algo dedans) à revue par les pairs, alors votre système n’est *PAS* fiable. Jusqu’à preuve du contraire.Permalink On twitter.com
Mood -4 🙁
-
@freemindtronic Ça impose aussi de commencer par définir un modèle de menace. On se protège de quoi ? Dans quels conditions ? Quels moyens a l’attaquant ? C’est la NSA ou mon collègue de boulot ? A-t-il des capacités d’attaque offline (ie accès au device)Permalink On twitter.com
Mood -4 🙁
-
@freemindtronic Sans modèle de menace, c’est de toute façon simple : aucun système n’est 100% robuste à 100% des attaques.Permalink On twitter.com
Mood -2 🙁