On 4/12/06, Lyon, Jay <[EMAIL PROTECTED]> wrote: > Kyle, thanks for your response. If you don't mind answering one more > question, it will help clarify things for me. > > Assume a hypothetical crypto toolkit; OpenEXX has recently emerged and > is a leader in a crypto technology that is useful for memory constrained > devices. It has been recently FIPS validated using the same recompile > model introduced by OpenSSL. Its security policy is similar to OpenSSL > (they are modeled the same). These tools are philosophically in sync. > > My application, for example; ScatterData will benefit from both of these > technologies and will have both tools in FIPS mode at the same time > (overlapping threads, etc). Will the non-hypothetical OpenSSL be in a > valid FIPS mode in this circumstance?
Please be aware that I am not a FIPS specialist, so I'm going to have to express my understanding; I hope that if I'm incorrect, someone with more knowledge will correct me. FIPS operates on a "security perimeter" concept -- that is, an individual cryptographic module is essentially a "black box" with a defined API. As long as cryptographically-significant state -- keys, entropy, initialization vectors, passphrases, ciphertext, plaintext -- are all maintained inside that security perimeter, then that module is in a valid FIPS mode. That said, however, two separate devices are two separate security perimeters. So, In order to move any data between FIPS devices, the application must first use the defined API of one of those devices to export that information out of that device's perimeter (in a manner compliant with that device's security policy), and then use the defined API of the other device to import that information into that other device's perimeter (in a manner compliant with that other device's security policy). In addition, keying material accepted from the user (passphrases and such) must be cleared from memory as soon as practical, and keys themselves are subject to the security modules' security policies. (Some modules require that keys be "non-exportable" if so marked, for example. This is especially true for modules that manage their own keystores, but may also be a concern in a hypothetical scenario such as the one you describe -- if that's the case, you will only be able to manipulate data encrypted with a given key in the module that created an manages that key's usage, even if the operation would be easier or quicker or even merely possible in the other module.) So, the answer to your question is "it depends on how you use them". -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
