Skip to content
This repository has been archived by the owner on Jul 1, 2024. It is now read-only.

Initial #9

Closed
wants to merge 91 commits into from
Closed

Initial #9

wants to merge 91 commits into from

Conversation

chris-giblin
Copy link
Contributor

Initial commit for review

Copy link
Member

@tombentley tombentley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very quick initial pass.

@chris-giblin
Copy link
Contributor Author

Thanks @tombentley for the first pass and resulting suggestions, all of which I have committed.

Comment on lines +27 to +28
public static final String AES_GCM_PADDING = AES + "/GCM/PKCS5Padding";
public static final String AES256_GCM_NOPADDING = "AES_256/GCM/NoPadding";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do both of these have the property that size(plaintext) == size (ciphertext)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

size (ciphertext) = size(plaintext) + len(GCM authtag) where len(GCM authtag) = 16

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AES GCM is essentially a streaming cipher without padding. The cipher "AES/GCM/PKCS5Padding" is from a different crypto provider I was testing and can be removed. Most Java crypto providers do not support this cipher. When it is supported by a crypto provider, my understanding is that "AES/GCM/PKCS5Padding" is effectively AES GCM NoPadding.

For our purposes, we can assume no padding for AES GCM encryption (although there is always a 16 byte authentication tag, as mentioned above).

// encrypt record value:
byte[] plaintext = new byte[record.valueSize()];
record.value().get(plaintext);
EncData ciphertext = encrypter.encrypt(plaintext);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking about topic encryption and the fact that it can increase the size of messages, both due to padding in the cipher (possibly, see https://github.com/strimzi/topic-encryption/pull/9/files#r850136676) and also for including things like the IV. If the proxy and the broker had the same max.message.size then it would mean the proxy might accept a message, but the broker reject it because of size inflation caused by the proxy. You could get away with just configuring the proxy with a smaller max.message.size than the broker if you could assume the inflation is a constant for a whole batch. But right now encryption is per-message. Which means for small messages the extra IV data could result in a large proportional increase in batch size, even in the absence of padding from the encryption algorithm.

Copy link
Contributor Author

@chris-giblin chris-giblin Apr 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Valid points.

In the existing scheme, the encryption metadata stored with each message, in bytes:

  • 2 (version)
  • 2 (IV length)
  • 16 (IV)
  • 2 (ciphertext length)
  • 16 (GCM authentication tag)

Total: 38 bytes "overhead" per encrypted message.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have created issue #15

Copy link
Member

@tombentley tombentley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a much deeper pass on the encryption bits (not really done the proxy bits, but I'm happy to leave those for now)

@@ -38,3 +38,7 @@ classes/
# MacOS
.DS_Store

# config files
vertx-proxy/src/main/resources/config.json
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this really be excluded?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The config file could contain credentials as we integrate with key management systems. Excluding the config file, at least for the time being, is a defensive action to prevent credentials being accidentally pushed into github in the future.

Comment on lines +16 to +17
Buffer rawMsg;
ByteBuffer payload;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

private

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these members are accessed directly by subclasses. Either protected or default visibility

Comment on lines +14 to +16
public static final String LISTENING_PORT = "listening_port";
public static final String KAFKA_BROKERS = "kafka_broker";
public static final String POLICY_REPO = "policy_repo";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If they're just constants why not declare them on the outer class?

Copy link
Contributor Author

@chris-giblin chris-giblin Apr 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I anticipate many config params and use static classes as a way to group related constants as opposed to maintaining a long list of constants. But I am perfectly willing to forego the inner class for now and address large number of constants when we cross that bridge.

Signed-off-by: Chris Giblin <[email protected]>
Signed-off-by: Chris Giblin <[email protected]>
Signed-off-by: Chris Giblin <[email protected]>
Signed-off-by: Chris Giblin <[email protected]>
Signed-off-by: Chris Giblin <[email protected]>
Signed-off-by: Chris Giblin <[email protected]>
Signed-off-by: Chris Giblin <[email protected]>
Signed-off-by: Chris Giblin <[email protected]>
chris-giblin and others added 19 commits April 25, 2022 10:40
Signed-off-by: Chris Giblin <[email protected]>
Signed-off-by: Chris Giblin <[email protected]>
Signed-off-by: Chris Giblin <[email protected]>
Signed-off-by: Chris Giblin <[email protected]>
Signed-off-by: Chris Giblin <[email protected]>
Signed-off-by: Chris Giblin <[email protected]>
Signed-off-by: Chris Giblin <[email protected]>
Signed-off-by: Chris Giblin <[email protected]>
@chris-giblin chris-giblin mentioned this pull request Apr 25, 2022
@chris-giblin
Copy link
Contributor Author

Closing this PR because numerous ongoing commits and a rebase error have made this PR too unwieldy.
The changes are now consolidated in the new PR #16 which supersedes this one.

@chris-giblin chris-giblin deleted the initial branch May 6, 2022 09:37
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants