Microsoft MVP성태의 닷넷 이야기
.NET Framework: 327. RSAParameters와 System.Numerics.BigInteger 이야기 [링크 복사], [링크+제목 복사]
조회: 17565
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)
(시리즈 글이 10개 있습니다.)
.NET Framework: 292. RSACryptoServiceProvider의 공개키와 개인키 구분
; https://www.sysnet.pe.kr/2/0/1218

.NET Framework: 327. RSAParameters와 System.Numerics.BigInteger 이야기
; https://www.sysnet.pe.kr/2/0/1295

.NET Framework: 329. C# - Rabin-Miller 소수 생성방법을 이용하여 RSACryptoServiceProvider 의 개인키를 직접 채워보자
; https://www.sysnet.pe.kr/2/0/1300

.NET Framework: 356. (공개키를 담은) 자바의 key 파일을 닷넷의 RSACryptoServiceProvider에서 사용하는 방법
; https://www.sysnet.pe.kr/2/0/1401

.NET Framework: 383. RSAParameters의 ToXmlString과 ExportParameters의 결과 비교
; https://www.sysnet.pe.kr/2/0/1491

.NET Framework: 565. C# - Rabin-Miller 소수 생성 방법을 이용하여 RSACryptoServiceProvider의 개인키를 직접 채워보자 - 두 번째 이야기
; https://www.sysnet.pe.kr/2/0/10925

.NET Framework: 566. openssl의 PEM 개인키 파일을 .NET RSACryptoServiceProvider에서 사용하는 방법
; https://www.sysnet.pe.kr/2/0/10926

.NET Framework: 638. RSAParameters와 RSA
; https://www.sysnet.pe.kr/2/0/11140

.NET Framework: 1037. openssl의 PEM 개인키 파일을 .NET RSACryptoServiceProvider에서 사용하는 방법 (2)
; https://www.sysnet.pe.kr/2/0/12598

.NET Framework: 2093. C# - PEM 파일을 이용한 RSA 개인키/공개키 설정 방법
; https://www.sysnet.pe.kr/2/0/13245




RSAParameters 와 System.Numerics.BigInteger 이야기


RSAParameters는 다음과 같이 간단한 구조체에 불과합니다.

[Serializable, StructLayout(LayoutKind.Sequential), ComVisible(true)]
public struct RSAParameters
{
    public byte[] Exponent;
    public byte[] Modulus;
    [NonSerialized]
    public byte[] P;
    [NonSerialized]
    public byte[] Q;
    [NonSerialized]
    public byte[] DP;
    [NonSerialized]
    public byte[] DQ;
    [NonSerialized]
    public byte[] InverseQ;
    [NonSerialized]
    public byte[] D;
}

RSA에 대해서 아시거나... 혹은 다음의 도움말을 참고해보면,

RSAParameters Structure
; https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.rsaparameters

아래의 공식이 성립하는 것을 볼 수 있습니다.

Modulus == D * Q

그럼, 정말로 그런지 한번 테스트 해볼까요? 이를 확인하기 위해 System.Security.Cryptography.RSAParameters 타입을 생성하면 되는데,

RSACryptoServiceProvider rsa = new RSACryptoServiceProvider();
Console.WriteLine(rsa.KeySize); // 1024

System.Security.Cryptography.RSAParameters rsaParam = rsa.ExportParameters(true);

여기서 "KeySize == Modulus 비트 수"입니다. RSACryptoServiceProvider 타입은 (Microsoft Enhanced Cryptographic Provider에 의해) 기본적으로 1024 길이의 비트를 생성하기 때문에, 따라서 Modulus 값은 (1024 / 8) == 128바이트의 배열이 되고, 소수인 D 와 Q 값은 64바이트로 구성됩니다. 그렇다면, 64바이트 값을 어떻게 숫자로 표현할 수 있을까요? int == 4바이트, long == 8바이트이기 때문에 이런 경우는 .NET 4.0에서 새롭게 제공되는 System.Numerics.BigInteger 타입을 이용해야 합니다.

그렇게 해서 최종적으로 검증해 보면 다음과 같이 나옵니다.

var rsaParam = rsa.ExportParameters(true);

BigInteger p = new BigInteger(rsaParam.P);
BigInteger q = new BigInteger(rsaParam.Q);

Console.WriteLine("P == " + p);
Console.WriteLine();
Console.WriteLine("Q == " + q);
Console.WriteLine();
Console.WriteLine();

BigInteger expectModulus = p * q;
BigInteger realModulus = new BigInteger(rsaParam.Modulus);

Console.WriteLine("expect == " + expectModulus);
Console.WriteLine();
Console.WriteLine("real == " + realModulus);
Console.WriteLine();
Console.WriteLine();

Console.WriteLine(expectModulus == realModulus);

// 출력 결과
P == 1745347117586124307562205124286981362442227763277912640750731532696045914361892339770449856387948878818154992652330479951788437061857370883395881528451063

Q == -2831377943566696349004974146379573665554872347974010564465244410976940341475835118677977005548443979634625788268996007446130714733671878050920424168711433


expect == -4941737332601061606570187639549427718961295189156172733040629026496217387840960517507341781860167036894747005869475064044704332300007926725569534038965955079267069563372191094586565054803509844616827366332886219041144233218481874255267563142125606547422977188664512747390151137223352939005270173921109103279

real == -16006374138550337361913895556834746249117422527852669572216124554020516563250980797049053677292949829318290649342785628587299165879371350772513931531074679499167095600766366968566255398032852895784920219487284111177709190850812490257181200566885064876772887181829227853031677929745974169705512945745218126097

False

솔직히, 위의 결과를 보고 매우 당혹스러웠는데요. codeproject에서 다음의 클래스를 다운로드해서 다시 검증을 시도해 보면서 희미하게 나마 길이 보이기 시작했습니다.

C# BigInteger Class
; http://www.codeproject.com/Articles/2728/C-BigInteger-Class

P == 13166127462085329373727425166872120986194216491356932086431169554619716019875387246531996148969249129949565580040266682598776454158918312549723959628032699

Q == 11390141563278975215819305956455532350216609406733079257245450072905569011882636528766209599715416605839390753590072712761658668466252783809241838580216743


expect == 149964055633326840002477251389683051260311657686489276520978618664425141749178160915585112396507001611162179675210170283871705549806201579779103084984128959100324337444518674590820398847138520023398114796723776140324034040066128137956589979334949391106309587487953021118120395908293916435156067301386111279357

real == 149964055633326840002477251389683051260311657686489276520978618664425141749178160915585112396507001611162179675210170283871705549806201579779103084984128959100324337444518674590820398847138520023398114796723776140324034040066128137956589979334949391106309587487953021118120395908293916435156067301386111279357


True

세상에... .NET 4.0 클래스에서는 예기치 않은 결과가 나온 반면, codeproject에서 다운로드한 BigInteger는 정상적으로 검증이 된 것입니다.

도대체, System.Numerics.BigInteger에 어떤 차이점이 있는 걸까요?




차이를 확인하기 위해 다음과 같이 간단한 배열을 사용해서 초기화를 해봤습니다.

{
    byte[] t1 = new byte[] { 0xF0, 0, 0, 0, 0, 0, 0, 0, 0 }; // 0xF0 == 240

    BigInteger b1 = new BigInteger(t1);
    Console.WriteLine("codeproject BigInteger == " + b1);
    System.Numerics.BigInteger nb1 = new System.Numerics.BigInteger(t1);
    Console.WriteLine(".NET 4.0 BigInteger == " + nb1);
}

// 출력 결과
codeproject BigInteger == 4427218577690292387840
.NET 4.0 BigInteger == 240

짐작하시겠지요? 이것을 기반으로 도움말을 찾아보니,

BigInteger Constructor (Byte[])
; https://learn.microsoft.com/en-us/dotnet/api/system.numerics.biginteger.-ctor

Little endian 이야기가 나옵니다.

The individual bytes in the value array should be in little-endian order

아하... 그렇다면, RSAParameters의 인자에 기록되어 있던 모든 바이트 배열은 Big Endian 식으로 기록한 값이라는 의미가 되는군요.

따라서, System.Numerics.BigInteger에서 RSAParameters의 개별값들을 정상적으로 인식시키기 위해서는 역순 배열을 해주어야 합니다.

그런데, 차이점은 그뿐만이 아닙니다. 위의 예제 코드를 다음과 같이 바꿔보면 알 수 있는데요.

{
    byte[] t1 = new byte[] { 0, 0, 0, 0, 0, 0, 0, 0xF0 }; // 0xF0 == 240

    BigInteger b1 = new BigInteger(t1);
    Console.WriteLine("codeproject BigInteger == " + b1);
    System.Numerics.BigInteger nb1 = new System.Numerics.BigInteger(t1);
    Console.WriteLine(".NET 4.0 BigInteger == " + nb1);

    byte[] nb1Bytes = nb1.ToByteArray();
}

codeproject BigInteger == 240
.NET 4.0 BigInteger == -295147905179352825856

원했던 결과는 4427218577690292387840인데, 엉뚱하게 -295147905179352825856라는 음수값이 나온 것입니다. System.Numerics.BigInteger와 codeproject의 BigInteger 간의 두 번째 차이점이 바로 '음수 표현'입니다.

System.Numerics.BigInteger는, 2의 보수표현에 의한 signed 지원을 하고 있는 반면 codeproject의 BigInteger 값은 -1을 표현하려면 280개의 255 값을 가진 바이트 배열이 필요합니다. (정확히 그 수가 아니면 unsigned BigInteger로 표현을 합니다.)




자... 그럼, 대강 준비가 모두 끝났습니다.

위의 내용에 기반해서 RSAParameters의 값들을 설명해 보면, 모두 unsigned에다가 BigEndian으로 표현되어 있다는 점입니다.

따라서, 최종적으로 아래와 같이 코드를 만들어 주면, Modulus == P * Q 식을 검증할 수 있게 됩니다.

{
    List<byte> pList = new List<byte>();
    pList.Add(0);
    pList.AddRange(rsaParam.P);
    pList.Reverse();

    List<byte> qList = new List<byte>();
    qList.Add(0);
    qList.AddRange(rsaParam.Q);
    qList.Reverse();

    System.Numerics.BigInteger p = new System.Numerics.BigInteger(pList.ToArray());
    System.Numerics.BigInteger q = new System.Numerics.BigInteger(qList.ToArray());

    Console.WriteLine("P == " + p);
    Console.WriteLine();
    Console.WriteLine("Q == " + q);
    Console.WriteLine();
    Console.WriteLine();

    System.Numerics.BigInteger expectModulus = p * q;

    List<byte> modList = new List<byte>();
    modList.Add(0);
    modList.AddRange(rsaParam.Modulus);
    modList.Reverse();

    System.Numerics.BigInteger realModulus = new System.Numerics.BigInteger(modList.ToArray());

    Console.WriteLine("expect == " + expectModulus);
    Console.WriteLine();
    Console.WriteLine("real == " + realModulus);
    Console.WriteLine();
    Console.WriteLine();

    Console.WriteLine(expectModulus == realModulus);
}

// 출력 결과
P == 13122761769973223728438748421120966940822111822658737846751726458201009787842568183226633956353767366852373536207830897524429703477826413101329242841991559

Q == 12143591235989542801897500592593786940177231874673557922727626132792109878234051570051285301506807193717599879021393783668476782936432195855587786810886413


expect == 159357454821825460303855513529351666165351910023005057152558643457380993169002523181064440400043956860957806683852053087023978010188144107163145164586420445263064724930686003901511627395052659481408547123871407008485127664685784237943462320106826498735373812869875643428632125173297462470986055646835053787867

real == 159357454821825460303855513529351666165351910023005057152558643457380993169002523181064440400043956860957806683852053087023978010188144107163145164586420445263064724930686003901511627395052659481408547123871407008485127664685784237943462320106826498735373812869875643428632125173297462470986055646835053787867


True

역시... 이렇게 확인이 되어야 마음이 놓인다니까요. ^^

첨부한 파일은 위의 과정을 테스트한 프로젝트입니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 11/7/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13559정성태2/19/20242934오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/20242157닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20241911Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20241954Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20242108닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20241853VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20241936닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20241885닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20242081닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/20242195Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/20242497개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/20242326개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/20242078개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/20241938Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
13545정성태1/30/20241854닷넷: 2212. ASP.NET Core - 우선순위에 따른 HTTP/HTTPS 호스트:포트 바인딩 방법
13544정성태1/30/20241864오류 유형: 894. Microsoft.Data.SqlClient - Could not load file or assembly 'System.Security.Permissions, ...'
13543정성태1/30/20241864Windows: 254. Windows - 기본 사용 중인 5357 포트 비활성화는 방법
13542정성태1/30/20241895오류 유형: 893. Visual Studio - Web Application을 실행하지 못하는 IISExpress - 두 번째 이야기
13541정성태1/29/20241941VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
13540정성태1/29/20242069Linux: 69. 리눅스 - "Docker Desktop for Windows" Container 환경에서 IPv6 Loopback Address 바인딩 오류
13539정성태1/26/20242357개발 환경 구성: 703. Visual Studio - launchSettings.json을 이용한 HTTP/HTTPS 포트 바인딩
13538정성태1/25/20242408닷넷: 2211. C# - NonGC(FOH) 영역에 .NET 개체를 생성파일 다운로드1
13537정성태1/24/20242466닷넷: 2210. C# - Native 메모리에 .NET 개체를 생성파일 다운로드1
13536정성태1/23/20242566닷넷: 2209. .NET 8 - NonGC Heap / FOH (Frozen Object Heap) [1]
13535정성태1/22/20242407닷넷: 2208. C# - GCHandle 구조체의 메모리 분석
13534정성태1/21/20242242닷넷: 2207. C# - SQL Server DB를 bacpac으로 Export/Import파일 다운로드1
1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...