pem-rfc7468: Handle non-standard line sizes when decoding

[kjvalencik]

RFC 7468 states that parsers may handle other line sizes.

OpenSSH encoded private keys use a line-length of 70, but are otherwise compliant with RFC 7468. Supporting non-standard line sizes would allow pem-rfc7468 to read these keys.

Unfortunately, handling non-standard sizes is likely to cause a performance regression for a couple of reasons:

• Need to scan for newlines instead of splitting at exact points
• Need to handle partial data because 70 (or other values) may not be an exact base64 chunk

For those reasons, I propose additional decoder methods that are less strict.

• decode_less_strict
• decode_vec_less_strict

[tarcieri]

It might make sense to add some sort of configuration struct which could contain among other things the expected line-wrapping width, and have decode_with_config/encode_with_config methods (or perhaps Config::decode/Config::encode although that's a little strange).

That would make it possible to add various other knobs in the future, e.g. supporting more than just the "strict" interpretation of the grammar.

Edit: another bikeshedding option rather than a "config" struct would be to move the implementation to something like a Pem struct, and have the existing decode/encode static functions use Pem::default().

[kjvalencik]

I'm not sure if the non-alloc version is valuable. It's not trivial to handle arbitrary line-lengths without allocating. base64ct would need to be updated to handle partial inputs.

It might be better to initially leave that out of the design space.

[tarcieri]

We support heapless targets for all crates we develop. But accepting the linewrapping width as an option is pretty simple.

I'll go ahead and open a PR and you can tell me if it addresses your concerns.

[tarcieri]

I went ahead and merged #177 which adds support for decoding other wrap widths so long as they're a nonzero multiple of 4.

This unfortunately doesn't cover the OpenSSH case of a wrap width of 70.

I'm sorry to say that's just a poor choice for a Base64 wrap width, which I think would unduly complicate the implementation of this crate, because it would necessitate adding a buffer to the Base64 decoder.

This crate's goals are simplicity, sidechannel resistance, and support for "heapless" environments. I wouldn't necessarily be actively opposed to adding a buffered Base64 decoder, but that's complexity we'd need to take on just to address this particular corner case, and in doing so we run the risk of introducing bugs in the "99% case", so that's at least a bit worrisome.

[tarcieri]

You might be interested to know we've implemented a crate providing a format parser for OpenSSH private keys:

https://github.com/RustCrypto/formats/tree/master/ssh-key

I added a buffered Decoder to the base64ct crate. The pem-rfc7468 crate doesn't use it yet though, as it's somewhat complicated and though fairly well-tested it's also brand new and I'm not fully confident in it.

The ssh-key crate should solve your original request for a constant-time OpenSSH private key parser, though.