"Conformità FIPS" riguarda più dell'algoritmo. Riguarda le implementazioni . Essere premiati con il badge "conforme" è un processo lungo, complesso e molto costoso; il suo significato concettuale è che ci sono alcuni motivi validi per credere che l'implementazione sia corretta e sicura e soddisfi una serie di proprietà di sicurezza. Dal momento che non sappiamo davvero come dimostrare che il software sia corretto in generale, la maggior parte della conformità FIPS viene effettuata attraverso audit e analisi del processo di sviluppo. Questo è piuttosto approfondito; ciò include, ad esempio, la garanzia che durante lo sviluppo sia stato utilizzato il controllo delle versioni del codice sorgente, con attribuzione appropriata di ciascuna riga di codice a uno sviluppatore correttamente identificato, per il quale sono stati eseguiti alcuni controlli in background.
In pratica, ottenere la conformità implica la produzione di un sacco di documenti (molte migliaia di pagine) e ancora più auditing, per un costo che va facilmente a $ 50000 o più, e richiede mesi. I costi crescono rapidamente con lo scopo. Apparentemente, nel 2007 (dal tuo link), Microsoft ha passato l'intera prova per HMAC / SHA-1 ma non per HMAC / SHA-256 o HMAC / SHA-512, motivo per cui il primo è "FIPS validato" ma non il quest'ultimo.
Questo potrebbe essere legato al fatto che in quel momento, .NET poteva usare l'implementazione SHA-1 dal livello Win32 (CryptoAPI), nel codice nativo, mentre SHA-256 e SHA-512 erano codice "gestito" ; fare la conformità FIPS per HMAC / SHA-256 con l'implementazione gestita ( SHA256Managed
) avrebbe gettato il runtime CLR, incluso il compilatore JIT, nell'ambito del controllo, e il prezzo sarebbe probabilmente salito alle stelle. Un'implementazione nativa di SHA-256 è stata aggiunta in .NET 3.5 ( SHA256Cng
) ma è stata rilasciata solo alla fine del 2007, troppo tardi per la conformità mostrata nella lista a cui ci si collega.