그냥 평범한 이 뉴스를 보세요...

뉴스 자체는 평범합니다. 뭐 여기에 오류는 딱히 없겠죠. 다만 그 내용이 걱정스러울 뿐이죠.

'끝내리시드' 소리까지 들어가며 반다이 배를 불려준 동인녀용 건담백합 성향(?) 학원물이 뭐가 문제냐구요? 우연인지 필연인지는 모르겠지만, 이 두 단어만 보면 KISA나 국정원에도 뭔가 애니메이션 마니아가 있다는 의심을 지울 수 없습니다만...(이름 한 번 참 멋지게 지었습니다.) 하지만 이 기사는 사실 그렇게 기쁜 소식은 아닙니다. 곡해해서 들으면 이렇게 들릴 수 있기 때문입니다.

"KISA-국가정보원, 우리나라 인터넷 세상의 ActiveX 종속화 확대를 위해 노력 합의'


도대체 무슨 소리냐구요? SEED와 ARIA는 만든 곳과 그 규격은 조금씩 다르지만 웹 브라우저와 서버가 주고 받는 데이터를 암호화하는 규격입니다. SEED가 민간 규격이자 국제 규격이며, ARIA는 정부 주도의 KS 규격이라는 점만 다를 뿐입니다. 그런데 이것과 ActiveX가 무슨 상관이 있냐구요? 상관이 있으니까 이야기를 꺼내겠죠.

빌형기업이 만든 IE의 정보를 보면 '암호화 수준'이 나옵니다. 이 암호화가 무엇인고 하니... 은행 계좌번호나 비밀번호 같은 중요한 정보는 그냥 보내면 해커나 크래커가 패킷을 가로채 쉽게 이 정보를 알아낼 수 있습니다. 그런 문제를 막기 위해 이런 정보는 가로채더라도 쉽게 알 수 없도록 변형을 시키고, 특정 암호를 넣어야만 풀 수 있도록 하여 주고 받습니다. 그 암호의 길이와 복잡함에 따라서 40비트, 128비트, 256비트 규격같은 것이 있습니다. 128비트라면 16진수로는 32자, 일반 알파벳이나 숫자로는 16글자입니다. 이 정도면 단순 무식한 대입 방법(Brute Force)로는 엄청난 시간이 걸립니다.

암호화 수준이 커지면 그만큼 기본적인 보안 능력은 좋아집니다. 하지만 이러한 보안 기술은 국가 안보와도 관련이 있기에 컴퓨터와 인터넷 암호화를 시작한 미국에서 그 기술을 미국 이외의 나라에서 쓰지 못하도록 했습니다. 지금은 그런 것이 없지만, 미국에서는 128비트 암호화를 쓸 때 우리나라는 40비트같은 낡은 암호화 웹 기술만을 써야 했습니다.

하지만 약한 암호화는 해킹 위험성이 크기에 우리나라에서 인터넷 뱅킹을 만드는 시점에서 나름대로 고민을 할 수 밖에 없었습니다. 그래서 내린 결론은 '외국의 간섭이 없는 우리나라만의 128비트 암호화 규격을 만들자'였으며, 그 결과 1998년에 SEED가 태어났습니다.(ARIA는 그 이후 나온 규격입니다.)

문제는 SEED 암호화 규격은 웹 브라우저에 들어간 기본 기능이 아니라는 데 있습니다. 기본 기능이 아닌 것을 쓰게 하려면 따로 프로그램이 필요한 것은 당연한 법. SEED 지원은 별도 프로그램이나 IE의 플러그인인 ActiveX 컨트롤 형태로 들어가게 되었습니다. 안 되는 것을 되게 하려고 노력한 KISA나 업계의 노력인 SEED는 적어도 이 시점에서는 그렇게 잘못된 것은 아니었으며, SEED 자체가 태어나지 말았어야 한다는 주장은 어디까지나 결과론에 불과한 이야기입니다. iris 역시 SEED가 태어나지 말았어야 한다는 막나가는 주장은 하지 않습니다.

문제는 세상이 바뀌면 SEED 자체도 달라져야 했음에도 전혀 그렇지 못했다는 점입니다. 미국이 128비트 암호화 규격을 수출 금지 품목에서 빼면서 이제 우리나라에서도 검증된 128비트 암호화를 쓸 수 있게 되었습니다. SEED 자체가 미국의 128비트 암호화 금수 조치에 따른 반동 성격이 강했기에 이 시점에서 KISA나 정부, 업계는 SEED의 미래에 대해 진지하게 생각할 필요가 있었습니다. 정상적인 상황이었다면 SEED는 그 역할을 다하고 역사의 뒤안길로 사라지거나, 아니면 정부가 빌형기업이나 다른 웹 브라우저 개발사에 SEED 기본 내장이 이뤄질 수 있도록 노력을 다 해야 했을 것입니다. 하지만 결과는'그냥 방치'에 불과했습니다. SEED는 더 널리 퍼져 우리나라 인터넷 금융의 기본이 되었으며, SEED는 여전히 웹 브라우저의 주변인에 그쳤습니다. 나중에 OpenSSL이나 FireFox에 SEED가 들어가기는 했습니다만, 여전히 IE에서 SEED는 주변인입니다. 아직 나오지도 않은 IE8 역시 SEED나 ARIA는 들어가지 않습니다.

이 문제는 꽤 심각한데, SEED나 ARIA를 쓰려면 누군가가 관련 플러그인이나 프로그램을 만들어주기를 기다려야만 합니다. 이런 플러그인과 프로그램이 없는 운영체제 및 웹 브라우저/네트워크 어플리케이션은 SEED/ARIA를 전혀 쓸 수 없습니다. 현재로서는 SEED/ARIA 지원이 철저히 ActiveX 중심으로 이뤄져 있기에 FireFox나 다른 웹 브라우저를 쓰면서 인터넷 뱅킹/기타 보안 작업을 하는 것은 사실상 불가능합니다.

물론 '돈이 된다면' 특정 업체가 서드 파티 웹 브라우저나 Linux 등 다른 운영체제용으로 SEED/ARIA 플러그인을 만들어 줄지도 모릅니다. 하지만 국내 기업들은 '돈이 안 된다'는 이유로서 이런 작업에 소홀하며, 정부기관 역시 이 부분에 손을 놓고 있습니다. '이론적으로 다른 웹 브라우저 및 운영체제에서도 작동하니 문제가 없다'는 말만 되새김질할 뿐입니다. 이론적으로 안 될 것이야 없겠죠. 하지만 '업계 자율'이라는 핑계로 사실상 '안 되도록' 방치하고 있다는 책임에서는 자유롭지 못할 것입니다.

그 때문에 KISA와 국정원이 SEED와 ARIA 보급에 적극적으로 나서겠다는 뜻은 '사실상 Windows 및 IE 독점화에 기여하겠음'을 의미합니다. 직접 타 운영체제와 웹 브라우저용 SEED/ARIA 플러그인을 만들어 줄 생각도 없고 업체들에게 개발을 장려할 것도 아니면서 말만은 우리나라의 보안을 확실히 책임져 주는 것인 양 있는 폼을 다 잡습니다.

물론 SEED나 ARIA만 어떻게 한다고 우리나라의 인터넷 뱅킹이 편해지는 것은 아닙니다. SEED/ARIA는 보안의 기본인 암호화만 담당하지, 인터넷 뱅킹의 전부는 아닙니다. 국가정보원이 정한 인터넷뱅킹 보안 규격에는 '오픈 소스가 아닌' 키보드 해킹 방지 툴과 방화벽, 그리고 바이러스 백신이 필요합니다. 이런 것은 빌형기업 Windows에서나 필요한 것이지 바이러스 걱정이 거의 없는 Linux나 OS/2, MacOS에서 생각할 것이 아님에도 강제화한 결과 'Windows 아니면 꺼져' 상황을 만들어 버렸습니다. 더군다나 공인 인증서 역시 Windows 전용이며, 법원마저도 이것이 불공정거래가 아니라고 해버린 만큼 국가정보원이나 방송통신위원회의 생각이 바뀌지 않는 한 우리나라는 '빌형기업이 ActiveX의 목을 쥐고 흔드는 것에 벌벌 떠는' 상황이 이어질 것입니다.

이런 상황 개선의 의지를 전혀 담지 않고 있는KISA와 국정원의 SEED와 ARIA 보급 합의를 보며 별 능력도 없으면서 온 세상에 자기 하나만 잘났다고 주장하는 '찌질이' 신 아스카가 떠오르는 이유는 뭘까요? 겉보기에는 폼은 다 재고 자랑은 다 하면서 점차 수렁으로 밀어 넣는 무능한 존재... IE 의존이라는 구덩이로 우리나라 인터넷 환경을 더 밀어 넣으려고 하는 두 조직의 합의를 이렇게 보는 것이 너무 SEED같은 발상인가요?

추신: SEED와 ARIA의 이름으로 말장난을 조금 쳤습니다만, 이들은 실제로 무개념 건담, 그리고 백합 학교와 관련이 없습니다.^^

SEED: KISA가 개발한 TTA(정보통신 단체 표준) 128비트 암호 규격. 국제 표준 규격이기도 함.
ARIA: 기술표준원이 만든 KS(국가 표준) 128비트 암호 규격. 64비트 프로세서에 최적화된 암호화 규격.


출처 - http://myiris.egloos.com/
 

원래 쓰지도 않는 고전암호는 포스팅 할 생각도 없었습니다만 ... ...
올소라 아퀴나스 덕분(?)에 치환암호만 한번 포스팅 해볼까 하는 생각이 들어 일단 포스팅을 해봅니다 ... ...
물론 이 애니메이션은 픽션이고, 내용에 나오는 법의서는 테무라(Temura)라는 일종의 신비수학을 근간으로 하니
실상은 치환암호는 아니지만 ... ... 뭐 ... 신경쓰면 지는겁니다 ...

개그는 이쯤 하고 ... 본문으로 들어가면 ...
치환 암호는 크게 단순 치환 암호와 복합 치환 암호로 구분이 가능합니다.

단순 치환 암호 (Simple Substitution)
단순치환 암호는 고대 로마에서 시저가 사용했다 하여 시저 암호(Caesar ciphers)로 더 잘 알려져 있는데
매우 단순합니다 ...

A를 D로, B를 E로 ... 알파벳에 +3 하여 암호문을 생성합니다 ...

평문    : ATTACK
암호문 : DWWDFN

... ... 이게 전부입니다 ... ...

알파벳에 +3이 아닌 다른 수를 더한다던가
수식으로 표현한다던가
Key space가 26개라던가 하는 내용은 과감히 생략합니다


복합치환암호는 여러 가지가 있지만 (여러가지가 있었나 ... ???)
그 중에서 Vigenere cipher를 소개합니다.
자세한건 http://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher를 참고하시면 더 좋겠습니다...

간단히 역사를 설명하면, 최초에 1553년 Giovan Battista Bellaso에 의해 소개 되었는데
19세기에 Blaise de Vigenere가 오류를 정정하면서 Vigenere cipher로 더 널리 알려져 있다...
.. 라고 위키에 써있는걸 번역했습니다

(테이블 출처 역시 위키입니다 ...)

위의 테이블을 참고하면, 행에 평문의 열에 키의 알파벳을 조합하여 암호문을 얻습니다 (반대도 가능합니다)

평문    : ATTACKATDAWN
키       : LEMONLEMONLE
암호문 : LXFOPVEFRNHR

이 것을 수학적으로 포장하면 ... ... ... 그건 링크에 적어둔 위키 보세요 ...;; 수식 쓰기 힘들어요 ;ㅂ; ...

...

... 결론은
암호학을 빙자한 뻘 포스팅이 되어버렸네요 ...

출처 - http://reinliebe.tistory.com/
이전에 소개한 다양한 블록 암호 알고리즘들이 전부 128-bit 이나 64-bit 와 같이

일정한 크기의 블록 단위의 암호화를 진행한다고 했습니다.

 

그렇다면 여기서, 만약 암호 알고리즘에서 제공하는 블록 크기보다 더 큰 크기의 평문을 암호화 하려면... ????

 

이 때 필요한 것이 블록 암호의 운영 모드입니다.

블록암호의 운영 모드는 크게 ECB, CBC, OFB, CFB, CTR의 다섯 가지 모드로 나뉩니다.

 

- ECB (Electronic Code Book)

   ECB 모드는 매우 간단하게 생각해서 평문을 블록 크기로 잘라서 암호화 하는 방식입니다.

   구지 수식으로 표현하면 ... Ci = E(Pi, K) 이렇게 되겠군요 ...

   특징이라면 병렬 처리가 쉽다는 장점과 동시에

   보안적 측면에서 입력이 랜덤화 되지 않고 평문이 쉽게 조작 될 수 있다는 단점이 있습니다.

 

- CBC (Cipher Block Chaining)

   CBC 모드는 첫 번째 블록의 결과가 다음 블록의 암호화에 반영이 되기 때문에

   ECB 모드보다 보안적 특성이 뛰어납니다.

   다만 한 블록에서 에러가 발생되면 다음 블록에 영향을 미친다는 단점이 있습니다.

   수식으로 표현하면 ... Ci = E((Pi xor Ci-1), K) 가 되겠군요

 

- OFB (Output FeedBack)

   CBC 모드가 에러가 발생하면 에러가 발생한 다음 블록부터 계속 에러가 전파되는 현상이 있었습니다.

   반면 OFB 모드는 이런 단점을 보완하여 평문에서 1-bit 에러가 발생하면

   암호문에도 1-bit 에러만 발생하게 됩니다.

   OFB 모드를 보면 키 스트림을 생성하고 평문과 XOR를 하여 암호를 만들어 내는 방법이기에

   어떤 의미로는 스트림 암호로 볼 수 있습니다.

   

- CFB (Cipher FeedBack)

   CFB 모드는 OFB 모드와 구조적으로 비슷해 보이나, 다소 다른 양상을 보입니다.

   우선 한 암호문이 다음 블록의 키로 사용되기 때문에,

   암호문을 알고 있는 상황에서 복호화를 병렬 처리 할 수 있다는 점이 특징입니다.

   따라서 MISTY와 같이 복호화가 느린 시스템에서 사용하기에 좋겠지요

 

- CTR (Counter)

   CTR 모드는 EBC 모드 처럼 병렬 처리가 가능 할 뿐만 아니라

   EBC 모드 처럼 한 블록에서 생긴 에러가 다음 블록으로 전파 되지도 않으며

   EBC 모드보다 안전합니다.


최종적으로 정리하면 다음과 같습니다.

 

 

 EBC

CBC

 OFB

 CFB

 Security

- 평문 패턴 유지

- 블록 암호 입력이 랜덤화되지 않음

- 평문 조작이 쉬움

- 평문 패턴 없어짐

- 블록 암호 입력이 랜덤화 됨

- 평문 조작 어려움

- 평문 패턴 없어짐

- 블록 암호 입력이 랜덤화 됨

- 평문 조작이 쉬움

- 평문 패턴 없어짐

- 블록 암호 입력이 랜덤화 됨

- 평문 조작 어려움

 Efficiency

- 병렬처리 가능

- 전처리 불가능

- 복호화 병렬처리

- 전처리 불가능

- 병렬처리 불가능

- 전처리 가능

- 복호화 병렬처리

- 전처리 불가능

 Error

 Propagation

- 암호문 에러가 평문의 한 블록에만 영향을 줌 - 암호문 에러가 다음 블록에 영향을 줌 - 암호문 에러가 평문에 대응하는 비트에만 영향을 줌 - 암호문 에러가 현재 블록과 다음 블록에 영향을 줌

표랑 본문을 이전 텍스트큐브 시절에 포스팅 한 걸 그대로 옮겨 온 것인데,

표를 다시 그리려니 ... 귀찮 ... 어려워서 그냥 CTR 모드는 표에 반영 못했네요 llorz

그 때는 그림도 같이 첨부 됐었는데, 그림 자료도 다 잃어버렸네요 ㅠㅠㅠㅠㅠㅠ


출처 - http://reinliebe.tistory.com/
ARIA 암호 알고리즘의 C# 버젼입니다 ... ...

소스보기


네 ;;; 그냥 국정원에서 나눠주는 소스코드를 C#으로, Round Key만 on-the-fly 방식으로 고친겁니다 ;;

결국은 아무것도 아닌 땜빵 소스코드 포스팅이죠 ;;; ... llorz


출처 - http://reinliebe.tistory.com/




정확히는 암호학 카테고리로 보기는 어렵지만,
AES 알고리즘(http://reinliebe.tistory.com/9)의 S-Box의 생성 원리(?) 라고 볼 수 있어서 암호학 카테고리에 넣어봤습니다.

AES S-Box는
S(x) = A·x^-1+a 로 표현되고,
A Matrix와 a Vector는 상세 명세에 잘 나와있으니 그걸 참조하면 됩니다 ... ...
(물론 S-Box도 테이블로 잘 나와있지요 ...)

그러면 x^-1은 ???? ...
물론 m(x) = x^8 + x^4 + x^3 + x + 1 Polynomial도 주어졌으니 계산하면 됩니다 ... 만,
귀찮죠 ;;

그래서 준비한 x^-1 Table,

00 01 8D F6 CB 52 7B D1 E8 4F 29 C0 B0 E1 E5 C7
74 B4 AA 4B 99 2B 60 5F 58 3F FD CC FF 40 EE B2
3A 6E 5A F1 55 4D A8 C9 C1 0A 98 15 30 44 A2 C2
2C 45 92 6C F3 39 66 42 F2 35 20 6F 77 BB 59 19
1D FE 37 67 2D 31 F5 69 A7 64 AB 13 54 25 E9 09
ED 5C 05 CA 4C 24 87 BF 18 3E 22 F0 51 EC 61 17
16 5E AF D3 49 A6 36 43 F4 47 91 DF 33 93 21 3B
79 B7 97 85 10 B5 BA 3C B6 70 D0 06 A1 FA 81 82
83 7E 7F 80 96 73 BE 56 9B 9E 95 D9 F7 02 B9 A4
DE 6A 32 6D D8 8A 84 72 2A 14 9F 88 F9 DC 89 9A
FB 7C 2E C3 8F B8 65 48 26 C8 12 4A CE E7 D2 62
0C E0 1F EF 11 75 78 71 A5 8E 76 3D BD BC 86 57
0B 28 2F A3 DA D4 E4 0F A9 27 53 04 1B FC AC E6
7A 07 AE 63 C5 DB E2 EA 94 8B C4 D5 9D F8 90 6B
B1 0D D6 EB C6 0E CF AD 08 4E D7 E3 5D 50 1E B3
5B 23 38 34 68 46 03 8C DD 9C 7D A0 CD 1A 41 1C

네.. 결코 제가 계산이 귀찮아서 만든건... ... 아닙니다

출처 - http://reinliebe.tistory.com/
블록암호(Block Cipher)의 구조는 예전 포스트(http://reinliebe.tistory.com/76)에서 어급한바와 같이
크게 Feistel 구조와 SPN 구조로 나뉩니다.

Feistel 구조의 장점은 별도의 복호화기를 구현하지 않아도, 암호화기를 이용해 복호화를 할 수 있다는 장점이 있었고
반면 SPN 구조는 암호를 풀기 위해서는 별도의 복호화기를 필요로 한다고 했었습니다.

Involutional SPN 구조는 SPN 구조임에도 불구하고,
별도의 복호화기를 필요로 하지 않은 조금 특별한 구조의 블록암호입니다.

대표적인 Involutional SPN 구조의 암호 알고리즘으로는
국내표준암호알고리즘 ARIA(http://reinliebe.tistory.com/78)가 있습니다.

----------------------------------------------------------------------------------

간단하게 ARIA를 예로 Involutional SPN 구조에 대하여 설명을 하면,

일반적인 SPN 구조의 암호 알고리즘의 암호화 순서는 (한 라운드만 보면)
[평문] -> [치환계층] -> [확산계층] -> [암호문] 과 같은 구조가 됩니다.

반대로 복호화할때는
[암호문] -> [Inverse 확산계층] -> [Inverse 치환계층] -> [평문] 순으로 될것입니다.

ARIA의 각 라운드 함수를 보면 짝수 라운드와 홀수 라운드에서 치환계층이 서로 틀립니다.
게다가 짝수 라운드의 치환계층의 Inverse가 홀수라운드의 치환계층이 되는 구조로 되어있습니다.

또한 확산계층의 Matrix의 inverse가 자기 자신이 되는 구조입니다.

이런 구조적 특징을 이용하여 별도의 복호화기를 사용하지 않고도 복호화를 할 수 있는게 Involutional SPN 구조 입니다


출처 - http://reinliebe.tistory.com/
SEED 암호 알고리즘 소스코드는 KISA에서 배포하기도 하고,
일전의 포스팅에서 소개한 devpia 자료실에도 올라와 있기 때문에 딱히 올릴 생각은 없었지만 ...

요즘 통 ... 암호 관련 포스팅을 하지 않아서 ... 그냥 가지고 있는 소스나 올려보자하는 땜빵 포스팅인거죠 ;;
(사실 암호학 포스팅하면서 수식쓰기가 귀찮아서 ... 계속 진행을 미루고 있는 게으름 탓이지만요 ㅠㅠ)

이번 포스팅은 역시 차별화(?)를 두기위해 C++/CLR로 작성된 코드이며 .. 작성한지 2년정도 된 듯 싶네요 ...

 

public ref class SEED {

 

private:

 

    array<Byte>^    Plaintext;

    array<Byte>^    Ciphertext;

    array<Byte>^    SecretKey;

 

    UInt32            G_Function(UInt32 unGin);

    UInt64            F_Function(UInt64 unFin, UInt64 unRoundKey);

    array<UInt64>^    KeySchedule(array<Byte>^ ucKey);

    void            Encryption(array<Byte>^ ucPlaintext, array<Byte>^ ucKey, array<Byte>^ ucCiphertext);

 

public:

 

    SEED();

 

    static array<Byte>^        S1 = {

        0xA9, 0x85, 0xD6, 0xD3, 0x54, 0x1D, 0xAC, 0x25, 0x5D, 0x43, 0x18, 0x1E, 0x51, 0xFC, 0xCA, 0x63,

        0x28, 0x44, 0x20, 0x9D, 0xE0, 0xE2, 0xC8, 0x17, 0xA5, 0x8F, 0x03, 0x7B, 0xBB, 0x13, 0xD2, 0xEE,

        0x70, 0x8C, 0x3F, 0xA8, 0x32, 0xDD, 0xF6, 0x74, 0xEC, 0x95, 0x0B, 0x57, 0x5C, 0x5B, 0xBD, 0x01,

        0x24, 0x1C, 0x73, 0x98, 0x10, 0xCC, 0xF2, 0xD9, 0x2C, 0xE7, 0x72, 0x83, 0x9B, 0xD1, 0x86, 0xC9,

        0x60, 0x50, 0xA3, 0xEB, 0x0D, 0xB6, 0x9E, 0x4F, 0xB7, 0x5A, 0xC6, 0x78, 0xA6, 0x12, 0xAF, 0xD5,

        0x61, 0xC3, 0xB4, 0x41, 0x52, 0x7D, 0x8D, 0x08, 0x1F, 0x99, 0x00, 0x19, 0x04, 0x53, 0xF7, 0xE1,

        0xFD, 0x76, 0x2F, 0x27, 0xB0, 0x8B, 0x0E, 0xAB, 0xA2, 0x6E, 0x93, 0x4D, 0x69, 0x7C, 0x09, 0x0A,

        0xBF, 0xEF, 0xF3, 0xC5, 0x87, 0x14, 0xFE, 0x64, 0xDE, 0x2E, 0x4B, 0x1A, 0x06, 0x21, 0x6B, 0x66,

        0x02, 0xF5, 0x92, 0x8A, 0x0C, 0xB3, 0x7E, 0xD0, 0x7A, 0x47, 0x96, 0xE5, 0x26, 0x80, 0xAD, 0xDF,

        0xA1, 0x30, 0x37, 0xAE, 0x36, 0x15, 0x22, 0x38, 0xF4, 0xA7, 0x45, 0x4C, 0x81, 0xE9, 0x84, 0x97,

        0x35, 0xCB, 0xCE, 0x3C, 0x71, 0x11, 0xC7, 0x89, 0x75, 0xFB, 0xDA, 0xF8, 0x94, 0x59, 0x82, 0xC4,

        0xFF, 0x49, 0x39, 0x67, 0xC0, 0xCF, 0xD7, 0xB8, 0x0F, 0x8E, 0x42, 0x23, 0x91, 0x6C, 0xDB, 0xA4,

        0x34, 0xF1, 0x48, 0xC2, 0x6F, 0x3D, 0x2D, 0x40, 0xBE, 0x3E, 0xBC, 0xC1, 0xAA, 0xBA, 0x4E, 0x55,

        0x3B, 0xDC, 0x68, 0x7F, 0x9C, 0xD8, 0x4A, 0x56, 0x77, 0xA0, 0xED, 0x46, 0xB5, 0x2B, 0x65, 0xFA,

        0xE3, 0xB9, 0xB1, 0x9F, 0x5E, 0xF9, 0xE6, 0xB2, 0x31, 0xEA, 0x6D, 0x5F, 0xE4, 0xF0, 0xCD, 0x88,

        0x16, 0x3A, 0x58, 0xD4, 0x62, 0x29, 0x07, 0x33, 0xE8, 0x1B, 0x05, 0x79, 0x90, 0x6A, 0x2A, 0x9A

    };

 

    static array<Byte>^        S2 = {

        0x38, 0xE8, 0x2D, 0xA6, 0xCF, 0xDE, 0xB3, 0xB8, 0xAF, 0x60, 0x55, 0xC7, 0x44, 0x6F, 0x6B, 0x5B,

        0xC3, 0x62, 0x33, 0xB5, 0x29, 0xA0, 0xE2, 0xA7, 0xD3, 0x91, 0x11, 0x06, 0x1C, 0xBC, 0x36, 0x4B,

        0xEF, 0x88, 0x6C, 0xA8, 0x17, 0xC4, 0x16, 0xF4, 0xC2, 0x45, 0xE1, 0xD6, 0x3F, 0x3D, 0x8E, 0x98,

        0x28, 0x4E, 0xF6, 0x3E, 0xA5, 0xF9, 0x0D, 0xDF, 0xD8, 0x2B, 0x66, 0x7A, 0x27, 0x2F, 0xF1, 0x72,

        0x42, 0xD4, 0x41, 0xC0, 0x73, 0x67, 0xAC, 0x8B, 0xF7, 0xAD, 0x80, 0x1F, 0xCA, 0x2C, 0xAA, 0x34,

        0xD2, 0x0B, 0xEE, 0xE9, 0x5D, 0x94, 0x18, 0xF8, 0x57, 0xAE, 0x08, 0xC5, 0x13, 0xCD, 0x86, 0xB9,

        0xFF, 0x7D, 0xC1, 0x31, 0xF5, 0x8A, 0x6A, 0xB1, 0xD1, 0x20, 0xD7, 0x02, 0x22, 0x04, 0x68, 0x71,

        0x07, 0xDB, 0x9D, 0x99, 0x61, 0xBE, 0xE6, 0x59, 0xDD, 0x51, 0x90, 0xDC, 0x9A, 0xA3, 0xAB, 0xD0,

        0x81, 0x0F, 0x47, 0x1A, 0xE3, 0xEC, 0x8D, 0xBF, 0x96, 0x7B, 0x5C, 0xA2, 0xA1, 0x63, 0x23, 0x4D,

        0xC8, 0x9E, 0x9C, 0x3A, 0x0C, 0x2E, 0xBA, 0x6E, 0x9F, 0x5A, 0xF2, 0x92, 0xF3, 0x49, 0x78, 0xCC,

        0x15, 0xFB, 0x70, 0x75, 0x7F, 0x35, 0x10, 0x03, 0x64, 0x6D, 0xC6, 0x74, 0xD5, 0xB4, 0xEA, 0x09,

        0x76, 0x19, 0xFE, 0x40, 0x12, 0xE0, 0xBD, 0x05, 0xFA, 0x01, 0xF0, 0x2A, 0x5E, 0xA9, 0x56, 0x43,

        0x85, 0x14, 0x89, 0x9B, 0xB0, 0xE5, 0x48, 0x79, 0x97, 0xFC, 0x1E, 0x82, 0x21, 0x8C, 0x1B, 0x5F,

        0x77, 0x54, 0xB2, 0x1D, 0x25, 0x4F, 0x00, 0x46, 0xED, 0x58, 0x52, 0xEB, 0x7E, 0xDA, 0xC9, 0xFD,

        0x30, 0x95, 0x65, 0x3C, 0xB6, 0xE4, 0xBB, 0x7C, 0x0E, 0x50, 0x39, 0x26, 0x32, 0x84, 0x69, 0x93,

        0x37, 0xE7, 0x24, 0xA4, 0xCB, 0x53, 0x0A, 0x87, 0xD9, 0x4C, 0x83, 0x8F, 0xCE, 0x3B, 0x4A, 0xB7

    };

 

    static array<UInt32>^    KC = {

        0x9E3779B9, 0x3C6EF373, 0x78DDE6E6, 0xF1BBCDCC, 0xE3779B99, 0xC6EF3733, 0x8DDE6E67, 0x1BBCDCCF,

        0x3779B99E, 0x6EF3733C, 0xDDE6E678, 0xBBCDCCF1, 0x779B99E3, 0xEF3733C6, 0xDE6E678D, 0xBCDCCF1B

    };

 

    String^    G_Function(String^ strInput);

    String^    Encryption(void);

    void    SetPlaintext(String^ strPlaintext);

    void    SetKey(String^ strKey);

};


클래스 구성은 대략 이렇게 했고,

멤버함수는 ... 접어둡니다 ...
(오버로딩 된 함수나 입출력 관련된 함수는 길기만 하고 딱히 관계없으므로 생략합니다)

출처 - http://reinliebe.tistory.com/
RSA가 소인수분해의 어려움에 기반한 암호 알고리즘이라는 사실은 이미 지난 포스트에서 설명을 했습니다.
(관련 포스트 : http://reinliebe.tistory.com/79)

게다가 해독 사례도 이미 언급을 하였습니다 (관련 포스트 : http://reinliebe.tistory.com/83)

일단 앞서 언급한 내용과 더불어

오늘은 RSA 암호의 안전성에 대하여 알아 보겠습니다.

우선 RSA 암호를 공격한다는 의미는 공개키를 이용하여 암호문으로 부터 원 메시지를 복원 한다는 의미와 같은데, 아직까지는 소인수분해를 이용하여  φ(n) 과 d 를 계산하는 방법 말고 특별히 이렇다 할 효율적인 알고리즘이 알려져 있지 않다지요 ...

물론 소인수분해 외의 방법이 존재 할 지도 모르고요 ...

아무튼 이어서... RSA 암호의 공격 방법에 대하여 알아보아요 ...

▶ Protocol 공격

  - 작은 e를 사용하는 경우

  - 작은 d를 사용하는 경우

  - Multiplicative 특성을 이용한 공격

  - 여러 암호문을 보낼 때 공통의 modulus를 사용하는 경우

  - 순환 공격

  - 부분 키 노출 공격

  - Timing 공격

 

▶ 소인수분해 공격

  - Trial Division

  - Pollard rho 공격

  - Pollard p-1 공격

  - 타원곡선을 이용한 공격

  - Dixon's random square 공격

  - Quadratic sieve 공격

  - Number field sieve 공격

 

물론 이 밖에도 다양한 알고리즘과 공격 방법이 존재 할 수 있습니다.
(일단 참고한 자료들이 조금 오래된 자료기 때문에 지금은 더 효율적인 알고리즘들이 나왔을 것으로 추정됩니다만)

 

아무튼 이런 공격들로부터 안전한 RSA를 구현하기 위해
매우 큰 소수(1024bit 이나 2048bit 정도)를 사용하도록 권장하며,
소수를 선택함에 있어 아래와 같은 규칙을 갖게 됩니다.

▶ 소수 선택의 조건

  - 두 소수 p, q의 크기가 거의 같아야 함

  - p-q가 너무 작으면 안됨

  - p-1이 큰 수를 인수로 가져야 함

  - p+1이 큰 수를 인수를 가져야 함


출처 - http://reinliebe.tistory.com/

+ Recent posts