Private Key detector misses secrets because it does not correctly align with PEM file format protocol specification(s)

[0x736E]

Please review the Community Note before submitting

TruffleHog Version

v3.0.0 and above

Trace Output

N/A

Expected Behavior

The 'Private Key' detector should detect all types of PEM formatted private key.

Actual Behavior

The 'Private Key' detector does not detect all types of PEM formatted private key:

• Keys with headers or other meta-data
• Keys which are formatted differently:
  • TruffleHog does not detect private key if it's in one line #2338
• Keys which have headers not captured by current pattern:
  • PGP PRIVATE KEY BLOCK
  • YUBIKEY PIV PRIVATE KEY
  • SSH2 ENCRYPTED PRIVATE KEY
  • OpenVPN Static key V1
  • OpenVPN tls-crypt-v2 client key
  • ...
• The current regex pattern allows for any printable character between the header and footer (or none at all)
  • This may cause lower performance as the engine tries to validate data which is captured between a header and footer as a private key which it should not because it is not valid base64 data

Steps to Reproduce

1. Create a private key such as one of those mentioned above
2. Scan the key with TruffleHog
3. It will not produce findings for those keys

Environment

• OS: All
• Version: All versions

Additional Context

The 'Private Key' detector is designed to identify instances of private keys such as RSA Private Key. It does this by looking for patterns which match the PEM file format.

This format is specified in a number of industry standards:

• RFC 1421, 1422 define the overall PEM structure.
• RFC 2315, 5280, and 4716 address specific PEM object types and their base64 formatting.
• RFC 7468 focuses on the underlying base64 encoding rules, and header specification.
• https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail

Not all aspects of PEM formatted files are codified in such standards, for example:

• Formatting of the Base64 data within a PEM formatted file is not strictly defined. Common practice is to format the data such that there are 64 characters per line, with a new line terminator. However this is not universal, and is not a strict requirement of the specification. In some cases, this may be 76 or 80 characters per line. It is possible this trend of breaking after 64 characters is actually borrowed from the way the RFC's are formatted in order to fit within an 80 character column and was never actually intended to be a standard, hence why it was not codified.
  • The only actual standard in this regard I have been able to find is on page 42 of RFC 821 - Simple Mail Transfer Protocol (SMTP). PEM formats originate in encrypted email exchange, and this RFC defines the maximum number of characters per line in an email message as 1,000 characters. So strictly speaking, no PEM key should be longer than 1,000 characters without a line-break. But as outlined above, this is not a strictly defined control and is not enforced.

References

• TruffleHog does not detect private key if it's in one line #2338