[jira] [Comment Edited] (LOG4J2-2930) Add plugin for encrypting/decrypting log events

["Matt Sicker (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4J2-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202892#comment-17202892 ] 

Matt Sicker edited comment on LOG4J2-2930 at 9/27/20, 6:59 PM:
---------------------------------------------------------------

Looking for standards, I've found our old friends OpenPGP and S/MIME, both of which are overly complicated for this type of feature. There's also [PURB|https://en.wikipedia.org/wiki/PURB_(cryptography)] which sounds neat, but it's more theoretical than practical unless I can find some examples.

Edit: example code is available in [this golang module|https://github.com/dedis/purb]. After reading through the paper, there are two useful ideas to take from here (otherwise, the whole concept is out of scope for our use as it generalizes into multiple recipients):

# The use of generated key pairs for shared secrets for each message can indeed work (this is ephemeral key exchange), though the PURB paper goes on to specify that these public keys should be encoded using a function that maps "group elements" (i.e., the underlying mathematical structure the key encodes) to a uniform random string. Such a transformation is _not_ required when using ciphers like X25519 where the group elements already satisfy that property (this looks like a necessary step for traditional elliptic curves, though). Being a sample plugin, this could simply use X25519 (with an optional Bouncy Castle or similar crypto dependency for older JDKs) to avoid needing to include fancy cryptographic math code.
# To prevent the size of messages being used to leak information (typically via statistical analysis), the use of padding is still recommended even though we'd be using authenticated stream ciphers which don't require padding. The padding algorithm suggested in the paper is called "Padme" which takes advantage of floating point numbers' representation to find a padding length with little overhead. This algorithm is specified as such: given a length L, we compute the padding length L' as:

{code}
let E = floor(log2(L))
let S = floor(log2(E)) + 1
let z = E - S
let m = (1 << z) - 1
let L' = (L + m) & ~m
{code}

Unfortunately, {{java.lang.Math}} doesn't have a base 2 log, so hopefully we don't lose accuracy by converting that to log(n)/log(2).


was (Author: jvz):
Looking for standards, I've found our old friends OpenPGP and S/MIME, both of which are overly complicated for this type of feature. There's also [PURB|https://en.wikipedia.org/wiki/PURB_(cryptography)] which sounds neat, but it's more theoretical than practical unless I can find some examples.

> Add plugin for encrypting/decrypting log events
> -----------------------------------------------
>
>                 Key: LOG4J2-2930
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2930
>             Project: Log4j 2
>          Issue Type: New Feature
>          Components: Appenders, Core, Receivers
>    Affects Versions: 2.13.3
>            Reporter: Matt Sicker
>            Priority: Major
>
> Some of the existing appenders write log events to sophisticated systems which support encrypting said data at rest and in transit (e.g., storing events in an encrypted SQL database using a TLS connection, writing data to an encrypted filesystem or disk, etc.) However, not every system supported in Log4j provides a feature or ability to encrypt and decrypt data natively. There are a small collection of ad hoc cryptographic operations in Log4j (e.g., {{SslConfiguration}}, {{KeyStoreConfiguration}}, {{SecretKeyProvider}}, etc.) which should be refactored and extended to allow for more flexibility in key management and message encryption/decryption. This will allow appenders and receivers that wish to support encryption to do so much more easily. This should also allow for more sophisticated use of cryptography such as adding message digests or authentication tags to log messages to help prevent tampering and add authenticity.
> Related resources:
> * https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html
> * https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html
> * https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html#protection



--
This message was sent by Atlassian Jira
(v8.3.4#803005)