Constant time base64 decoded_len returns InvalidLength on fully valid data

[httpjamesm]

I'm trying to parse an OpenSSH key using ssh_key with line lengths of 70, 70, 70, 70 and 64 without any padding, but the decoded_len (

formats/base64ct/src/decoder.rs

Line 438 in 057aa1f

fn decoded_len<E: Encoding>(&self) -> Result<usize, Error> {

) function in the base64ct crate returns InvalidLength for some reason. The process works without error on another key with line lengths of 70, 70, 70, 70 and 32 with padding. Decoding with the base64 crate and re-encoding with padding results in the same input string and the same error.

Here's the contents of the erroring key (not sensitive):

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACDctrRCQ6LEyzTbsXkAQ8mhdIOQZzP/XKcuplituD2PaQAAAKC+1uNjvtbj
YwAAAAtzc2gtZWQyNTUxOQAAACDctrRCQ6LEyzTbsXkAQ8mhdIOQZzP/XKcuplituD2PaQ
AAAEAyjynmk0ex/GrImDlAEN81gXGK4tWaq36kO+HRp8szLNy2tEJDosTLNNuxeQBDyaF0
g5BnM/9cpy6mWK24PY9pAAAAFEdlbmVyYXRlZCBCeSBUZXJtaXVzAQIDBAUGBwgJ
-----END OPENSSH PRIVATE KEY-----

It appears that the checks are a little too strict, especially when other tools, like ssh-keygen, have no issues with the key.

• ssh-key 0.6.7
• pem 0.7.0
• base64ct 1.6.0
• cargo 1.80.1

[httpjamesm]

Re-encoding the key with ssh-keygen fixed it, but it doesn't explain why the key is being rejected by base64ct