• PLATFORM
      • Cryptosense Analyzer
        • Analyzer for Applications
        • Analyzer for PKCS#11
      • Features
        • Custom Cryptography Policies
        • LDAP and AD Integration
        • Custom Cryptography Rules
        • REST API
        • Vulnerabilities Types Found
        • All Features
  • SOLUTIONS
      • Use Cases
        • Cryptography Inventory
        • Secure Cloud Migration
        • Automated Crypto Audits
        • Crypto Testing in the SDLC
        • Automated HSM Pen-Tests
        • All Use Cases
  • RESOURCES
      • Resources
        • Whitepapers
        • Datasheets
        • Blog
        • Training Courses
        • Cloud Crypto Comparison
      • Company
        • About Us
        • Careers
        • Partners & Resellers
        • Contact
  • SUPPORT
  • LOG IN
  • GET IN TOUCH
March 1, 2016

The Lesson From DROWN: Bad Crypto Can Be Worse Than No Crypto

Today sees the public release of details of DROWN, another “full-stack” crypto vulnerability in TLS, involving new mathematical insights into the Bleichenbacher attack on PKCS#1v1.5 encryption, implementation bugs, failure to turn off old versions and real-world implementation data from Internet-wide scans showing that DROWN affects as many as 35% of HTTPS servers. It’s a really nice piece of work – this truly is the golden age of applied crypto research.

One particular lesson from DROWN is that sometimes, bad cryptography is worse than no cryptography. For some time, the “folklore” around configuring TLS for mail transport (SMTP) has been that it is best to leave all SSL and TLS versions enabled, because if no successful SSL or TLS handshake is completed, mail transport will fall back to plaintext. But with DROWN, we see that leaving SSLv2 enabled allows an attacker to decrypt mail sent over TLS1.2, which would have otherwise been secure. If the same RSA key material is used on other servers, the mailserver’s SSLv2 can be used to attack them, as well.

DROWN should give more momentum to the movement towards secure crypto everywhere. To test your external-facing crypto services for DROWN and other issues, you can use our tool at discovery.cryptosense.com. To go deeper on the crypto inside your Java applications, try this.

 

Try Cryptosense Analyzer for Free

 

August 7, 2014

WebCrypto API Tracer

A tracer is a simple but important tool for auditing crypto security that allows the analyst to see the calls made by an application to a crypto interface. This is especially useful if the application and/or the crypto provider are only available in binary or black-box form (e.g. an HSM), but the crypto API is known. Even if source code is available, a simple tracer can save a lot of time compared to instrumenting code or manually setting trace points.

Recently we’ve been involved reviewing the draft W3C Web Crypto API. As a result of this and as part of our ongoing work on web crypto, our intern Gregoire put together a Chrome extension that traces calls to the WebCrypto API.

As you can see in the screenshots, a simple dropdown gives a list of all key objects in the session and their attributes.

key_view

Continue reading →

May 19, 2014

Why PKCS#1v1.5 Encryption Should Be Put Out of Our Misery

RSA Encryption with padding as described in PKCS#1v1.5 has been known to be insecure since Bleichenbacher’s CRYPTO 98 paper revealed a chosen ciphertext attack. PKCS#1 version 2.0, published September 1998, proposed a new padding scheme based on OAEP and recommended the old scheme not be used in any new implementations.

This hasn’t stopped PKCS#1v1.5 padding from being used just about everywhere. Take a look at this table of Smart Card support for example.

One reason might be that Bleichenbacher’s attack was though to be impractical: the worst-case analysis of the attack in the paper tells us that 2^20 chosen ciphertexts are needed, which gave rise to the name “the million message attack”.

In fact the median case is much easier than that. And like all attacks, the attack algorithm has only got better. Building on advances by Klima, Pokorny and Rosa in 2003, our work published at CRYPTO 2012 showed that the median case for the standard oracle requires less than 15 000 messages.

Still, there seems to be widespread belief that PKCS#1v1.5 is somehow ok if you use it carefully. For example, in this debate on the W3C crypto API bugzilla, one comment suggests that because TLS still uses RSA PKCS#1v1.5 then it must be possible to make secure protocols with it.

Let’s look more carefully at how TLS “fixes” the attack. Continue reading →

Interested in Crypto News?


There's a better way to Manage Cryptography

Find out how you can use Cryptosense Analyzer Platform to:

  • Automate detection of vulnerabilities in your cryptography
  • Map key lifecyles and library use before migrating to the cloud
  • Ensure regulatory compliance
  • Prepare for post-quantum crypto.
request a Demo now

Most Popular Posts

  • Parameter choice for PBKDF2
  • Cloud Encryption Part Two: Client Side Encryption for Azure Storage
  • New cryptography in .NET Core 3.0
  • Dangerous Tutorials: How not to learn C# cryptography
  • BouncyCastle Keystore Security
  • Why PKCS#1v1.5 Encryption Should Be Put Out of Our Misery
    • Features
      • Cryptography Inventory
      • Low False Positive Rate
      • Custom Cryptography Policies
      • Custom Cryptography Rules
      • LDAP and AD Integration
      • REST API
      • Easy Installation
      • Expert Support
      • All Features
    • CS Analyzer
      • Request Demo
      • Secure Cloud Migrations
      • Automated Crypto Audit
      • Crypto Testing in the SDLC
      • Automated HSM Pen-Tests
    • Resources
      • Support
      • Whitepapers
      • Blog
      • Careers
      • Contact

Follow us on Twitter FR: +33 (0)9 72 42 35 31 US: +1 646-893-7657

info@cryptosense.com

© 2012-2019 Cryptosense | All rights reserved.

  • Cryptosense Analyzer
  • Request Demo
  • Use Cases
  • Support
  • Whitepapers
  • Contact
  • About Us
  • Blog
We use cookies to deliver our services. If you continue to use this site we assume you consent to our privacy policy.ACCEPTPrivacy policy