syl a écrit 52 commentaires

Bravo pour ce journal qui nous éclairent sur un successeur (encore un ;-)) du couple fameux VHDL/Verilog.

Par contre, je suis surpris que ce langage prenne pour parti pris un tout-synchrone. J'ai certes arrêté la conception HW il y a quelques années, mais pour les designs complexe (au-delà de la dizaine de millions de portes), on parlait beaucoup de GALS (Globally Asynchronous Locally Synchronous). Comment un tel langage peut-il être compatible de ce paradigme ?

Je répond rapidement et dans le désordre.

IPsec c'est du pur symétrique. Pour la PFS, il faut de l'asymétrique (un échange Diffie-Hellman en l'occurence).

En ce qui concerne les clés IPsec, la PFS est apportée par IKE qui permet de négocier et mettre à jour les clés IPsec (quoiqu'une gestion manuelle est possible, bien qu'hardue). Il n'empêche qu'entre deux négociations IKE, plusieurs messages sont chiffrés avec la même clé dans une SA IPsec.

La clé privée ne chiffre rien du tout : DH et ses variantes sont des protocoles pour se mettre d'accord sur un secret commun. J'ai l'impression que tu mélanges un peu tout.

Ceci est mon dernier message sur le sujet, vu que ça commence à partir dans tous les sens.

Et cette borne est sûre.

Oups, je préfère préciser : cette borne est sûre avec des algorithmes et des modes à l'état de l'art (AES-CBC + HMAC-SHA256 ou AES-CCM, par exemple).

C’est complètement faux. Et c’est même l’inverse.

Merci. Ça fait plus de 10 ans que je travaille dans le domaine, il va donc me falloir tout revoir à la base :)

L’IV peut être une donnée publique

Où ai-je dis l'inverse ? Par définition il est publique puisqu'il est nécessaire pour déchiffrer. Il doit donc être transmis sur la ligne avec le message (dans le cas général, ici il n'y a pas de ligne puisque l'on protège des mots de passe).

c’est le couple clef+iv qui doit être unique lors du chiffrement

C'est bien ce que j'ai dit ci-dessus.

La clef de chiffrement, elle, doit bien être unique, d’autant plus que certains algos ne nécessitent pas d’IV (RC4, le mode ECB ou CTR de AES, …).

Effectivement, on peut parler de vieux algorithmes (RC4) ou encore de modes à bannir (ECB)…
Plus sérieusement, la même clé peut être utilisée pour chiffrer différent messages tant que l'IV pour un message donné n'a pas déjà été utilisé par un autre message chiffré avec la même clé.

La règle générale est donc clef à usage unique par défaut.

Cela signifie donc que TLS, IPsec et la plupart des protocoles de sécurité ne sont pas sûr, c'est bien ça ?
Parce que ces protocoles chiffrent bien plusieurs messages avec la même clé, qui est mise à jour régulièrement mais pas à chaque message. Par exemple, IPsec permet de chiffrer jusqu'à 2⁶⁴ messages avec la même clé. Et cette borne est sûre.

Réutiliser une clé n'est pas une erreur grave, tant que le service est le même (par exemple, une clé utilisée pour chiffrer toutes les autres).
Par contre réutiliser un IV est une erreur grave. Tous les couples (clé,IV) doivent être différents. On peut donc utiliser une IV I une fois avec la clé K1 et une fois avec la clé K2 mais jamais deux fois avec la même clé.

Une autre chose importante : toujours utiliser un chiffrement intègre. Par exemple CBC + HMAC, ou mieux un mode combiné comme CCM ou GCM. Attention cependant dans le premier cas (utilisation d'un mode de confidentialité et un mode d'intégrité) : les clés doivent être différentes (services différents), et l'intégrité doit être calculée sur le chiffré, et non sur le clair.

La propriete d'un IV en crypto c'est 'que sa valeur ne doit pas etre predictible pour un adversaire au moment de l'operation de chiffrement'. La ce n'est clairement pas le cas… c'est au mieux un 'nonce'/sel.

C'est effectivement le cas pour le mode CBC, par exemple.

Cependant, le mode CTR (et donc GCM dont la partie confidentialité est un mode CTR), la non-prédictibilité n'est pas nécessaire : l'IV doit juste être unique. C'est D'ailleurs ce qui est dit dans le §8 de la spécification GCM (le mode d'incrément de l'IV est même proposé comme une des 2 façons de construire un IV, cf. §8.2.1).

Une bonne façon de réduire la taille des clés, c'est d'utiliser les algorithmes de signature sur courbes elliptiques. Là, une clé de 256 bits est largement suffisante.

On y gagnerait non seulement en taille de clé mais aussi en temps de calcul.

Dans le public, les CDD peuvent faire jusqu'à 3 ans. De plus, tu peux cumuler les CDD jusqu'à 6 ans. Au delà, tu passes en CDI (ou t'es viré avant).
Enfin, cette barre de 6 ans n'existe que depuis 2005. avant, on pouvait enquiller les CDD avec le même employeur public pendant toute sa carrière. Ce changement a été imposé à la France par la Cour de Justice Européenne.

Pour ma part, ça fait 10 ans que je suis contractuel dans la fonction publique.

Les « biens à double usage » sont ceux qui peuvent être utilisés pour une utilisation civile ou une utilisation militaire.

Les moyens de cryptologie sont considérés comme biens à double usage, et même comme des armes de guerre de 2ème catégorie (d'où la restriction à l'export).

ECDSA, c'est un algorithme de signature (Elliptic Curve Digital Signature Algorithm). La signature permet de s'assurer de la provenance d'un message (tel message a bien été écrit par telle personne) mais en aucun cas de protéger son contenu.

Je te parle de prix de puces et tu me parles de prix de cartes. Effectivement, ça na rien à voir. S'ils utilisent un ASIC, ils devront faire une carte sur mesure pour l'intégrer. Ils peuvent aussi le faire pour un FPGA.

Une puce de téléphone portable avec une centaine de millions de transistors, coute entre 20$ et 40$, certes elles sont produit en millions d'unités.

C'est quand même ce qui fait la différence. Et avec la somme annoncée (300 000 €), ils ne produiront pas beaucoup de pièces. De plus, si tu parles de l'OMAP de TI (Texas_Instruments), il me semble que la production, c'est plutôt plusieurs dizaines (et j'ai un doute sur « centaines ») de millions d'unités.

D'ailleurs, au sujet de l'OMPA, une petite anecdote :
J'ai participé à une conf de Ahmed Amine Jerraya qui citait ce composant en exemple de la limite de ce qui était concevable : un composant qui a « coûté » 1000 hommes.an (!), qui a une architecture extrêmement complexe, qui est très gros donc pratiquement impossible à rentabiliser, et pourtant, TI en a vendu des dizaines (des centaines, je ne me rappelle plus ce que Jerraya a dit exactement) de millions. Mais pour lui, cela reste un exemple de ce qu'il ne faut pas/plus faire.

Je ne suis pas d'accord sur les deux process. Effectivement, on trouve pas mal de concepteurs qui utilise cette méthode mais, personnellement, je ne vois pas l'intérêt d'utiliser un process pour faire de l'asynchrone. Sans compter qu'il y a une troisième école : 3 process pour décrire une machine d'état : un process synchrone pour l'état, un process asynchrone pour faire évoluer l'état et un autre process synchrone pour les sorties. Mais après, les goûts et les couleurs....

Je ne comprends pas bien ta réponse. C'est la taille du projet qui fait qu'une matrice coûte 500 € (?) ou alors tu veux dire qu'opengraphics est obligé d'utiliser plusieurs matrices pour y intégrer son GPU ?

Sinon, pour 50 € pièce pour une filière ASIC, ça m'intéresse d'avoir plus d'infos : combien de pièces seront produites, sur quelle techno (donc avec quel ticket d'entrée), combien de puces par wafer, surface de la puce, etc...

Ah oui, les prédiffusés (les cellules sont pré-existantes, ainsi que les premiers niveaux de métaux qui permettent d'alimenter ces cellules et de relier entre eux les différents transistors composant ces cellules. Ensuite, il reste juste à métalliser les derniers niveaux pour créer la fonction voulue). Je n'y avait pas pensé. Mais je ne pense pas que ce soit une bonne idée.

Ces technos ont toujours existé chez les fondeurs: cela permet de créer une puce sur mesure à moindre coût (mais au dépend de la performance). Je ne sais pas si cela est disponible sur les dernières technos (et ça m'étonnerait un peu, c'est un marché de niche et il ne permet donc pas de rentabiliser une usine à plusieurs milliards de dollar). Ces dernières années, elles sont un peu revenues en grâce, surtout à cause du gouffre énergétique que sont les FPGA. Mais à mon avis, cela n'est plus valable pour les toutes dernières technos de FPGA (Virtex 5 de Xilinx et Stratix IV d'Altera) qui se sont beaucoup améliorés sur l'aspect consommation (un FPGA consomme toujours énormément plus qu'un ASIC mais c'est beaucoup mieux que les générations précédentes).

Je me réponds à moi-même pour développer mon précédent commentaire, et pour dire pourquoi il me semble que fondre un ASIC n'est pas intéressant pour le projet Open Graphics. Pour cela, je vais détailler les flots de conception FPGA et ASIC.


FPGA

Au commencement, il y a la description du design (phase de codage, en fait). Celle-ci de fait au niveau RTL (Register_Transfer_Level) dans un langage de haut-niveau, dit HDL (Hardware Description Language). En Europe, on utilise plutôt le VHDL alors qu'en Amérique du Nord, on utilise plutôt le Verilog.
Puis, une fois la description terminée, on utilise un outil de simulation pour vérifier que cette description est correcte. À cette étape, on effectue une simulation dite « comportementale » : on cherche juste à vérifier que la description du design est correcte. À noter : le simulateur peut être le même quelque soit le flot (FPGA ou ASIC).

Ensuite, on rentre réellement dans le flot FPGA. Chaque fournisseur de FPGA propose ses propres outils mais tous les flots font : la synthèse (traduction de la description RTL en description plus bas niveau à l'aide des éléments de la bibliothèque du fournisseur (ces éléments sont les éléments de base du FPGA)), le placement-routage (placement : positionnement de chaque élément dans la matrice du FPGA, routage : choix du chemin des signaux (un signal relie la sortie d'un bloc à l'entrée d'un ou plusieurs blocs)) puis la génération du fichier de programmation (qui sera chargé dans le FPGA pour le personnaliser).

Avant de générer le fichier de programmation, on effectue en général une simulation dite « temporelle » : on utilise les informations de timings fournies par la phase de placement-routage pour vérifier que les signaux se propagent sans erreurs d'un élément à l'autre de la matrice (le cas typique d'erreur : le signal d'horloge arrive après la donnée sur un élément mémoire).

Coût du flot :
- flot propriétaire du fournisseur : quelques centaines d'euros
- coût unitaire d'un FPGA : pour les dernières technos et pour les grosses matrices, commandées en grosse quantité : de 100 à 300 €
- temps de développement : en général environ 12 mois


ASIC

Pour la première phase (description RTL), c'est la même chose que pour le FPGA sauf qu'on doit utiliser des éléments de la bibliothèque du fondeur pour les blocs durs (RAM, par exemple). En effet, ces blocs étant spécifiques à une techno, le fondeur fournit ses propres modèles comportementaux pour ces blocs. Et pour les utiliser, il faut avoir accès à sa bibliothèque, et pour cela, il faut avoir signer un NDA. A mon avis, ce NDA rend impossible la libération du code HDL utilisant les modèles du fondeur.

Pour la synthèse, il faut utiliser un outil de synthèse ASIC. Ces outils sont plus compliqués à utiliser que ceux pour FPGA (mais on a beaucoup plus de latitudes) et sont plus chers : il faut compter environ 100k€/an (les licenses sont valables pour un temps donné en CAO électronique).

Pour le placement-routage, cela devient compliqué : les outils sont très chers, et peu de personnes ont les compétences nécessaires pour effectuer ce travail. Cette phase est de plus en plus souvent sous-traiter aux fournisseurs d'outils ou aux fondeurs. Je ne sais pas évalué le prix de cette prestation mais je sais que le forfait journalier est très élevé (prestation de luxe).

Ensuite, vient le tour du fondeur. Celui-ci crée les masques à partir de la sortie de l'étape précédente. Un masque est la représentation géométrique pour un niveau de la puce. Sur les dernières technos, on compte facilement 40 niveaux de masque. Ce sont ces masques qui coûtent très chers à la fabrication (1 M€ le jeu de masques). Puis, à partir des masques, les puces sont gravées dans les tranches de silicium (wafers).

Coût du flot :
- outils : synthèse 100000€/an, P&R : je dirais 100000€ minimum pour cette phase
- fonderie : 1M€ + cout de production par lot (de quelques dizaines à quelques centaines de k€) -> plus on fabrique de composants, moins le coût unitaire est élevé. Dans le métier, on dit qu'il faut maintenant produire plusieurs millions de composants pour que cela soit rentable de faire un ASIC au lieu d'un FPGA sur les dernières technos.
- temps de développement : de 18 à 24 mois en général


Mon avis

Effectivement, pour un concepteur de circuit numérique, il est plus sympa de faire un ASIC qu'un FPGA (déjà, faire un ASIC, ça fait sérieux, alors que n'importe qui peut programmer un FPGA dans son garage ;-)) mais vu la faible quantité de puces qui seront fabriquées par le projet Open Graphics, il est, àmon avis, suicidaire de partir sur un flot ASIC. Il faut être réaliste : ils ne vendront jamais plusieurs millions de cartes (et donc autant de composants).

L'accès à une fonderie pour 300 K€ ? Ça me semble vraiment peu. Sur les dernières technos (type 65 nm et 45 nm), c'est plutôt 1 M€ juste pour les masques. Après, il faut rajouter quelques dizaines à quelques centaines de milliers d'euros par lot (un lot, c'est en général 25 wafers (galette de silicium) et le nombre de puces par wafer dépend de la taille de celles-ci).

J'infirme le fait qu'ils fabriquent leurs propres processeurs (je dirais plutôt composants cryptographiques, pour ma part) : la NSA possédait bien une fab mais elle vient de fermer. J'ai lu ça il y a quelques semaines dans un magazine professionnel genre EETimes mais je n'arrive pas à retrouver l'info...

Pour la NSA, tu es sur ?
En France, le Ministère de la Défense peut interrompre un dépôt de brevet en demandant la cession du brevet à l'Etat ou plus simplement en demandant la consession d'une license d'exploitation (Article R612-27 du Code de la Propriété Intellectuelle).
Il n'est pas dit que le Ministère doit avoir déjà déposer un brevet sur l'invention mais seulement qu'il peut se l'approprier (contre dédomagement, bien sur).

Zut, c'est le scrutin de mars.
Mea culpa

En 2 minutes, sur le site de l'Assemblée Nationale :

http://www.assemblee-nationale.fr/12/scrutins/jo0964.asp

Je pense que les mêmes infos sont disponibles sur le site du Sénat.

Finalement, ça fonctionne bien une fois que l'applet java est installée correctement ;-)
Elle était bien présente côté 64 bits mais pas dans le chroot. Une fois copier le fichier dans le chroot, tout c'est bien passé : j'ai enfin pu déclarer mes revenus.

On dit la DCSSI et non le DCSSI.
DCSSI = Direction Centrale de la Sécurité des Systèmes d'Information.
Elle dépend directement du Premier Ministre (http://www.ssi.gouv.fr/fr/dcssi/ ).

J'utilise firefox dans un chroot 32 bits (avec java installé) et ça plante au moment de signer la déclaration. C'est dommage...

En france, c'était les Cosmocats (http://fr.wikipedia.org/wiki/Cosmocats )

Et la fameuse greve du McDo st Michel a Paris ? C'est pas un resto le McDo ? En plus, cette greve a ete plutot longue, si mes souvenirs sont bons.