There is a language called SystemVerilog that can be protected via encryption to allow sharing/licensing code for others to use, but prevents them from seeing the code contents. This is done based on the recommendations of IEEE 1735 (paywall) and through support through the Compiler/Simulation software. If the correct keys are used, the compiler/simulator is able to read the 'shared' IP, compile, and run the protected IP.

Within IEEE 1735, it recommends RSA >=2048 for Asymmetric encryption.

I can have some code, protected by this encryption scheme, that prints text out to a log file. If the text it prints out is static text, will I need to worry about the encryption security of my file?

module my_encrypted_module;
 initial begin
    $display ("This text will be printed to log file");
  • The encrypted file is 1000 characters long
  • 500 characters is a text message that will be printed to the log when running
  • Does knowledge from seeing the resulting print message decrease the security of the other portions of this same file, allowing someone to more easily decrypt the file?


  • 1
    $\begingroup$ My reading is that IEEE 1735-2014 as approved 2014-12 has flaws vigorously slept under the rug, as half-acknowledged by "Please view (dead link) for important information regarding possible vulnerabilities" and the disappearance of a research paper; and is replaced by IEEE 1735-2014 of 2015-09. Reportedly "The PDF of this standard is available at no cost compliments of the Accellera Systems Initiative at ieeexplore.ieee.org/document/7274481" but "free" seems to be \$91 $\endgroup$ – fgrieu Nov 13 '18 at 7:00
  • $\begingroup$ Thanks @fgrieu. Since you work with software, you already know there are different meanings for 'free' $\endgroup$ – mdiehl13 Nov 14 '18 at 5:29

IEEE 1735-2014 prescribes a hybrid encryption scheme, where a symmetric key is enciphered per an asymmetric encryption scheme. The recommended asymmetric encryption scheme is RSAES-PKCS1-V1_5 of PKCS#1 with key length at least 2048-bit, and that's used to encipher a random key, perhaps for DES, 3DES, AES-128, or AES-256 (with only the later two recommended). That key is used to encipher the payload in CBC mode.

In the question the payload is a "file" of about 1000 bytes, including 500 bytes of public static text. It is asked

(considering this) will I need to worry about the encryption security of my file?

Yes, but not because of the interaction of the 500 bytes of public static text with RSA at thought in the question, because RSA does not directly encipher this text; and not because of the known text, because CBC and any decent block cipher should be secure against that. The reasons to worry are that

  1. Fundamentally, IEEE 1735-2014 assumes that the tool possessing the asymmetric decryption key will manage to keep it secret, as well as the symmetric encryption key, and use them per designed-in restrictions. That's even though that tool seems to be software running on standard PCs, and we know no robust way to achieve such security in such context. Determined and competent adversaries with access to the software in a state where it can run are able, with enough effort, to access the deciphered plaintext.
  2. It is uneasy to implement CBC decryption in a way that does not make it a decryption oracle (allowing decryption of any ciphertext encrypted with the symmetric key by repeated queries). And according to CVE-2017-13091, implementers have not.
  3. It is difficult to implement RSAES-PKCS1-V1_5 decryption in a way that does not make it a decryption oracle (allowing decryption of any RSA ciphertext encrypted with the public key by repeated queries). And according to CVE-2017-13092, implementers have not.
  4. Goofs seem to have crept in at least the initial version of the standard and implementations.
  • 1
    $\begingroup$ Linking to EMC/RSA/whatever is asking for trouble, they seem to have serious issues leaving their content in the right place. It's not as bad as Sun / Oracle, but it is close. I would not expect otherwise from a storage company, of course. $\endgroup$ – Maarten Bodewes Nov 13 '18 at 12:44
  • 1
    $\begingroup$ @Maarten Bodewes: yes, this important reference (PKCS#1v2.2) has been on again / off again lately. OTOH the IETF version was dead slow to load when I just tried, and lacks the drawings, which help a lot! And I'm not feeling like making an explicitly unlawful mirror, or linking to one. Thus I'm left linking to the official source, hoping that the self-proclaimed champion of reliable storage will get it straight. $\endgroup$ – fgrieu Nov 13 '18 at 13:05
  • $\begingroup$ @MaartenBodewes: EMC including RSA (and VMWare) is owned by Dell since 2016, and as of last month Dell is proposing a kind of pseudo-IPO. I haven't decided whether either or both of these augur good or ill. $\endgroup$ – dave_thompson_085 Nov 14 '18 at 4:51
  • $\begingroup$ Good point about private key being on a client machine. I agree there probably isn't a good way around this for the tool vendors, since the corporations installing them (your big Semiconductor companies) do not want the tools calling-home to enable keeping private key elsewhere $\endgroup$ – mdiehl13 Nov 14 '18 at 5:22

No known, modern cipher should be vulnerable against known plaintext attacks. Now just RSA 2048 is not likely to be used on all the text, and RSA encryption can be implemented in different ways, but it is unlikely to the extreme that the protocol is vulnerable against known plaintext attacks. It may of course well be vulnerable against other attacks, such as padding oracle attacks on PKCS#1 v1.5 padding, if that is used.

So you can create a string as large as you want and still be secure against known plaintext attacks, no matter how much of it is guessed or gets known otherwise.

Hah, and I looked up the standard after I wrote this answer and got this in return. It doesn't contain known plaintext attacks of course, that would be too easy. But it does use PKCS#1 v1.5 - which may be vulnerable and AES-CBC without authentication which is even more likely to be vulnerable (ugh).

The paper by the way has been "withdrawn for non scientific reasons" - probably to hide it under the carpet, but you can still download it if you know how to retrieve old internet content (deliberately not linked). Here is the security advisory that links to the missing paper.

  • $\begingroup$ Thanks Maarteen for your comments on plaintext attacks, and for finding that article. That will be super useful to know! $\endgroup$ – mdiehl13 Nov 14 '18 at 5:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.