Je voulais savoir si il existe une recommendation, ou une baffouille
pour : US Secure Hash Algorithm 1, sur les organismes ci-dessus ou si
ces derniers recommande un autre algo ?
( pour le hash biensur ! )
La denière fois que j'ai exploré le sujet des algorithmes de hash officiellement admis par la DCSSI, [...] les deux fonctions de hashage admises étaient [...] [...] SHA-1 et RIPEMD-160 [...]
Je conjecture que les algorithmes de la famille SHA-2 http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf seraient aussi admissibles en le demandant poliment, mais je n'ai pas d'exemple de produit certifié les utilisant.
En fait dans la mise à jour 1.1 du document suivant : http://www.ssi.gouv.fr/site_documents/politiqueproduit/Mecanismes_cryptographique_v1_10_standard.pdf la dcssi rejette maintenant l'utilisation de sha-1 dans les composants qualifiés au niveau standard (paragraphe C.3.1).
En pratique ça fait un certain temps que la cellule crypto fait la moue quand on lui parle de sha-1 et pousse au maximum vers sha-2.
Quand au produits certifiés utilisant sha-2, je vais parler ici de ce que je connais directement, soit celui-ci : http://www.ssi.gouv.fr/fr/confiance/certificats/certificat2006_06.html (l'utilisation de sha-256 est dans le rapport de certification)
A la demande de la DCSSI, le produit peut être configuré dans un mode où seule les signatures en sha-256 seront possibles.
Francois Grieu wrote:
La denière fois que j'ai exploré le sujet des algorithmes de hash
officiellement admis par la DCSSI, [...]
les deux fonctions de hashage admises étaient [...]
[...] SHA-1 et RIPEMD-160
[...]
Je conjecture que les algorithmes de la famille SHA-2
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
seraient aussi admissibles en le demandant poliment, mais je n'ai
pas d'exemple de produit certifié les utilisant.
En fait dans la mise à jour 1.1 du document suivant :
http://www.ssi.gouv.fr/site_documents/politiqueproduit/Mecanismes_cryptographique_v1_10_standard.pdf
la dcssi rejette maintenant l'utilisation de sha-1 dans les composants
qualifiés au niveau standard (paragraphe C.3.1).
En pratique ça fait un certain temps que la cellule crypto fait la moue
quand on lui parle de sha-1 et pousse au maximum vers sha-2.
Quand au produits certifiés utilisant sha-2, je vais parler ici de ce
que je connais directement, soit celui-ci :
http://www.ssi.gouv.fr/fr/confiance/certificats/certificat2006_06.html
(l'utilisation de sha-256 est dans le rapport de certification)
A la demande de la DCSSI, le produit peut être configuré dans un mode où
seule les signatures en sha-256 seront possibles.
La denière fois que j'ai exploré le sujet des algorithmes de hash officiellement admis par la DCSSI, [...] les deux fonctions de hashage admises étaient [...] [...] SHA-1 et RIPEMD-160 [...]
Je conjecture que les algorithmes de la famille SHA-2 http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf seraient aussi admissibles en le demandant poliment, mais je n'ai pas d'exemple de produit certifié les utilisant.
En fait dans la mise à jour 1.1 du document suivant : http://www.ssi.gouv.fr/site_documents/politiqueproduit/Mecanismes_cryptographique_v1_10_standard.pdf la dcssi rejette maintenant l'utilisation de sha-1 dans les composants qualifiés au niveau standard (paragraphe C.3.1).
En pratique ça fait un certain temps que la cellule crypto fait la moue quand on lui parle de sha-1 et pousse au maximum vers sha-2.
Quand au produits certifiés utilisant sha-2, je vais parler ici de ce que je connais directement, soit celui-ci : http://www.ssi.gouv.fr/fr/confiance/certificats/certificat2006_06.html (l'utilisation de sha-256 est dans le rapport de certification)
A la demande de la DCSSI, le produit peut être configuré dans un mode où seule les signatures en sha-256 seront possibles.
ptilou
Bonjour,
On 15 août, 17:11, Francois Grieu wrote:
Dans l'article , ptilou écrit:
En ce qui concerne le hash SHA-1, le wiki
http://fr.wikipedia.org/wiki/SHA-1
parle de collision, mon avis tant à dire qu'elles sont plus fréquentes (plaussibles) sur des fichiers de petite taille ?
Je ne vois pas pourquoi la probabilité que deux fichiers de contenu alétoire, MAIS DISTINCT, aient le même hash, serait sensiblement affectée par le fait que les deux fichiers soient de petite taille. Autant que je sache cette probabilité est de l'ordre de 2^-160.
Bien sur, la probabilité que deux très petit fichiers de contenu alétoire soient identiques dépend de leur taille, et jusqu'à 20 octets environ cela affecte notablement la probabilité que les deux fichiers aient le même hash.
Mais c'est la taille des en-tête de fichier !
( j'en dis une de plus ? )
Euh, sauf à fournir aussi une piste de justification...
Mon anglais étant proche de médiocre, j'ai cru comprendre que la clés de hash était obtenu par un procéder proche des algo de compression, après c'est ma logique qui a déduit ce raisonnement ...
Ptilou
Bonjour,
On 15 août, 17:11, Francois Grieu <fgr...@gmail.com> wrote:
Dans l'article <1187183396.024167.181...@50g2000hsm.googlegroups.com>,
ptilou <pti...@gmail.com> écrit:
En ce qui concerne le hash SHA-1, le wiki
http://fr.wikipedia.org/wiki/SHA-1
parle de collision, mon avis tant à dire qu'elles sont plus
fréquentes (plaussibles) sur des fichiers de petite taille ?
Je ne vois pas pourquoi la probabilité que deux fichiers
de contenu alétoire, MAIS DISTINCT, aient le même hash,
serait sensiblement affectée par le fait que les deux fichiers
soient de petite taille. Autant que je sache cette probabilité
est de l'ordre de 2^-160.
Bien sur, la probabilité que deux très petit fichiers de
contenu alétoire soient identiques dépend de leur taille,
et jusqu'à 20 octets environ cela affecte notablement
la probabilité que les deux fichiers aient le même hash.
Mais c'est la taille des en-tête de fichier !
( j'en dis une de plus ? )
Euh, sauf à fournir aussi une piste de justification...
Mon anglais étant proche de médiocre, j'ai cru comprendre que la clés
de hash était obtenu par un procéder proche des algo de compression,
après c'est ma logique qui a déduit ce raisonnement ...
parle de collision, mon avis tant à dire qu'elles sont plus fréquentes (plaussibles) sur des fichiers de petite taille ?
Je ne vois pas pourquoi la probabilité que deux fichiers de contenu alétoire, MAIS DISTINCT, aient le même hash, serait sensiblement affectée par le fait que les deux fichiers soient de petite taille. Autant que je sache cette probabilité est de l'ordre de 2^-160.
Bien sur, la probabilité que deux très petit fichiers de contenu alétoire soient identiques dépend de leur taille, et jusqu'à 20 octets environ cela affecte notablement la probabilité que les deux fichiers aient le même hash.
Mais c'est la taille des en-tête de fichier !
( j'en dis une de plus ? )
Euh, sauf à fournir aussi une piste de justification...
Mon anglais étant proche de médiocre, j'ai cru comprendre que la clés de hash était obtenu par un procéder proche des algo de compression, après c'est ma logique qui a déduit ce raisonnement ...
Ptilou
ptilou
On 15 août, 21:39, YannicK wrote:
Pour la NSA, je n'ai entendu que du bien sur les traveaux effectué ! ( l'organisme qui gére FIPS est "chien comme cochon" avec la NSA ! )
*COPAIN* comme cochon, et non pas /chien/ comme cochon !!! Ptilou, il faut réviser vos classiques ! Je vous conseille vivement un nouveau visionnage des "bronzés font du ski" ...
Préfére le passage avec la nignole, chez l'agriculteur ...
Ptilou
On 15 août, 21:39, YannicK <yannhuitcen...@yahoopointfr.invalid>
wrote:
Pour la NSA, je n'ai entendu que du bien sur les traveaux effectué !
( l'organisme qui gére FIPS est "chien comme cochon" avec la NSA ! )
*COPAIN* comme cochon, et non pas /chien/ comme cochon !!! Ptilou, il
faut réviser vos classiques ! Je vous conseille vivement un nouveau
visionnage des "bronzés font du ski" ...
Préfére le passage avec la nignole, chez l'agriculteur ...
Pour la NSA, je n'ai entendu que du bien sur les traveaux effectué ! ( l'organisme qui gére FIPS est "chien comme cochon" avec la NSA ! )
*COPAIN* comme cochon, et non pas /chien/ comme cochon !!! Ptilou, il faut réviser vos classiques ! Je vous conseille vivement un nouveau visionnage des "bronzés font du ski" ...
Préfére le passage avec la nignole, chez l'agriculteur ...
Ptilou
ptilou
Bonjour,
On 16 août, 11:51, Jean-Marc Desperrier wrote:
ptilou wrote:
Avec réserve : Juridiquement je crois que si c'est reconnu en Europe, c'est de facto en France ?! FIPS 140-2 vient des USA, n'y a t'il pas une convention international, qui lui donne force ?
La seule validation qui a /force/ en France est celle des critères communs, un produit évalué suivant les critères communs est reconnu dans les autres pays signataires de cet accord quel que soit sont origine, y compris en dehors de l'europe.
Ok, y a aussi eu une baffouille pondu par l'U.N. en 96, je ne sais pas si elle a force en Europe ? ( définition de deux type de signature numérique ou electronique ... )
Malheureusement je ne connais aucun produit libre évalué suivant les critères communs, et je me demande pourquoi les US continuent généralement à évaluer suivant FIPS alors qu'ils reconnaissent au ssi les critères communs.
Est que FIPS ne saurait pas reconnu comme critères communs dans un des pays de l'Union européenne ? ( au pif UK ?! )
Ptilou
Bonjour,
On 16 août, 11:51, Jean-Marc Desperrier <jmd...@alussinan.org> wrote:
ptilou wrote:
Avec réserve : Juridiquement je crois que si c'est reconnu en Europe,
c'est de facto en France ?!
FIPS 140-2 vient des USA, n'y a t'il pas une convention international,
qui lui donne force ?
La seule validation qui a /force/ en France est celle des critères
communs, un produit évalué suivant les critères communs est reconnu dans
les autres pays signataires de cet accord quel que soit sont origine, y
compris en dehors de l'europe.
Ok, y a aussi eu une baffouille pondu par l'U.N. en 96, je ne sais pas
si elle a force en Europe ?
( définition de deux type de signature numérique ou electronique ... )
Malheureusement je ne connais aucun produit libre évalué suivant les
critères communs, et je me demande pourquoi les US continuent
généralement à évaluer suivant FIPS alors qu'ils reconnaissent au ssi les
critères communs.
Est que FIPS ne saurait pas reconnu comme critères communs dans un des
pays de l'Union européenne ?
( au pif UK ?! )
Avec réserve : Juridiquement je crois que si c'est reconnu en Europe, c'est de facto en France ?! FIPS 140-2 vient des USA, n'y a t'il pas une convention international, qui lui donne force ?
La seule validation qui a /force/ en France est celle des critères communs, un produit évalué suivant les critères communs est reconnu dans les autres pays signataires de cet accord quel que soit sont origine, y compris en dehors de l'europe.
Ok, y a aussi eu une baffouille pondu par l'U.N. en 96, je ne sais pas si elle a force en Europe ? ( définition de deux type de signature numérique ou electronique ... )
Malheureusement je ne connais aucun produit libre évalué suivant les critères communs, et je me demande pourquoi les US continuent généralement à évaluer suivant FIPS alors qu'ils reconnaissent au ssi les critères communs.
Est que FIPS ne saurait pas reconnu comme critères communs dans un des pays de l'Union européenne ? ( au pif UK ?! )
Ptilou
Francois Grieu
Le 16 août, 12:35, Jean-Marc Desperrier a écrit:
Francois Grieu wrote:
La denière fois que j'ai exploré le sujet des algorithmes de hash officiellement admis par la DCSSI, [...] les deux fonctions de hashage admises étaient [...] [...] SHA-1 et RIPEMD-160 [...]
Je conjecture que les algorithmes de la famille SHA-2 http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangen... seraient aussi admissibles en le demandant poliment, mais je n'ai pas d'exemple de produit certifié les utilisant.
En fait dans la mise à jour 1.1 du document suivant :http://www.ssi.gou v.fr/site_documents/politiqueproduit/Mecanismes_cry... la dcssi rejette maintenant l'utilisation de sha-1 dans les composants qualifiés au niveau standard (paragraphe C.3.1).
En pratique ça fait un certain temps que la cellule crypto fait la moue quand on lui parle de sha-1 et pousse au maximum vers sha-2.
Merci de cette mise à jour (ma "dernière fois" avais plus de 2 ans).
Quand au produits certifiés utilisant sha-2, je vais parler ici de ce que je connais directement, soit celui-ci :http://www.ssi.gouv.fr/fr/conf iance/certificats/certificat2006_06.html (l'utilisation de sha-256 est dans le rapport de certification)
A la demande de la DCSSI, le produit peut être configuré dans un mode où seule les signatures en sha-256 seront possibles.
Donc non seulement SHA-2 est recommandé voire obligatoire, mais en plus c'est utilisé !
François Grieu
Le 16 août, 12:35, Jean-Marc Desperrier <jmd...@alussinan.org> a
écrit:
Francois Grieu wrote:
La denière fois que j'ai exploré le sujet des algorithmes de hash
officiellement admis par la DCSSI, [...]
les deux fonctions de hashage admises étaient [...]
[...] SHA-1 et RIPEMD-160
[...]
Je conjecture que les algorithmes de la famille SHA-2
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangen...
seraient aussi admissibles en le demandant poliment, mais je n'ai
pas d'exemple de produit certifié les utilisant.
En fait dans la mise à jour 1.1 du document suivant :http://www.ssi.gou v.fr/site_documents/politiqueproduit/Mecanismes_cry...
la dcssi rejette maintenant l'utilisation de sha-1 dans les composants
qualifiés au niveau standard (paragraphe C.3.1).
En pratique ça fait un certain temps que la cellule crypto fait la moue
quand on lui parle de sha-1 et pousse au maximum vers sha-2.
Merci de cette mise à jour (ma "dernière fois" avais plus de 2 ans).
Quand au produits certifiés utilisant sha-2, je vais parler ici de ce
que je connais directement, soit celui-ci :http://www.ssi.gouv.fr/fr/conf iance/certificats/certificat2006_06.html
(l'utilisation de sha-256 est dans le rapport de certification)
A la demande de la DCSSI, le produit peut être configuré dans un mode où
seule les signatures en sha-256 seront possibles.
Donc non seulement SHA-2 est recommandé voire obligatoire, mais en
plus c'est utilisé !
La denière fois que j'ai exploré le sujet des algorithmes de hash officiellement admis par la DCSSI, [...] les deux fonctions de hashage admises étaient [...] [...] SHA-1 et RIPEMD-160 [...]
Je conjecture que les algorithmes de la famille SHA-2 http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangen... seraient aussi admissibles en le demandant poliment, mais je n'ai pas d'exemple de produit certifié les utilisant.
En fait dans la mise à jour 1.1 du document suivant :http://www.ssi.gou v.fr/site_documents/politiqueproduit/Mecanismes_cry... la dcssi rejette maintenant l'utilisation de sha-1 dans les composants qualifiés au niveau standard (paragraphe C.3.1).
En pratique ça fait un certain temps que la cellule crypto fait la moue quand on lui parle de sha-1 et pousse au maximum vers sha-2.
Merci de cette mise à jour (ma "dernière fois" avais plus de 2 ans).
Quand au produits certifiés utilisant sha-2, je vais parler ici de ce que je connais directement, soit celui-ci :http://www.ssi.gouv.fr/fr/conf iance/certificats/certificat2006_06.html (l'utilisation de sha-256 est dans le rapport de certification)
A la demande de la DCSSI, le produit peut être configuré dans un mode où seule les signatures en sha-256 seront possibles.
Donc non seulement SHA-2 est recommandé voire obligatoire, mais en plus c'est utilisé !
François Grieu
Sylvain
Jean-Marc Desperrier wrote on 16/08/2007 11:51:
[...] et je me demande pourquoi les US continuent généralement à évaluer suivant FIPS alors qu'ils reconnaissent aussi les critères communs.
peut être parce que le périmêtre de ces certifs est assez différents!
en gros, la certif. FIPS 140-2 est auto-contenue: elle définit exhaustivement ce qui doit être protégée et quels points doivent être satisfait (et cette approche colle avec le pragmatisme américain).
une certif. EAL commence par définir son profil de sécurité (soit de manière libre - et la pertinence peut ne pas être si évidente, soit de manière consensuelle - et les tours de tables de comités prennent généralement des années, ce qui peut être colle avec le tempérament latin d'une partie de l'Europe).
au delà de ces différences (caricaturales), s'ils "reconnaissent" les critères communs, une certif 140-2 niveau 2 est souvent demandée même si le produit d'intérêt a déjà une certif EAL 4 ou 4+.
Sylvain.
Jean-Marc Desperrier wrote on 16/08/2007 11:51:
[...] et je me demande pourquoi les US continuent généralement
à évaluer suivant FIPS alors qu'ils reconnaissent aussi les
critères communs.
peut être parce que le périmêtre de ces certifs est assez différents!
en gros, la certif. FIPS 140-2 est auto-contenue: elle définit
exhaustivement ce qui doit être protégée et quels points doivent être
satisfait (et cette approche colle avec le pragmatisme américain).
une certif. EAL commence par définir son profil de sécurité (soit de
manière libre - et la pertinence peut ne pas être si évidente, soit de
manière consensuelle - et les tours de tables de comités prennent
généralement des années, ce qui peut être colle avec le tempérament
latin d'une partie de l'Europe).
au delà de ces différences (caricaturales), s'ils "reconnaissent" les
critères communs, une certif 140-2 niveau 2 est souvent demandée même si
le produit d'intérêt a déjà une certif EAL 4 ou 4+.
[...] et je me demande pourquoi les US continuent généralement à évaluer suivant FIPS alors qu'ils reconnaissent aussi les critères communs.
peut être parce que le périmêtre de ces certifs est assez différents!
en gros, la certif. FIPS 140-2 est auto-contenue: elle définit exhaustivement ce qui doit être protégée et quels points doivent être satisfait (et cette approche colle avec le pragmatisme américain).
une certif. EAL commence par définir son profil de sécurité (soit de manière libre - et la pertinence peut ne pas être si évidente, soit de manière consensuelle - et les tours de tables de comités prennent généralement des années, ce qui peut être colle avec le tempérament latin d'une partie de l'Europe).
au delà de ces différences (caricaturales), s'ils "reconnaissent" les critères communs, une certif 140-2 niveau 2 est souvent demandée même si le produit d'intérêt a déjà une certif EAL 4 ou 4+.
