soddisfa i requisiti di sicurezza (ad esempio una funzione hash deve essere resistente alla collisione , preimage-resistant o una cifratura deve soddisfare ciphertext indistinguishability )
la parte difficile qui è come giustificare che soddisfa i requisiti di sicurezza. Facciamo affidamento su riduzioni di sicurezza ('' prove ''), estensioni dell'analisi esterna (ad esempio, l'algoritmo pubblicato su una rivista rispettata e analizzato per un paio di anni potrebbe essere previsto "migliore" di qualcosa tenuto segreto) e l'esperienza del progettisti (ad es. mi fiderei dei progettisti di AES più di qualche persona a caso che pubblichi su un newsgroup)
soddisfa i requisiti di rendimento per l'applicazione specifica e l'intervallo di piattaforme di destinazione
è facile da implementare in modo sicuro (ad esempio, alcuni algoritmi sono più facili da proteggere rispetto ai canali laterali rispetto ad altri, gli algoritmi più semplici sono più facili da implementare correttamente)
una caratteristica extra è che '' fallisce con garbo '' ad es. se alcune delle ipotesi richieste per il corretto funzionamento non sono soddisfatte, non portano a un'insicurezza catastrofica ma solo a un peggioramento del livello di sicurezza. Un buon esempio potrebbe essere il riutilizzo nonce negli schemi di crittografia autenticati. Alcuni progetti falliscono drasticamente mentre altri possono mantenere un certo livello di sicurezza.