Skip to content
GitLab
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • GnuTLS GnuTLS
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 271
    • Issues 271
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 18
    • Merge requests 18
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • gnutlsgnutls
  • GnuTLSGnuTLS
  • Issues
  • #1050
Closed
Open
Issue created Jul 14, 2020 by Hubert Kario (@mention me if you need reply)@tomato42Developer

Timing sidechannel in RSA decryption

Description of problem:

The time for GnuTLS to respond to malformed RSA ciphertexts in ClientKeyExchange depends on kind of error in the RSA padding.

Generally, it looks like the response time depends on size of encrypted data in the PKCS#1 v1.5 encrypted data.

I've run tests with 1 million connections per probe, on a 2.4GHz skylake CPU with 1024 bit RSA key, the two probes with most dissimilar results were "too long (49-byte) pre master secret" and "invalid MAC in Finished on pos 0", it takes the server an extra 58.5ns to respond one over the other. This is with a 95% confidence interval of +-6.8ns.

Exact results of Wilcoxon signed-rank tests are in this report.csv file.

Version of gnutls used:

gnutls-3.6.8-11.el8_2.x86_64

Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL)

RHEL 8

How reproducible:

Time the server responses to differently malformed ClientKeyExchange data.

Actual results:

Timing of server responses depends on the way RSA ciphertext is malformed

Expected results:

The timing of server responses should be completely independent of the RSA ciphertexts.

Additional info:

We're aware of other implementations that have the timing sidechannel, we'd like to coordinate the release of this information to the public.

Edited Feb 10, 2023 by Hubert Kario (@mention me if you need reply)
Assignee
Assign to
Time tracking