Bug 347791

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