Difference between revisions of "Support IEEE 1735 encryption standard"
From Verific Design Automation FAQ
| Line 1: | Line 1: | ||
| − | '''Q:Does Verific provide support for IEEE 1735 encryption standard?''' | + | '''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 "decryption/encryption '''keys'''."'' | ||
| + | |||
| + | |||
| + | Verific provides APIs with which the licensees can plug in their proprietary encryption/decryption algorithms. | ||
For technical details, please see: | For technical details, please see: | ||
| Line 12: | Line 16: | ||
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: | ||
| + | |||
| + | * If Verific were to provide encryption algorithms, Verific 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, it would ship the same implementations to all of its licensees. Many licensees of Verific are direct competitors. A company would not want its competitors to have access to its encryption/decryption algorithms. | ||
| + | |||
| + | * As the provider of encryption/decryption algorithms, Verific would be responsible for providing measures to prevent security breaching. Since the encryption/decryption implementations were 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 the responsibility. | ||
| + | |||
| + | So the task of encryption/decryption implementations is appropriately reserved to the licensee. | ||
Latest revision as of 22:27, 24 July 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 "decryption/encryption keys."
Verific provides APIs with which the 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 distribution:
examples/verilog/parse_encrypted_RTL examples/verilog/parse_encrypted_RTL_1735style
Verific does not implement nor provide encryption/decryption algorithms for several reasons:
- If Verific were to provide encryption algorithms, Verific 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, it would ship the same implementations to all of its licensees. Many licensees of Verific are direct competitors. A company would not want its competitors to have access to its encryption/decryption algorithms.
- As the provider of encryption/decryption algorithms, Verific would be responsible for providing measures to prevent security breaching. Since the encryption/decryption implementations were 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 the responsibility.
So the task of encryption/decryption implementations is appropriately reserved to the licensee.
