MISTERY

1) 웹 어플리케이션 모의해킹

 

이름

설명

URL

wapiti

웹 취약점 스캐너

http://wapiti.sourceforge.net/

w3af

웹 취약점 스캐너

http://w3af.org/category/python

V3n0M-Scanner

웹 취약점 스캐너

https://github.com/v3n0m-Scanner/V3n0M-Scanner

xsser

XSS 취약점 스캐너

http://xsser.sourceforge.net/

sqlmap

SQL 인젝션 점검 도구

http://sqlmap.org/

spiderfoot

웹서버 풋프린팅 분석

http://sourceforge.net/projects/spiderfoot/

Parsero

웹사이트 디렉토리 탐색

https://github.com/behindthefirewalls/Parsero

dnsrecon

DNS 정보 목록화 도구

https://github.com/darkoperator/dnsrecon

 

 

2) 네트워크 분석

이름

설명

URL

Scapy

패킷 생성 및 조작 도구

http://www.secdev.org/projects/scapy/

dpkt

패킷 생성 및 조작 도구

https://code.google.com/p/dpkt/

pyhids

파이썬 기반의 HIDS

https://bitbucket.org/cedricbonhomme/pyhids/

pypcap, Pcapy and pylibpcap

패킷 덤프

https://code.google.com/p/pypcap/

http://corelabs.coresecurity.com/index.php?module=Wiki&action=view&type=tool&name=Pcapy

http://pylibpcap.sourceforge.net/

droopy

간단한 파일 공유

http://stackp.online.fr/?p=28

netgrafio

네트워크 구성도 시각화

https://github.com/nullsecuritynet/netgrafio

 

 

3) 포렌식 분석도구

이름

설명

URL

volatility

메모리 포렌식 도구

https://code.google.com/p/volatility/

libforensics

디지털 포렌식 도구

https://code.google.com/p/libforensics/

python-registry

레지스트리 포렌식

http://www.williballenthin.com/registry/

 

 

4) 악성코드 분석도구

 

이름

설명

URL

KicomAV

백신엔진

http://www.kicomav.com/

PyEMU

백신엔진

https://code.google.com/p/pyemu/

Yara

백신엔진

https://code.google.com/p/yara-project/

pyClamAV

백신엔진

http://xael.org/norman/python/pyclamav/index.html

Cuckoo Sandbox

가상화기반 악성코드 분석

http://www.cuckoosandbox.org/

pefile

PE 분석 도구

https://code.google.com/p/pefile/

peframe

PE 분석 도구

https://github.com/guelfoweb/peframe

jsunpack-n

자바스크립트 분석 도구

https://code.google.com/p/jsunpack-n/

thug

웹기반 악성코드 분석

https://buffer.github.io/thug/

apkinspector

안드로이드 악성코드 분석

https://github.com/honeynet/apkinspector/

 

 

5) 문서형 악성코드 분석

이름

설명

URL

HwpScan2

한글 취약점 스캐너

http://www.nurilab.com/?p=58

PDFDot

PDF 분석 및 시각화 도구

http://www.nurilab.com/?p=170

pdf-parser

PDF 분석 도구

http://blog.didierstevens.com/programs/pdf-tools/

pyPdf

PDF 분석 도구

http://pybrary.net/pyPdf/

VulScan

문서 분석 도구

https://code.google.com/p/vulscan/

 

 

6) 기타

이름

설명

URL

Sulley

fuzzing framework

https://github.com/OpenRCE/sulley

Powerfuzzer

fuzzing framework

http://www.powerfuzzer.com/

Pompem

취약점 정보 검색

https://github.com/rfunix/Pompem

 












출처 : http://kyaru.blog.me/130167232493

>> 보안 관련 자료가 제법 괜찮습니다.










 

 

신고

Comment +0

People seem to want to treat computer security like it's rocket science or black magic.

사람들은 컴퓨터 보안을 마치 로켓 공학이나 흑마술과 같이 다룬다.

 

In fact, computer security is nothing but attention to detail and good design.

사실, 컴퓨터 보안은 세부적이고 더 나은 설계에 관련된 것이지 그 이상도 이하도

아니다.

 

It's certainly possible to turn a computer security problem into a rocket-science or brain surgery class problem, but if you've done that it's almost a certain indication that you've already started down the wrong path.

당신이 아직까지도 컴퓨터 보안을 로켓 과학이나 뇌 수술 수준의 문제로 보고 있다면,

이미 잘못된 길로 가고 있음을 나타내는 것이다.

 

 

- Marcus Ranum

 

 

 

국내 은행에서 인터넷 거래를 위해 기본적으로 발급해주는 보안카드는 카드처럼 생긴 암호표다.

1번 부터 30번 까지 4자리의 숫자가 연속적으로 적혀 있는 카드인데, 초창기에는 이 보안 카드의

특정 번호의 4자리 숫자만을 물어 보고 맞으면 인증을 통과시키는 단순한 과정에서 2006년 경에

제안된 좀 더 안전한 인증 방법이 2011년 현재 까지도 사용되고 있다.

 

인터넷 거래를 해봤거나 전화 거래를 해봤다면, 보안카드의 x번 앞 두자리와 y번 뒷 두자리를 묻는

인증 과정을 잘 알고 있을 것이다. 맞다. 이런 과정은 2006년도 이전의 인증 과정보다는 확실히

보안카드의 일부가 유출된 상태여도 약간은 안전해질 수 있다.

 

 

 

 

 

[공인 전자서명 인증체계]

 

 

보안카드 마다 별도로 기록되어 있는 일련번호가 존재하는데 이 번호를 이용하여 공인인증서를

발급 받을 수 있다.

공인인증서라는 개념은 대한민국에만 있다. 해외에는 없다.

공인인증서 때문에 해킹이 된다는 말들은 사실 터무니 없는 얘기다.

이 것 때문에 보안이 강화될 수 있었다. 물론 ActiveX를 사용하여 인증하는 방식 때문에

사용자들에게 ActiveX는 무조건 설치해야 된다는 편견을 가져다 주긴 하였지만..

 

해외에는 공인인증서라는 것이 없어도 인터넷 거래 등을 할 수 있다.

이런 점이 보안을 더 악화시키거나 하지는 않겠지만, 한국의 인터넷 거래에서 처럼 여러 가지 보안

프로그램(키보드 해킹 방지, 백신, 방화벽 등)들을 ActiveX로 설치해주어야 하는 정책 보다는

안전하지 않을 수도 있다.

 

해외의 금융 거래는 사용자에게 전적으로 사용자의 PC 보안을 자율적으로 맡기고 있다.

따라서, 사용자들은 금융 거래시 최소한의 보안 인식을 가지고 거래를 하게 될 수 밖에 없다.

사용자의 PC가 사용자의 관리 덕분에 비교적 안전한 편이라면, 금융 거래시 별다른 프로그램 설치나

기다림 없이도 해외에서는 신속하고 간편하게 금융 거래가 가능해진다.

 

국내 정책상 여러 가지 보안 소프트웨어를 설치하고, 이용하게 되는데 논란이 많다.

특히 보안 소프트웨어의 유지보수가 힘들다는 점이다.

더 나은 암호화 알고리즘의 도입이나 일부 보완 등의 기능 수정은 많은 시간과 비용이 발생한다.

비교적 최근에는 SSL(Secure Socket Layer)에 대한 미 정부의 수출 제한이 해제되면서 최신의

인터넷 브라우저들(파이어폭스, 오페라, 익스플로러 등)이 더 높은 수준의 암호화를 지원하였다.

하지만, 국내의 일부 거래 서비스들은 이러한 움직임에 즉각적으로 대응하였지만, 시간이 지체된다.

이용자들은 당시의 브라우저가 지원하는 수준보다 낮은 수준의 암호화를 사용할 수 밖에 없었고,

거래를 전적으로 보안 소프트웨어에 의존하도록 하는 부분에서 문제가 발생하였다.

2011년 현재에는 이런 부분이 해결되었지만, 유지보수가 힘들다는 점은 변함이 없다.

 

 

 

[공인인증서 사용현황]

 

 

 

공인인증서의 용도는 다양한데 보통 전자서명에 사용되고,

전자서명은 전자 인감증명서로 해석될 수 있으며

인터넷 상에서 금융 거래를 할 때, 거래 내역의 위조나 변조를 방지하는 등의 용도이다.

 

공인인증서에는 여러 가지 정보가 포함되어 있는데,

공인인증서 마다 다른 고유한 일련번호와 유효기간, 공개키, 발행기관의 서명, 인증서 정책,

소유자 식별, 발행기관 식별, 사용목적 등이다.

공인인증서는 RSA 공개키 기반이고, 현재는 키의 길이가 1024bit와 2048bit가 공존하고 있다.

키 길이가 길면 그 만큼 안전하다고 할 수 있지만, 아직은 전환 단계에 있기 때문에 혼란이 있다.

RSA 공개키 기반의 메커니즘의 좀 더 쉽게 접근 가능한 제 2, 제 3의 통로가 발견되기 전까지는

키 길이를 늘림으로써 간단하게 보안성을 향상시킬 수 있다.

 

 

[공인 인증기관]

 

 

2006년도에 도입이 된 OTP(One Time Password)는 보안 1등급 매체로 약간의 수수료를 내면

은행에서 발급 받을 수 있다. 작은 배터리가 들어있는 기계다. (손목 시계 같은)

이 배터리가 모두 소모되면 동작을 못하게 된다. 다행히 거래가 적은 편이라면 4~5년은 거뜬하다.

 

 

 


[OTP 기계의 종류는 다양하다]

 

일반적으로 사용되는 '공인인증서' 와 '보안카드' 의 결합은 "3등급 보안" 으로 규정되어 있다.

하지만, 최근 악성코드나 해킹에 의한 공인인증서의 유출이 발생하면서,

HSM(Hardware Security Module) 등의 보다 강화된 공인인증서 보관 방법이 제시되었다.

HSM은 하드웨어적인 보안 칩이 들어있는 USB 메모리에 공인인증서를 별도로 보관하여

공인인증서의 복제나 유출을 방지하는 방법이다.

 

 

 


[홍채인식, 지문인식, 손바닥 정맥패턴 인식 등 다양한 생체인식 기술이 있다]

해외에서는 보다 활발한 인증 방식이 도입되고 있는 중인데,

특히 미국은 2006년도에 위치기반 인증과 생체기반 인증을 이미 도입한 상태다.

 

 

 

 


[대한민국 정부 OTP 인증체계]

 

 

 

OTP는 일회용 비밀번호다. 한국의 은행들은 일반적으로 시간(Time)에 의해 OTP가 동기화되어 있는데

쉬운 예를 들면, 내가 A라는 은행에서 OTP를 발급 받아서 로그인 인증 과정에 사용하려고 한다.

OTP 기계에 적힌 6자리 숫자를 로그인 창에 입력한다.

A라는 은행에도 나와 동일한 시간에 동일한 OTP로 6자리 숫자를 생성한 다음,

로그인시 내가 입력한 OTP 값과 일치하는지 비교한다.

이렇게 비교한 OTP 값이 같으면 인증에 통과시킨다.

물론, 소프트웨어 적으로 모든 것이 이루어 지기 때문에 사용자 입장에서는 OTP 기계만 있으면 된다.

나머지는 은행 서버가 알아서 처리한다.

 

OTP 인증은 이중요소인증(Two-factor authentication)의 하나다.

보통, 인터넷 거래에서 OTP 사용자들은 카드 비밀번호도 입력하고, OTP의 값도 입력을 한다.

다시 말해 두 번 비밀번호를 입력하는 셈이다.

마찬가지로, 보안카드 또한 이중요소인증의 일부인데 정적인 비밀번호가 적혀 있기 때문에

유출되면 곤란해진다.

 

첫 번째 비밀번호는 내가 알고 있는 비밀번호고, (카드 비밀번호)

두 번째 비밀번호는 시간에 따라 달라지는 비밀번호다. (OTP 값)

비밀번호가 유출되어도 OTP 값은 알수 없다는 점이

단일요소인증(Single-Factor Authentication)이나, 보안카드에 비해 좀 더 높은 수준의 보안을

유지할 수 있는 비결인 것이다.

 

OTP는 시간에 따라 동적(Dynamic)인 비밀번호를 생성한다.

은행별로 이 시간값에 오차(Tolerance)가 존재하기는 한다.

OTP의 비밀번호가 갱신되는 시간은 약 15초~30초 정도이고, 이는 은행별로 약간씩 편차가 있다.

OTP는 사용자 입장에서보면 단지 보안성의 향상이라는 효과를 얻을 수 있지만,

은행 입장에서는 OTP 생성과 관련된 정보를 관리해야 하는 부담을 떠앉는다.

 

OTP는 비동기화(Asynchronous) 방식과 동기화(Synchronous) 방식으로 구분이 되는데,

현재는 은행에서 시간 동기화 방식의 OTP가 사용되고 있기 때문에 동기화 방식의 OTP를

사용하고 있는 것이 된다.

 

 

 

[OTP 비동기화(질의-응답) 방식]

 

 

비동기화 방식을 질의-응답 방식이라고도 하는데, 은행 서버에서 사용자에게 질문을 하면,

이 질문을 사용자가 OTP 기계에 입력하고 출력되는 결과를 다시 은행 서버에 전송해야 되는

불편함이 있어 잘 사용되지 않는다.

은행 입장에서도 많은 부하가 발생하여 동기화 방식에 비해 이득이 없다.

따라서, 아래의 동기화 방식을 주로 이용하게 된다.

 

 

 


[시간이나 이벤트 등을 통해 OTP를 동기화하는 방식]

 

 

동기화 방식의 경우 현재 사용되고 있는 시간 동기화 방식이 보편적인데, 단점이 있다면

OTP 값이 출력되고 난 이후 15~30초 사이의 시간안에 은행 서버로 입력값을 전송하지 못할 경우

OTP 값이 갱신되어 변경되면 다시 입력을 해주어야 하는 것이 문제다.

컴퓨터와 키보드에 익숙하지 않은 사람들은 불편함을 겪는다.

 

 

 

 

[횟수(Counter) 기반 OTP 예시]

 

 

이외에도 동기화 방식중 이벤트(Event) 동기화 방식이 존재하는데,

이 방식은 여러 가지의 형태가 존재할 수 있다. 그 중 카운터(Counter)를 사용한 이벤트 동기화

방식은 인증 횟수를 세는 카운터를 하나 둔다고 생각하면 된다.

예를 들어, 내가 생성한 비밀번호의 횟수와 은행 서버가 생성한 비밀번호의 횟수가 동일하면

비밀번호도 동일할 것이고, 인증에 통과할 수 있다.

물론 사용자가 실수나 호기심에 비밀번호를 한번 더 생성해버리면 인증 횟수가 다르기 때문에

서로 다른 비밀번호로 인증을 하게 된다. 당연히 인증에 실패한다.

 

OTP 기계중에는 사용자가 단추를 눌러야 다음 비밀번호를 생성하여 보여주는 기계가 있는 반면에

자동으로 15초 정도 지나면 다음 비밀번호를 생성하여 보여주는 기계가 있다.

이벤트 동기화 방식 중 카운터 이벤트 동기화 방식에서는 대개 사용자가 단추를 눌러야만 다음

비밀번호를 생성할 수 있도록 하고 있다.

자동으로 계속 다음 비밀번호를 생성하면 카운터 값이 일치하지 않아 인증에 실패하기 때문이다.

 

카운터 이벤트 동기화 방식을 다시 쉬운 예로 들면,

첫 번째 로그인시, 비밀번호 값과

두 번째 로그인시, 비밀번호 값은 당연히 서로 틀리다.

내가 첫 번째 로그인을 위해 OTP 기계에서 비밀번호 생성 단추를 한 번 눌렀고,

출력된 OTP 값을 전송하여 로그인에 성공하였다.

하지만, 호기심에 OTP 기계에서 비밀번호 생성 단추를 여러번 눌렀고,

출력된 OTP 값을 2번째 로그인에 전송하였더니 인증에 실패하였다.

로그인 서버에서는 2번째 로그인으로 파악하고 2번째 OTP 값을 요구했던 것이다.

 

다행히 이런 사용자의 실수를 어느 정도 오차로 보고 허용하는 경우도 있다.

 

최근에는 OTP를 구매할 때 발생하는 비용 때문에 기존에 사용자가 가지고 있을 법한

가령 휴대폰이나 스마트폰, IC카드 등을 활용하여 OTP를 생성하는 방법도 존재한다.

또, IC카드와 IC카드 리더기를 활용한 OTP 생성 및 인증 방법도 존재하는데,

2008년도 당시 정부에서 적극적으로 권장하려던 부분이다.

아쉽게도 이 방법은 아직 잘 사용되고 있지 않으며, 해킹등의 문제가 발생할 우려가 있어 보인다.

또한 IC 카드 리더기를 구입해야 되기 때문에 비용적인 측면에서도 문제가 발생된다.

조금더 나아가 OTP와 IC 카드를 결합한 형태의 카드도 출시되고 있으며, 소리로 인식하는

OTP 도 존재한다.

 

 

 


[IC카드와 OTP가 결합된 형태]


 

요즘은 OTP 기계의 단가를 최대한 낮추기 위해 은행끼리 동일한 제품을 구입하기도 한다.

일종의 공동구매다. 이렇게 되면, 사용자가 부담하는 수수료도 적게 들고,

은행끼리 동일한 OTP로 인증하는데 사용될 수도 있다.

OTP 마다 개별적인 고유 식별 번호가 적혀 있는데 이 값을 은행별로 공유하면 은행별로 별도의

OTP가 필요하지 않고, 1개의 OTP만으로도 거래가 충분해진다.

이러한 방법은 보안성이 떨어지는 경우를 생각해 볼 수 있기 때문에 대다수의 사용자들은

은행별로 OTP를 구매한다.

 

당시 해외에서는 OTP와 동시에 흥미로운 주제였던

양방향 인증(Mutual Authentication 또는 Two-way Authentication)이 있었는데,

최근까지 유명한 검색 업체에서 사용되었던 인증 방식으로

보통 사용자가 온갖 비밀번호와 공인인증서 등을 은행 서버로 전송하는데

은행 서버 자체가 정당한 은행 서버인지를 증명할 수 있는 방법은 없었다.

그래서 나온 개념이 사용자 마다 별도로 등록하는 비밀 사진이 있는데

이 비밀 사진을 은행 서버가 해당 사용자가 로그인 할 때 보여주는 방법이다.

이렇게 되면, 사용자는 은행 서버가 정당한지 아닌지를 쉽게 파악할 수 있게 된다.

 

유감스럽게도 이러한 양방향 인증 방식은 SSL 등 여러 가지 더 나은 대안으로 대체되었고,

비밀 사진 방식의 양방향 인증은 현재는 거의 찾아볼 수 없는 상태다.

 

 

 

 

 

 

 

 

출처 : http://blog.naver.com/tpinlab/10121774937

 

 

 

 

 

 

 

 

신고

Comment +0

"We sent the S-boxes off to Washington. They came back and were all different."

"우리는 S-Box 들을 워싱턴으로 보냈다. 모든 것이 달라져서 돌아왔다."

 

 

- Alan Konheim(DES 설계자)

 

 

DES 개발에 참여한 몇몇 설계자는 미 국가안보국인 NSA가 DES를 좀 더 취약하도록 수정하지

않았다고 얘기한다.

 

DES는 Data Encryption Standard 의 줄임말이다.

DES는 IBM사의 암호 설계 연구원이었던 Horst Feistel의 루시퍼(Lucifer) 암호에 기반하고 있다.

또한 DES는 비밀키(Secret Key) 방식의 암호화 알고리즘이다.

암호화를 할 때 입력한 키 값을 모르면 복호화가 안된다는 의미다.

1972년에 NBS 미 국가표준국에서는 암호체계 제안요구서를 발표하여 유일하게 이 요구서의 요구를

충족하는 IBM의 루시퍼 암호를 당시 암호 분야에 전문가가 없었던 NBS는 NSA로 이관했다.

 

 

[NSA 로고]

 

이 때, 미 국가안보국 NSA는 초 극비기관이었고, 미군과 미 정부에 사용되는 암호체계를 설계하고

구현하는 업무를 맡은 중요한 정보기관이었다.

DES의 유력한 후보였던 IBM사의 루시퍼 암호를 NSA 입장에서는 극비리에 검토하게 된다.

뒤늦게 NSA가 DES를 검토했다는 사실이 일반에 알려지게 되면서, NSA가 DES에 몰래

해독가능한 뒷 경로(Backdoor)를 숨겨놨을 것이라고 사람들은 의심하게 되었다.

 

 

[NSA 본부 전경]

 

 

어찌되었건, 이러한 의심은 오랜 기간 동안 DES가 시장에서 사용되어 오면서 백도어가 없는 것처럼

여겨진다. 많은 사람들의 의심은 단지 의심으로 끝났다.

이런 의심 때문에 DES는 표준암호로써 별로 좋은 인상을 남겨주지는 못했다.

 

초창기 IBM사에서 만든 루시퍼 암호는 128bit 키(Key) 값을 가지도록 설계되었다.

하지만, NSA가 검토할 당시 이 키 값을 64bit로 변경하였고, 내부적으로 56bit만을 사용하게 된다.

또, S-Box 부분도 변경되었는데, 이 S-Box의 독특한 부분은 DES가 안전할 수 있는 중요한 부분이다.

따라서 사람들의 의심이 끊이지 않았던 것이기도 하다.

 

[DES의 근간이 되는 페이스텔 암호체계의 원리]

 

DES는 페이스텔이란 사람이 설계한 암호체계인 페이스텔 암호체계를 기반으로 하고 있다.

이 암호체계는 입력 값 P를 두 개로 나눠서 연산하는데, L과 R로 각각 나누게 된다.

DES는 64bit 블록 암호이기 때문에 입력 값 64bit 마다 연산이 진행되고, L과 R이 각각 32bit다.

 

DES는 많은 부분이 선형식으로 구성되어 있다.

선형식은 말 그대로 수학 식으로 풀 수 있는 형태다.

암호학에서는 선형식을 비 선형식으로 바꾸는데 주안점을 둔다.

선형식은 수학자들이 풀기 쉽지만, 비 선형식은 특정한 규칙이 없는 것처럼 보이기 때문에

식을 도출하기가 매우 난해하다.

 

DES는 실제 56bit의 키 길이를 가지고 있기 때문에 전수 키 조사(Exhaustive Key Search)를

진행할 때의 걸리는 작업량이 2^55(2에 55승) 가 된다.

이는 현재의 컴퓨터 연산처리 속도에 비하면 매우 적은 것으로 취약하다고 할 수 있다.

 

암호학에서 생일문제(Birthday Problem)는 이러한 전수 키 조사의 작업량을 확률적으로 1/2 가량

줄어들 수 있다.

생일문제란, 한 방에 얼마 만큼의 사람이 있어야 생일이 같은 두 사람을 찾을 수 있느냐는 문제인데,

확률적으로 생일이 같은 사람이 있을 확률은 약 23명만 있어도 찾을 수 있다는 것이다.

사람들의 생일은 무작위기 때문에 최악의 경우는 365명이 있어도 서로 같지 않을 수도 있지만,

평균적인 경우나 최상의 경우도 생각을 해볼 수 있기 때문에 확률적으로 역설적이지만

많은 수의 사람이 필요하지는 않다는 것을 알 수 있게 된다.

아래 생일문제 계산기를 이용하면 그래프로 좀 더 쉽게 확인할 수 있다.

Enter number of Birthdays to calculate: 에 15라고 입력된 값은 한 방에 15명이 있다는 의미다.

이 값은 변경할 수 있으니 직접 테스트 해보기 바란다. 우측의 Calculate 단추를 누르면 시작한다.

 

 

 

[생일문제 계산기]

 

 

생일문제 계산기의 좌측은 무작위로 생성된 생일들이고, 이 생일들 중에서 서로 동일한 생일이 있으면

우측의 그래프에 어느 정도 확률인지 출력된다.

한 방에 있을 수 있는 사람의 수의 최대 값은 60이다.

 

전수 키 조사에서 또한 마찬가지로 모든 수를 조사하기 전에 절반 쯤 조사를 하다보면 발견하게 될

가능성이 높다는 의미다.

DES의 이론적인 공격 방법은 다양하지만, 하드웨어의 급속한 발전 탓에 전수 키 조사에서 조차

취약성을 나타내고 있어 급기야 이 문제의 대안으로 삼중(Triple) DES를 고안하기에 이른다.

 

삼중 DES가 나오기 전에 두번 DES를 연산하려는 시도도 있었으나, 공격 방법이 발견되면서

삼중 DES로 대체되었다.

이중 또는 삼중 DES의 핵심은 키 길이를 늘리는데 있다.

키 길이가 늘어나면 전수 키 조사의 작업량이 늘어나기 때문에 새로 나올 암호 표준이 준비되는 동안

어느 정도 시간을 벌 수 있었다.

 

삼중 DES는 다행히 공격 방법의 비실용적인 측면 때문에 이중 DES 보다는 안전하다고 할 수 있었다.

삼중 DES의 암호화 방법은 약간 독특한데 암호화-복호화-암호화의 형태가 주로 사용되었다.

이런 형태는 기존 DES와의 하위 호환성을 위해 사용되었으며, 키 길이는 112bit였다.

 

현재에는 AES(Advanced Encryption Standard) 가 블록암호의 표준이자 보편화가 되어 있다.

AES는 좀 더 다른 형태의 연산과 강화된 키 길이 등으로 기존의 구 암호표준인 DES와 Triple-DES를

대체한다.

 

 

 

 

 

출처 : http://blog.naver.com/tpinlab/10121774937

 

 

 

 

 

신고

Comment +0