История изменений
Исправление www_linux_org_ru, (текущая версия) :
вот хорошая цитатка в тему:
Frankly, I'd be surprised if anyone did use it. Even before the potential backdoor was discovered back in 2007, the Dual_EC_DRBG was known to be much slower and slightly more biased than all the other random number generators in NIST SP 800-90. To quote Bruce Schneier:
«If this story leaves you confused, join the club. I don't understand why the NSA was so insistent about including Dual_EC_DRBG in the standard. It makes no sense as a trap door: It's public, and rather obvious. It makes no sense from an engineering perspective: It's too slow for anyone to willingly use it. And it makes no sense from a backwards-compatibility perspective: Swapping one random-number generator for another is easy.»
I guess it's possible that the only people at NSA who ever thought the back door was going to work were too high in the hierarchy to really understand the practical issues. I can easily imagine a conversation something like this:
«The SIGINT folks keep asking for an algorithm that we can break but nobody else can. Is that possible?»
«Well, technically, yes, but it'd be really slow. Nobody's ever going to want to use it. And it'd look really suspicious, anyway.»
«Never mind that, just do it. I really want to get those guys off my back.»
The only other possibility I can think of is that maybe some people are using Dual_EC_DRBG in crypto products, simply because the NSA has been leaning on them to do so. But it still seems like an awkward way to introduce a backdoor into a cryptosystem, when it would be so much easier to just slip in a deliberate bug or two. Still, it's a NIST-approved algorithm, so using Dual_EC_DRBG could at least let you legitimately claim that your code has been tested and validated, while still having a backdoor. ( http://crypto.stackexchange.com/a/10192 )
http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html — там целый список, но большинство вместе с Dual_EC_DRBG сертифицируют и другое
Исходная версия www_linux_org_ru, :
вот хорошая цитатка в тему:
Frankly, I'd be surprised if anyone did use it. Even before the potential backdoor was discovered back in 2007, the Dual_EC_DRBG was known to be much slower and slightly more biased than all the other random number generators in NIST SP 800-90. To quote Bruce Schneier:
«If this story leaves you confused, join the club. I don't understand why the NSA was so insistent about including Dual_EC_DRBG in the standard. It makes no sense as a trap door: It's public, and rather obvious. It makes no sense from an engineering perspective: It's too slow for anyone to willingly use it. And it makes no sense from a backwards-compatibility perspective: Swapping one random-number generator for another is easy.»
I guess it's possible that the only people at NSA who ever thought the back door was going to work were too high in the hierarchy to really understand the practical issues. I can easily imagine a conversation something like this:
«The SIGINT folks keep asking for an algorithm that we can break but nobody else can. Is that possible?»
«Well, technically, yes, but it'd be really slow. Nobody's ever going to want to use it. And it'd look really suspicious, anyway.»
«Never mind that, just do it. I really want to get those guys off my back.»
The only other possibility I can think of is that maybe some people are using Dual_EC_DRBG in crypto products, simply because the NSA has been leaning on them to do so. But it still seems like an awkward way to introduce a backdoor into a cryptosystem, when it would be so much easier to just slip in a deliberate bug or two. Still, it's a NIST-approved algorithm, so using Dual_EC_DRBG could at least let you legitimately claim that your code has been tested and validated, while still having a backdoor. ( http://crypto.stackexchange.com/a/10192 )
однако, что интересно, похоже некоторые фирмы используют этот алгоритм в качестве ЕДИНСТВЕННОГО для определенного продукта, в частности:
Hash_Based DRBG: [ Prediction Resistance Tested: Not Enabled ( SHA-224 , SHA-256 , SHA-384 , SHA-512 ) ( SHS Val#1323 ) ]
«Thales e-Security implements this algorithm for applications running on its Thales Secure Processing Platform (TSPP) providing secure cryptographic resources to products in the Thales e-Security portfolio, including the payShield 9000 HSM family.»
http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html — там целый список, но большинство вместе с Dual_EC_DRBG сертифицируют и другое, а вот Thales e-Security сертифицировала исключительно бэкдор для своей TSPP, гы-гы