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

The only working implementation I know (Synplicity's Open IP Encryption)
uses quite unfortunate solution: fixed IV (both encrypting and
decrypting tool use assumed value). If IP vendor for some reason decides
to use the same encryption key for subsequent encryption sessions, it
makes code-breaking task much easier if the code-breaker has access to
more than one encrypted file. The problem is less painful if random key
is used for each encryption session.
For the sake of backwards compatibility, I would suggest to use 'assume
default if explicit data not present' rule:
-- create new tag for IV, so that symmetric key and IV can be specified
clearly
-- if either key or IV is missing in the decryption envelope, tool
default is used
Anybody knows how Cadence (the originator of the donation) does it?

Thank you,

Jerry Kaczynski 

-----Original Message-----
From: Peter Ashenden [mailto:peter@ashenden.com.au] 
Sent: Sunday, July 15, 2007 11:20 PM
To: 'Michael Smith'; vhdl-200x@server.eda.org
Cc: vhdl-lrm@lists.accellera.org
Subject: RE: [vhdl-200x] Protect tool - Key block clarification

Michael,

Thanks for raising this issue. It was a detail I was not aware of when
we drafted the specification. The LRM is silent on how the
initialization vector should be determined, but the interpretation you
suggest makes sense for digital envelopes.

As for encryption using symmetric cipers with secret keys (not using
digital envelopes), the secret key is not included in the decryption
envelope. It is assumed the recipient of the model has access to the key
in their keystore.
That begs the question of what initialization vector is to be used. If
we don't specify how the encryption tool generates an IV, the decryption
tool won't be able to decrypt. Any suggestions?

Please note that the above is my personal input, not the response of the
working group. I'll raise an issue report for the Accellera VHDL-TC on
this issue so that we can formalize a response.

Cheers,

PA 

--
Dr. Peter J. Ashenden         peter@ashenden.com.au
Ashenden Designs Pty. Ltd.    www.ashenden.com.au
PO Box 640                    VoIP:
sip://0871270078@sip.internode.on.net
Stirling, SA 5152             Phone: +61 8 7127 0078
Australia                     Mobile: +61 414 70 9106


> -----Original Message-----
> From: owner-vhdl-200x@server.eda.org
> [mailto:owner-vhdl-200x@server.eda.org] On Behalf Of Michael Smith
> Sent: Saturday, 14 July 2007 9:31 AM
> To: vhdl-200x@server.eda.org
> Subject: [vhdl-200x] Protect tool - Key block clarification
> 
> 
> I'm in the process of implementing the protect tool directives 
> described in the draft IEEE P1076-2006, section 22. I was looking for 
> a clarification on the key specification/key block (sections 22.1.3.1 
> and 22.1.4.1).
> 
> All symmetric encryption methods described in section
> 22.1.2.2 use Cypher-Block-Chaining, which requires an initial vector 
> (IV) to start the chain. My interpretation is that the encoded and 
> encrypted text of the key block must contain both the encryption key 
> and the initial vector, in that order with no space separating them. 
> The format the key and IV appear in is important for ensuring 
> compatibility between different applications. Is this interpretation 
> correct?
> 
> -----------------------
> Michael Smith
> R&D Engineer, SaberHDL
> Synopsys Inc.
> mtsmith@synopsys.com
> -----------------------
> 
> --
> This message has been scanned for viruses and dangerous content by 
> MailScanner, and is believed to be clean.
> 
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.