Datacom

 View Only
  • 1.  Encryption

    Posted Sep 15, 2022 12:21 PM
    We use DATACOM compression for all of our tables, and have an in-house written masking routine for social security numbers.
    I was asked, today, to investigate encryption for a number of specific data fields, on various tables.

    Can it be done by field, or does it need to be at the table level?

    Wondering what experiences people could share with us.
    What is the best source of information on the topic?
    Is there a 'cookbook' or similar type of thing in Tech Docs?


  • 2.  RE: Encryption

    Broadcom Employee
    Posted Sep 15, 2022 12:49 PM
    Steve,

    Early on I did a lot of benchmarking and could not see any performance
    benefit in just doing a few fields of a row. The encryption routines are
    such that a typical row of 300-500 bytes works as fast as asking for a
    couple columns.

    Since there was no performance benefit, we decided to go whole row
    encryption. It's much simpler, does not have to change if later a new
    column needs to be encrypted etc.

    For Datacom,

    - we offer datacom only encryption which is done at the table/row
    level. The upside is you have encrypted data to the point the row is taken
    out of the buffer and handed to the application, The downside is it is
    Datacom specific and much be managed separately from other encryption
    happening at the site.
    - we offer (with patches applied) support for IBM VSAM LDS datasets (for
    IXX and DATA areas). When you convert to VSAM LDS you can implement the
    IBM standard Pervasive encryption which can be used across many resources
    on the mainframe. The upside is you are using a platform wide encryption
    that has all the key management done at a platform (LPAR) level, The
    downside is that the encryption is down at the data block level when it is
    written or read from the dataset. So buffers in memory would be in the
    clear. In the mainframe this has not been an issue since we have memory
    protections and we removed things like shared common storage (CSA/ECSA) for
    any user data. This is what DB2, IMS, VSAM are using, so Datacom just fits
    into the same pie.
    - There is session about using IBM VSAM LDS with Pervasive encryption
    at MTE.
    - IBM VSAM support is relatively new, but we have had multiple sites
    validate it and I have one very large site in full production.



    In either case, the encryption is done for the whole row (Datacom) or in
    the whole block (IBM PE) the whole block. We don't see a lot of folks on
    mainframe going the selective column route.

    For Datacom encryption the choice is at table level, for IBM PE its at
    dataset (IXX or DATA area) level.

    Let me know if you want to talk more.

    Kevin




    Kevin Shuma
    Director of Engineering
    *Broadcom Software*
    5465 Legacy Drive, Plano, TX 75024-3106
    Mobile: 214 280-5907
    kevin.shuma@broadcom.com







    <kevin.shuma@broadcom.com>
    <http: broadcom.com/="">

    --
    This electronic communication and the information and any files transmitted
    with it, or attached to it, are confidential and are intended solely for
    the use of the individual or entity to whom it is addressed and may contain
    information that is confidential, legally privileged, protected by privacy
    laws, or otherwise restricted from disclosure to anyone else. If you are
    not the intended recipient or the person responsible for delivering the
    e-mail to the intended recipient, you are hereby notified that any use,
    copying, distributing, dissemination, forwarding, printing, or copying of
    this e-mail is strictly prohibited. If you received this e-mail in error,
    please return the e-mail to the sender, delete it from your computer, and
    destroy any printed copy of it.




  • 3.  RE: Encryption

    Posted Sep 15, 2022 02:18 PM
    Thank you so much, Kevin, for your prompt reply. I have forwarded your response to manager and Sys techs, with discussions to follow.

    Thank you,

    Stephen (Steve) Roy