RSA 공개키 등의 modulus 값에 0x00 선행 바이트가 있는 이유(ASN.1 인코딩)
지난 글에서 ssh-keygen으로 생성한 공개키 파일을 해석해 봤는데요,
C# - ssh-keygen으로 생성한 Public Key 파일 해석과 fingerprint 값(md5, sha256) 생성
; https://www.sysnet.pe.kr/2/0/13739
도저히 미심쩍어 DecodeSSHPublicKey 함수를 다시 한번 살펴봤습니다.
private static (string algorithmName, byte[] exponent, byte[] modulus) DecodeSSHPublicKey(byte[] bytesEncoded)
{
string algorithmName;
byte[] exponent;
byte[] modulus;
using (var stream = new MemoryStream(bytesEncoded))
using (var reader = new BinaryReader(stream))
{
int algorithmLength = reader.ReadInt32BE();
algorithmName = Encoding.ASCII.GetString(reader.ReadBytes(algorithmLength));
int exponentLength = reader.ReadInt32BE();
exponent = reader.ReadBytes(exponentLength);
reader.ReadByte();
int modulusLength = reader.ReadInt32BE();
modulus = reader.ReadBytes(modulusLength);
}
return (algorithmName, exponent, modulus);
}
결과적으로 1바이트를 건너뛴 것은 해석이 가능하게 만들긴 했지만, 가만 보니까 그 이후에 나오는 modulusLength의 값이 131328로 비정상적으로 나옵니다. (비정상으로 나와도 이후 ReadBytes에서 버퍼의 끝까지 읽어내는 식으로 동작해 예외는 발생하지 않습니다.)
반면 1바이트를 건너뛰지 않은 경우에는 modulusLength의 값이 513으로 그럴듯한 값이 나옵니다. 그런데, 원래 Key Size는 4096bits(512 바이트)인데요, 왜 513으로 나오는 걸까요?
아무튼, 513바이트를 읽어내면 주어진 bytesEncoded 버퍼의 끝까지 읽은 것이 맞습니다. 그리고 이때의 값은 다음과 같은데요,
00-AF-9C-D1-3B-92-F4-32-08-B2-48-8B-78...[생략]...-19-B3-40-93-48-13-5B-59-A7-0A-12-4D-EA-B1-C8-AC-1B-42-03-8A-C5-45
저렇게 가장 상위 바이트가 0x00으로 나옵니다. 이와 관련해서 찾아보면,
RSA Modulus prefaced by 0x00
; https://stackoverflow.com/questions/15953631/rsa-modulus-prefaced-by-0x00
Leading 00 in RSA public/private key file
; https://crypto.stackexchange.com/questions/30608/leading-00-in-rsa-public-private-key-file
그러니까 ASN.1 인코딩 규약을 따르기에 저렇게 0x00을 선행하는 경우가 있다고 합니다. 이게 뭔 소린지 좀 이상할 수 있는데요, 간단하게 설명해 보면 대충 이런 식입니다.
가령 8bit 정수를 인코딩 할 때 0b10000000으로 128을 나타낸다고 가정해 보겠습니다. 문제는 128을 나타내고 싶었던 건데 가장 최상위 비트가 1이라는 점으로 인해 음수로 해석할 수 있는 여지가 있다는 것입니다.
실제로 (양의 정수) 2개의 소수를 곱해 표현하는 modulus 값이 Key Size의 바이트 범위로 표현이 될 때 가장 상위 바이트가 1이 되는 경우가 종종 나올 수 있는데요, 이럴 때 저 값을 음수가 아닌 양수로 해석할 수 있도록 0x00을 선행하는 것입니다.
이에 기반해 위의 예제를 다시 보면, 최상위 바이트가 0xAF == 0b10101111이고, 따라서 상위 비트가 1이므로 0x00을 선행하여 출력한 것입니다.
결국, 첫 바이트가 0x00인 경우 그걸 무시하고 이후부터 읽어내 RSAParameters를 구성하면 됩니다.
private static (string algorithmName, byte[] exponent, byte[] modulus) DecodeSSHPublicKey(byte[] bytesEncoded)
{
string algorithmName;
byte[] exponent;
byte[] modulus;
using (var stream = new MemoryStream(bytesEncoded))
using (var reader = new BinaryReader(stream))
{
int algorithmLength = reader.ReadInt32BE();
algorithmName = Encoding.ASCII.GetString(reader.ReadBytes(algorithmLength));
int exponentLength = reader.ReadInt32BE();
exponent = reader.ReadBytes(exponentLength);
int modulusLength = reader.ReadInt32BE();
if (bytesEncoded[stream.Position] == 0) // reader.PeekByte가 없군요. ^^;
{
reader.ReadByte();
modulusLength--;
}
modulus = reader.ReadBytes(modulusLength);
}
return (algorithmName, exponent, modulus);
}
좀 더 찾아보니까,
RFC 4251 문서에도 이와 관련된 내용이 나옵니다.
mpint
Represents multiple precision integers in two's complement format,
stored as a string, 8 bits per byte, MSB first. Negative numbers
have the value 1 as the most significant bit of the first byte of
the data partition. If the most significant bit would be set for
a positive number, the number MUST be preceded by a zero byte.
Unnecessary leading bytes with the value 0 or 255 MUST NOT be
included. The value zero MUST be stored as a string with zero
bytes of data.
By convention, a number that is used in modular computations in
Z_n SHOULD be represented in the range 0 <= x < n.
그리고
RFC 4253에 저 mpint로 e, n이 표현된다고 명시돼 있습니다.
The "ssh-rsa" key format has the following specific encoding:
string "ssh-rsa"
mpint e
mpint n
음... 이것 참... 저렇게 표준 문서에 모두 나오긴 하는데... 그렇다고 저 방대한 RFC 문서를 다 훑어볼 수도 없고... ^^;
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]