You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Create a private key such as one of those mentioned above
Scan the key with TruffleHog
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:
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.
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:
Steps to Reproduce
Environment
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:
Not all aspects of PEM formatted files are codified in such standards, for example:
References
The text was updated successfully, but these errors were encountered: