Re: How the Greek cellphone network was tapped.
silvio wrote: Aren't run-of-the-mill cellphones these days powerful enough to use available software like OpenSSL to encrypt voice/datastreams? Again...what are the options for end-to-end cell encryption right now? Mobile phones have had spare cycles for doing strong crypto for a very long time. There are two classes of reasons why this is not happening and is (unfortunately) never going to happen: 1. Practically no users ask for it, so the handset vendors prefer to use development resources to build even more flashy features, rather than allocate resources to developing E2E security. No user would ever brag about how secure their phone is, but they would brag about how they can play video games or take pictures or whatever, or how small it is. 2. E2E crypto on mobiles would require cross-vendor support, which would mean that it would have to go into the standard. Unfortunately, standards in the mobile world are heavily influenced by governmnets, and the four horsemen of the apocalypse (drug dealers, paedophiles, spies, and terrorists) are still being used by government types to nix any attempts at crypto they can't break or intercept. Unfortunately, it's not so easy to roll your own on top of a 3G-enabled smartphone. The broadband channel does not have the tight jitter and throughput guarantees that voice needs, and some providers (Verizon in the USA for example) consider running voice traffic over their broadband network a violation of the usage agreement (no need to blame the government for that, their own greed is adequate explanation). There are lots of other technical and human-factors issues that have been covered to great extent in this and other fora. /ji - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
FIPS 140-2, PRNGs, and entropy sources
Hello, I have a couple of questions related to FIPS 140-2: 1) Can a product obtain FIPS 140-2 certification if it implements a PRNG from NIST SP 800-90 (and therefore is not listed in FIPS 140-2 Annex C)? If not, will Annex C be updated to include the PRNGs from SP 800-90? 2) Does FIPS 140-2 have any requirements regarding the quality of the entropy source that is used for seeding a PRNG? I couldn't find any such requirement, which seems like a glaring oversight when evaluating the security of a product that may generate keys and other critical security parameters. Thanks for your help. Best regards, Darren Lasko
Re: FIPS 140-2, PRNGs, and entropy sources
On Sat, Jul 07, 2007 at 10:53:17PM -0600, Darren Lasko wrote: 1) Can a product obtain FIPS 140-2 certification if it implements a PRNG from NIST SP 800-90 (and therefore is not listed in FIPS 140-2 Annex C)? If not, will Annex C be updated to include the PRNGs from SP 800-90? The PRNGs in SP800-90 are listed in the current Annex C (see item #6 on page 4; this occurred in January of this year). http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexc.pdf There is no algorithm testing for the SP800-90 RNGs yet, but they are allowed for use in the approved mode of operation because of IG 1.10 (http://csrc.nist.gov/cryptval/140-1/FIPS1402IG.pdf). You'll also want to read IG 1.12, which directly pertains to the testing that is required to test the vendor's assertion that they have a compliant SP80-90 RNG. 2) Does FIPS 140-2 have any requirements regarding the quality of the entropy source that is used for seeding a PRNG? Yes. The requirement imposed by FIPS 140-2 (http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf) are in section 4.7.2: Compromising the security of the key generation method (e.g., guessing the seed value to initialize the deterministic RNG) shall require as least as many operations as determining the value of the generated key. (which would apply to any RNG output that became a key) and in section 4.7.3: Compromising the security of the key establishment method (e.g., compromising the security of the algorithm used for key establishment) shall require at least as many operations as determining the value of the cryptographic key being transported or agreed upon. (which would apply to any RNG output that is used in a security relevant way in a key establishment scheme) Josh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
