• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Custom IC SKILL
  3. encryption question

Stats

  • Locked Locked
  • Replies 5
  • Subscribers 142
  • Views 16923
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

encryption question

mctang
mctang over 9 years ago

Hi  All,

1. I type the following command in CIW

     encrypt( "abc.il" , "abc_enc.il")

    Could anther user convert abc_enc.il to ASCII file ?

2.  I type the following command in CIW

     encrypt( "abc.il" , "abc_enc.il", "pass" )

    Could anther user convert abc_enc.il to ASCII skill file if the user has the password ?

Thanks,

ManChak

  • Cancel
Parents
  • Andrew Beckett
    Andrew Beckett over 9 years ago

    To answer the original questions, a non-password encrypted file is pretty easy to see the source; I won't go into the details here - but you should simply class this as a minor deterrent against somebody being able to mess with the code, rather than any protection.

    If you provide a password when encrypting the file, then the method typically used to see the source no longer works. You do need to provide the password when loading the file (second argument to the load() function), and as with all encryption, the code is read protected (you cannot use the pp() function). I wouldn't say the encryption is "strong" but I'm not sure I'm aware of anyone who has gone to the lengths to figure out how to crack the encryption.

    As Lawrence said, generally a context file offers the best protection as you're essentially providing the compiled virtual machine code. Provided you remember to set writeProtect before you create the context, the code won't be pp-able.

    I tend to use password-encryption for small fixes that need protecting, and context files for bigger chunks of code.

    Kind Regards,

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • Andrew Beckett
    Andrew Beckett over 9 years ago

    To answer the original questions, a non-password encrypted file is pretty easy to see the source; I won't go into the details here - but you should simply class this as a minor deterrent against somebody being able to mess with the code, rather than any protection.

    If you provide a password when encrypting the file, then the method typically used to see the source no longer works. You do need to provide the password when loading the file (second argument to the load() function), and as with all encryption, the code is read protected (you cannot use the pp() function). I wouldn't say the encryption is "strong" but I'm not sure I'm aware of anyone who has gone to the lengths to figure out how to crack the encryption.

    As Lawrence said, generally a context file offers the best protection as you're essentially providing the compiled virtual machine code. Provided you remember to set writeProtect before you create the context, the code won't be pp-able.

    I tend to use password-encryption for small fixes that need protecting, and context files for bigger chunks of code.

    Kind Regards,

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information