There are two ways that I see to solve the IV collision issue:
1. Allow longer IVs: The GCM spec allows IVs of any size, we can just do the same for 1619.1, and leave it to the application to decide how to set the IV and to what size. The application can then set the IV to include the vendor-ID and whatever else it wants to put there. (Does the CCM spec allow long IVs?) 2. Push the problem to key-management, using a solution such as the one that was proposed by Matt. We can probably devise key-derivation methods that use AES rather than SHA256 (or use existing methods from NIST). Approach 1 is more elegant (I think) but either would work. In the spirit of having a very permissive standard, I suggest that we just allow any-size IV and put some appendix that describe the multi-vendor IV issue and sketches the two solutions above. -- Shai Matt Ball wrote: > [...] I think the only big outstanding issue is that we need to find a > way to solve the problem of unique IVs across different vendors. Jim, > have you had a chance to looks at some of the options? I'd like to get > some discussion started before our next meeting in February, so here are > some comments (most coming from Fabio's meetings of the December meeting): > [...] > Just brainstorming here -- How about if we did something like this: > > NewKey = SHA-256(UserKey || 3-byte IEEE OUI || Vendor unique information) > [...]
