Layer7 API Management

Expand all | Collapse all

How to do double length Triple DES encryption/decryption ?

  • 1.  How to do double length Triple DES encryption/decryption ?

    Posted 09-15-2016 06:12 AM



     I am trying to decrypt a string, which has been encrypted using double-length 3DES symmetric keys. However not getting any assertion in Gateway (9.0) to do so. Please help.




  • 2.  Re: How to do double length Triple DES encryption/decryption ?

    Posted 09-23-2016 12:57 PM

    Good afternoon,


    We do not support double-length 3DES in our Symmetric Encryption assertion which is the only assertion that will do symmetric key encryption and decryption. The only options would be to write a custom assertion to do this or open a feature request for the symmetric assertion which could be looked in the future.



    The asymmetric and symmetric encryption and decryption assertions are provided as a way to create compatibility to some customer defined cryptography use cases. These tools are low level cryptography primitives and shouldn't be used without clear understanding of the risks associated.


    The entire deployment:  source, destination, configuration and the tooling used to implement security is sometimes referred to as a cryptosystem.


    In nearly every customer use we know of for asymmetric and symmetric encryption and decryption assertions, the cryptosystem as deployed lacks current state of the art protections against cryptographic attacks.


    Specifically, well-scrutinized systems like SSL and WS-Security BSP have mechanisms for establishing a session key used for the symmetric cryptography, normally via the Diffie-Hellman Key Exchange:


    Without a key derivation/symmetric key refresh, both Asymmetric and Symmetric cryptography is often vulnerable to cryptographic attacks. Some symmetric ciphers are subject to  , and all symmetric crypto is weak to password derived keys – there's too little entropy, making it vulnerable to a brute force  


    Asymmetric crypto is too expensive for bulk encryption, in terms of CPU, so that's usually not a good choice for performance reasons.


    Another risk is especially present is if the tools are used without user authentication/authorization. With cypher block chaining algorithms, there's a particularly large possibility of creating a key oracle via the padding oracle attack.


    For many use cases, there is far better tooling already in the product that enables customers to set up strong security.


    For instance, the most common use cases that we've heard about are better served by existing well supported features:


        To secure parameters in an API call, SSL is far easier to implement than these tools, and is actually more secure.
        To provide encrypted credentials, JWT, JWE, JWS are good choices.
        For encrypted message bodies, JWE comes to mind as well.
        Older standards like SOAP, WSS, SAML do a lot of the same things as JWT, JWS, JWE.




    Stephen Hughes

    Director, CA Support