Re: [vhdl-200x] Protect tool - Key block clarification

From: John Shields <John_Shields_at_.....> Date: Tue Jul 17 2007 - 12:20:41 PDT · to exchange it like a key

Michael and All,

I am investigating this and I will comment on it in more detail later. 
I've also directly asked some colleagues at Cadence to comment. I'll
reserve comments on some of your proposal and Jerry's.  With respect to
key exchange, yes, it is not defined in the spec along with some other
essential aspects to support effective interoperability across tool
chains and IP providers.  FYI, there is an effort started last Fall in
VSIA, an industry consortium dedicated to IP reuse, to fill in those
aspects as well as extend the specs to support digital rights
management.  That effort is being transitioned to IEEE in the near
future and should lead to enhancements to both Verilog and VHDL LRMs as
well as a separate specification.

I don't want to elaborate on it here, but I will say that the standard
use model proposed is the digital envelope in which a
session-generated, one time key for a particular symmetric cipher is
encrypted with a public key.  The key exchange problem becomes one of
obtaining authoritative public keys for those being granted rights. 
Within the envelope, as it proves necessary, one can provide the
session key and the IV.  Given the digital envelope scenario however,
it hardly matters.  The IV can be a fixed default without risking
anything, since the session key is a one time use.  I am not disputing
your point at all, just putting it into some additional perspective.

Now, I have a concern about the analysis of the cipher algorithms here
that leads us to the declare we need to carefully exchange the IV. I'll
start from a common sense argument; call me naive, if you will.  At
30,000 ft, to say that today's dominant strong symmetric ciphers
require a secret key for encryption and decryption is fine.  To say
that their weakness lies in key management, i.e., that one must
exchange the secret key in an out-of-band channel, is also fine.  To
discover in the implementation details that another piece of
information, the initial vector, must also be created and exchanged
concerns me greatly.  I mean, what's with the terminology?  It looks
like part of the key, it is needed like part of the key, and it has to
be exchanged like it was part of the key.  If that is the case, then
the algorithm designers have played a cruel hoax and added an unneeded
ugliness.  Or...I don't understand their motivations.  I do have some
insight into the general cipher block chaining(CBC) model. Here is my
research to this point:

There is value in using a random IV, but there is no need to
exchange it like a key to decrypt. The role it serves is to
provide a random set of initial "plaintext" to encrypt before the real
"plaintext."  Because of the nature of block chaining, each block
depends on the results of encrypting the prior block. CBC mode forces
identical plaintext blocks to encrypt to different ciphertext blocks
only when some previous plaintext block is different. Two identical
plaintext messages will still encrypt to the same ciphertext.  Even
worse, two messages that begin the same will encrypt the same way up to
the first difference.  ( To be clear, when using the same secret key,
of  course). So, this is underlying opportunity for a cracker.

The way to use an IV is as if it were a source of meaningless but
random initial plaintext.  (A timestamp is a suggestion I've read).
When you decrypt the first block, you just discard it except to
properly initialize the feedback register.  A couple of points.  While
the IV should be unique, it is not a requirement.  Two, the IV need not
be kept secret, it can be transmitted in the clear with the ciphertext
as the first block or any other way that is kept associated with the
ciphertext.  It takes some discussion, but there is no reduction in
strength of the encryption to do so. The attacks of block replay and
creating a code book are basically defeated.

The details I have not analyzed is whether the specific standardized
strong algorithms that are CBC based have not addressed transmission of
the IV as part of the cipher text.  Even if not directly, it is
possible that open source and commercial implementations actually have
agreed on how this is handled.  No point inventing yet another
approach. There is certainly the possibility that we do need to address
this in normative fashion in the LRMs, but perhaps we may discover that
the need is only in informative text.  I am reserving judgment.  Even
if it is normative, it is not clear that the best solution will be to
add a new protect pragma for it.

As to the Synplicity implementation, their use of the IV as a default
value is not a weakness that bothers me, since they use the digital
envelope model.  What would bother me a little is if they used the same
secret key rather than a one time use key.  Regardless, I am confident
we will not agree to do that as an adopted convention for
interoperability.

Hope this helps.

Regards, John