openais should be ported to use NSS library for cryptography. See the tracking bug for details and links on how it could be done.
no this would break protocol compatability and introduce unwanted dependencies in the project.
Steven, what are the crypto usages of openais?
from SECURITY distributed with the package: Group Messaging Interface ------------------------- Group messaging uses UDP/IP to communicate with other openais executives using messages. It is possible without authentication of every packet that an attacker could forge messages. These forged messages could fault the openais executive distributed state machines. It would also be possible to corrupt end applications by forging changes. Since messages are sent using UDP/IP it would be possible to snoop those messages and rebuild sensitive data. To solve these problems, the group messaging interface uses two new interfaces interal to it's implementation: 1. encrypt_and_sign - encrypts and signs a message securely 2. authenticate_and_decrypt - authenticates and decrypts a message securely When the executive wants to send a message over the network, it uses encrypt_and_sign to prepare the message to be sent. When the executive wants to receive a message from the network, it uses authenticate_and_decrypt to verify the message is valid and decrypt it. These two functions utilize the following algorithms: sha1 - hash algorithm secure for using with hmac hmac - produces a 16 byte digest from any length input sober - pseudo random number generator and stream cipher The hmac algorithm requires a 16 byte key. The sober algorithm requires a 16 byte private key. The sober algorithm requires a 16 byte public initial vector. The private key is read from disk and stored in memory for use with the sober algorithm to generate the three required keys. Every message starts with a struct security { unsigned char digest[20]; A one way hash digest unsigned char salt[16]; A securely generated random number } When a message is sent (encrypt_and_sign): ------------------------------------------ 1. sober is used to create a 16 byte random number (salt) using the md4 algorithm 2. sober is keyed with the private key and the initial vector is set to the salt. Then a 48 byte key is read from the sober algorithm. This 48 byte key is split into 3 16 byte keys. The keys are the hmac key, the sober key and the sober initial vector. 3. A sober instance is keyed with the sober key and sober initial vector from step #2. 4. The data of the packet, except for the security header, is encrypted using the sober cipher that was initialized in step #3. 5. The salt is stored in the security header of the outgoing message. 6. The hmac is initialized with the hmac key generated in step #2. 7. The message, except for the security header, is hmaced to produce a digest using the sha1 algorithm. 8. The digest is stored in the outgoing message. 9. The message is transmitted. When a message is received (decrypt_and_authenticate): ------------------------------------------------------ 1. sober is keyed with the private key and the initial vector is set to the salt in the received message. Then a 48 byte key is read from the sober algorithm. This 48 byte key is split into 3 16 byte keys. The keys are the hmac key, the sober key and the sober initial vector. 2. The sober key and sober initial vector from step #1 are used to key a new sober instance. 3. The hmac is setup using the hmac key generated in step #1 using sha1. 5. The message is authenticated, except for the security header. 6. If the message was not authenticated, the caller is told of the result. The caller ignores the message. 7. The message is decrypted, except for the security header, using the sober algorithm in step #2. 8. The message is processed. as an aside sober128 is used to generate random numbers in various places as well. regards -steve
Sigh, thanks steve. We need to mark this package 'extra care required'. Hopefully we won't need it in any of our near term validated products. Before we can validate, we will need to move to FIPS approved algorithms, which means working with upstream to extend the protocol itself (a lot longer than just changing the code). Steve, who came up with the protocol, is it trying to match an existing spec or specific to openais? If it hasn't had a security review, we should probably look into doing one with an outside cryptographer. New security protocols are nothing to take lightly. bob