Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: wrap base64-encoded PEM with 64-char line boundary #1292

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

littledivy
Copy link

According to RFC7468:

Generators MUST wrap the base64-encoded lines so that each line
consists of exactly 64 characters except for the final line, which
will encode the remainder of the data (within the 64-character line
boundary), and they MUST NOT emit extraneous whitespace.

Parsers can avoid branching and prevent timing sidechannel attacks. Ref https://arxiv.org/pdf/2108.04600.pdf

Fixes compatibility with Deno as it enforces stricter handling of PEM.

According to [RFC7468](https://datatracker.ietf.org/doc/html/rfc7468)

> Generators MUST wrap the base64-encoded lines so that each line
  consists of exactly 64 characters except for the final line, which
  will encode the remainder of the data (within the 64-character line
  boundary), and they MUST NOT emit extraneous whitespace.

Parsers can avoid branching and prevent timing sidechannel attacks. Ref https://arxiv.org/pdf/2108.04600.pdf

Fixes compatibility with Deno as it enforces stricter handling of PEM.
@rom1504
Copy link
Member

rom1504 commented Mar 17, 2024

how did you check this improve something?

@rom1504
Copy link
Member

rom1504 commented Jun 2, 2024

Hi @littledivy if nobody can verify that fix solve some issues, I think we should close this PR

@ozaner
Copy link

ozaner commented Jul 24, 2024

Hey @rom1504 this solves Deno compatibility. Without this fix, the node-minecraft-protocol library would only work with the NodeJS runtime and not others that have properly implemented RFC7468 (i.e. Deno). I've verified that this is a blocker towards that goal.

@rom1504
Copy link
Member

rom1504 commented Jul 25, 2024

What example were you able to run with deno?

@extremeheat
Copy link
Member

It may be the standard length, but for Minecraft we'd likely want to match the encoding behavior to be like vanilla Minecraft otherwise it's one of the areas that can be easily flagged by server software (like anticheat, antibot, etc).

I'm looking into the vanilla behavior here.

Copy link
Member

@extremeheat extremeheat left a comment

Choose a reason for hiding this comment

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

@@ -223,7 +223,7 @@ module.exports = function (client, server, options) {
function mcPubKeyToPem (mcPubKeyBuffer) {
let pem = '-----BEGIN RSA PUBLIC KEY-----\n'
let base64PubKey = mcPubKeyBuffer.toString('base64')
const maxLineLength = 76
const maxLineLength = 64
Copy link
Member

@extremeheat extremeheat Jul 25, 2024

Choose a reason for hiding this comment

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

For server/ we can keep it at 76 (but it probably won't matter whatever the width is as vanilla client doesn't care). It's not going to break Deno or anything as this call result isn't passed to anything except being sent to clients.

@@ -79,7 +79,7 @@ module.exports = function (client, options) {
function mcPubKeyToPem (mcPubKeyBuffer) {
let pem = '-----BEGIN PUBLIC KEY-----\n'
let base64PubKey = mcPubKeyBuffer.toString('base64')
const maxLineLength = 65
const maxLineLength = 64
Copy link
Member

@extremeheat extremeheat Jul 25, 2024

Choose a reason for hiding this comment

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

For the client/ width seems to not matter at all as it's not sent to server or anything but just as an intermediate variable that we pass to encrypt method -

const pubKey = mcPubKeyToPem(packet.publicKey)

@ozaner
Copy link

ozaner commented Jul 25, 2024

I see. Honestly, even though I didn't make this PR, I think it should be closed.

The main purpose of this PR was to enable Deno support, but since changing these widths seems to go against the actual Minecraft protocol, and since more work beyond changing these widths would probably need to be done to make it compatible with Deno, it doesn't seem worth it.

A full on proper port of this package is probably necessary for anyone wanting to use it with Deno (or better Deno-Node compatibility) which is definitely not in the scope of this project.

Thanks @extremeheat for helping to investigate this though.

@extremeheat
Copy link
Member

No, what I said was that only the client PEM encoder method needs to be changed, and that changing it here would have no effect on anything (beyond maybe fixing Deno). The width doesn't matter to nmp as long as it can be read by the crypto call.

On the server code there is nothing to change

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Almost too old
Development

Successfully merging this pull request may close these issues.

4 participants