Difference between revisions of "Support IEEE 1735 encryption standard"
From Verific Design Automation FAQ
| Line 2: | Line 2: | ||
| − | ''Note: This article mentions only "encryption/decryption '''algorithms'''," but the same arguments also apply to " | + | ''Note: This article mentions only "encryption/decryption '''algorithms'''," but the same arguments also apply to "encryption/decryption '''keys'''."'' |
| − | Verific provides APIs with which | + | Verific provides APIs with which our licensees can plug in their proprietary encryption/decryption algorithms. |
For technical details, please see: | For technical details, please see: | ||
| Line 12: | Line 12: | ||
(contact Verific Tech Support if you don't have credentials for Verific Documentation). | (contact Verific Tech Support if you don't have credentials for Verific Documentation). | ||
| − | There are application examples in Verific distribution: | + | There are application examples in Verific's software distribution: |
examples/verilog/parse_encrypted_RTL | examples/verilog/parse_encrypted_RTL | ||
examples/verilog/parse_encrypted_RTL_1735style | examples/verilog/parse_encrypted_RTL_1735style | ||
| − | Verific does not implement nor provide encryption/decryption algorithms for several reasons: | + | Verific does not implement nor provide our own encryption/decryption algorithms for several reasons: |
| − | * If Verific were to provide encryption algorithms, | + | * If Verific were to provide encryption algorithms, we would have to provide the decryption algorithms. Verific has always been shipping source code and is not set up to ship binaries. If Verific shipped the implementations of the encryption/decryption algorithms in the form of C++ source code, that would defeat the purpose of encryption in the first place. |
| − | * If Verific provided encryption/decryption algorithms, | + | * If Verific provided encryption/decryption algorithms, we would ship the same implementations to all of our licensees. Many licensees of our licensees are direct competitors of each other. A company would not want its competitors to have access to its encryption/decryption algorithms. |
| − | * As | + | * As a provider of encryption/decryption algorithms, Verific would be responsible for providing measures to prevent security breaches. Since the encryption/decryption implementations would be shipped to multiple licensees, there would be no guarantee that the algorithms would enjoy the same protection as the licensees' IPs would. It is not fair nor practical to expect Verific to bear this responsibility. |
So the task of encryption/decryption implementations is appropriately reserved to the licensee. | So the task of encryption/decryption implementations is appropriately reserved to the licensee. | ||
Revision as of 09:35, 29 October 2024
Q: Does Verific provide support for IEEE 1735 encryption standard?
Note: This article mentions only "encryption/decryption algorithms," but the same arguments also apply to "encryption/decryption keys."
Verific provides APIs with which our licensees can plug in their proprietary encryption/decryption algorithms.
For technical details, please see:
Parsing Protected and IEEE 1735 Encrypted RTL Files (contact Verific Tech Support if you don't have credentials for Verific Documentation).
There are application examples in Verific's software distribution:
examples/verilog/parse_encrypted_RTL examples/verilog/parse_encrypted_RTL_1735style
Verific does not implement nor provide our own encryption/decryption algorithms for several reasons:
- If Verific were to provide encryption algorithms, we would have to provide the decryption algorithms. Verific has always been shipping source code and is not set up to ship binaries. If Verific shipped the implementations of the encryption/decryption algorithms in the form of C++ source code, that would defeat the purpose of encryption in the first place.
- If Verific provided encryption/decryption algorithms, we would ship the same implementations to all of our licensees. Many licensees of our licensees are direct competitors of each other. A company would not want its competitors to have access to its encryption/decryption algorithms.
- As a provider of encryption/decryption algorithms, Verific would be responsible for providing measures to prevent security breaches. Since the encryption/decryption implementations would be shipped to multiple licensees, there would be no guarantee that the algorithms would enjoy the same protection as the licensees' IPs would. It is not fair nor practical to expect Verific to bear this responsibility.
So the task of encryption/decryption implementations is appropriately reserved to the licensee.
