Jump to content

Search the Community

Showing results for tags 'bytes encoding'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Accellera Systems Initiative
    • Information
    • Announcements
    • In the News
  • SystemC
    • SystemC Language
    • SystemC AMS (Analog/Mixed-Signal)
    • SystemC TLM (Transaction-level Modeling)
    • SystemC Verification (UVM-SystemC, SCV)
    • SystemC CCI Public Review
  • UVM (Universal Verification Methodology)
    • Methodology and BCL Forum
    • UVM SystemVerilog Discussions
    • Simulator Specific Issues
    • 1800.2-2017 Early Adopter Release
    • UVM Commercial Announcements
    • UVM 1.2 Public Review
  • Portable Stimulus
    • Portable Stimulus Discussion
  • IP-XACT
    • IP-XACT Discussion
  • IEEE 1735/IP Encryption
    • IEEE 1735/IP Encryption Discussion
  • OCP (Open Core Protocol)
  • UCIS (Unified Coverage Interoperability Standard)
  • Commercial Announcements
    • Announcements

Categories

  • SystemC
  • UVM
  • UCIS
  • IEEE 1735/IP Encryption

Calendars

  • Community Calendar

Found 1 result

  1. I have heard a couple of comments regarding the bytes field in the decryption envelope, that it is not completely clear in the published standard. Here is an unofficial clarification from one implementation team that completed successful interoperability testing: The “bytes” field in the decryption record is the number of bytes before base64 encoding—it’s the length of the initialization vector plus the length of the encrypted text. It’s not an essential field—it conveys no information that the base64 encoding doesn’t, and could be a candidate to deprecate. It’s also impossible to compute if you’re doing on-the-fly encryption and don’t know the length of your encrypted text until you’re done.
×