posted by 블르샤이닝 2015. 9. 16. 10:07
728x90

원본 : http://d2.naver.com/helloworld/318732


설명이 깔끔하고 이해하기 쉽게 설명되었다. 암호학을 책이나 논문 이런걸로 보면 수학적 계산법으로 인해 이해하기 어려운부분이 있는데 가볍게 읽으면서 이해하기 쉽게 쓴글같다. 특히 salt 부분은 현재 많이 사용되고 있는 부분이다(ida  정품 한번 보려고했다가 salt에 막혔던 슬픈기억......여튼 salt는 보안기사에서도 많이 나오니 어느정도 방식에 대해 이해해두는게 좋다)

안전한 패스워드 저장

"보안 시스템은 가장 약한 연결 고리만큼만 강하다."

보안 시스템은 여러 부분으로 이뤄집니다. 공격자(attacker)는 이 중에서 가장 취약한 부분을 공격할 것이라고 가정해야 합니다. 보안 시스템이라는 사슬에서 가장 약한 고리가 끊어지면 다른 고리가 얼마나 강한지는 문제가 되지 않습니다. 즉, 보안 시스템의 안정성은 '강한 부분이 얼마나 강한가'보다는 '약한 부분이 얼마나 약한가'에 따라서 좌우됩니다.

지난해 6월 세계 최대 비즈니스 전문 소셜 네트워크 서비스(SNS) LinkedIn은 사용자 데이터 해킹 사고로 650만 명의 아이디와 패스워드 정보가 유출된 후 집단 소송을 당했습니다. 취약한 암호화 알고리즘인 SHA-1을 사용했다는 것이 그 이유였습니다. 이제 보안 시스템의 한 부분인 암호화 알고리즘으로 어떤 알고리즘을 선택했는지도 보안의 책임을 다했는지 판단할 때 중요한 요소입니다.

이 글에서는 보안 시스템의 여러 부분 중, 패스워드를 저장할 때 사용되는 해시 함수(hash function)의 개념을 설명하고 대부분의 웹 사이트에서 사용하고 있는 암호화 알고리즘의 안정성을 검토하겠습니다. 그리고 어떤 암호화 알고리즘을 사용해야 안전한지 설명하겠습니다.

단방향 해시 함수

보통 프로그래머는 아래의 두 가지 중 한 가지로 사용자의 패스워드를 저장한다.

  • 단순 텍스트(plain text)
  • 단방향 해시 함수(one-way hash function)의 다이제스트(digest)

단순 텍스트로 패스워드를 저장하는 것은 범죄를 저지르는 것이나 다름없다. 아직도 이런 방법을 사용하고 있다면 지금 당장 변경해야 한다.

단방향 해시 함수는 수학적인 연산을 통해 원본 메시지를 변환하여 암호화된 메시지인 다이제스트를 생성한다. 원본 메시지를 알면 암호화된 메시지를 구하기는 쉽지만 암호화된 메시지로는 원본 메시지를 구할 수 없어야 하며 이를 '단방향성'이라고 한다.

예를 들어 사용자의 패스워드가 "hunter2"라면 이 문자열을 흔히 사용하는 해시 알고리즘인 SHA-256으로 인코딩하여 아래와 같은 값을 얻을 수 있다.

f52fbd32b2b3b86ff88ef6c490628285f482af15ddcb29541f94bcf526a3f6c7  

위의 값을 저장하면 사용자의 패스워드를 직접 저장하는 위험을 피할 수 있다. 그리고 사용자가 로그인할 때 패스워드를 입력하면, 이를 해시한 값을 저장된 값과 비교하여 일치 여부를 확인할 수 있다.

대부분의 해시 함수는 입력 값의 일부가 변경되었을 때 다이제스트가 완전히 달라지도록 설계되어 있다. "hunter3"라는 값의 SHA-256 다이제스트는 아래와 같으며 위의 "hunter2"와는 완전히 달라진 것을 확인할 수 있다.

fb8c2e2b85ca81eb4350199faddd983cb26af3064614e737ea9f479621cfa57a  

이 특징을 avalanche 효과라고 하며, 사용자의 원본 패스워드를 추론하기 어렵게 만드는 중요한 요소이다. 그러나 이것만으로는 패스워드 보안이 충분히 안전하다고 말할 수 없다.

단방향 해시 함수의 문제점

대부분의 웹 사이트에서는 SHA-256과 같은 해시 함수를 사용해 패스워드를 암호화해 저장하고 값을 비교하는 것만으로 충분한 암호화 메커니즘을 적용했다고 생각하지만, 실제로는 다음과 같은 두 가지 문제점이 있다.

인식 가능성(recognizability)

동일한 메시지가 언제나 동일한 다이제스트를 갖는다면, 공격자가 전처리(pre-computing)된 다이제스트를 가능한 한 많이 확보한 다음 이를 탈취한 다이제스트와 비교해 원본 메시지를 찾아내거나 동일한 효과의 메시지를 찾을 수 있다. 이와 같은 다이제스트 목록을 레인보우 테이블(rainbow table)이라 하고, 이와 같은 공격 방식을 레인보우 공격(rainbow attack)이라 한다. 게다가 다른 사용자의 패스워드가 같으면 다이제스트도 같으므로 한꺼번에 모두 정보가 탈취될 수 있다.

속도(speed)

해시 함수는 암호학에서 널리 사용되지만 원래 패스워드를 저장하기 위해서 설계된 것이 아니라 짧은 시간에 데이터를 검색하기 위해 설계된 것이다. 바로 여기에서 문제가 발생한다. 해시 함수의 빠른 처리 속도로 인해 공격자는 매우 빠른 속도로 임의의 문자열의 다이제스트와 해킹할 대상의 다이제스트를 비교할 수 있다(MD5를 사용한 경우 일반적인 장비를 이용하여 1초당 56억 개의 다이제스트를 대입할 수 있다).

이런 방식으로 패스워드를 추측하면 패스워드가 충분히 길거나 복잡하지 않은 경우에는 그리 긴 시간이 걸리지 않는다. 그리고 대부분 사용자의 패스워드는 길거나 복잡하지 않을 뿐 아니라, 동일한 패스워드를 사용하는 경우도 많다.

반면 사용자는 웹 사이트에서 패스워드를 인증하는 데 걸리는 시간에는 그리 민감하지 않다. 사용자가 로그인하기 위해 아이디와 패스워드를 입력하고 확인 버튼을 누르는 과정에 10초가 걸린다고 가정했을 때, 다이제스트를 생성하는 데 0.1초 대신 1초가 소요된다고 해서 크게 신경 쓰는 사람은 많지 않다. 즉, 해시 함수의 빠른 처리 속도는 사용자들보다 공격자들에게 더 큰 편의성을 제공하게 된다.

단방향 해시 함수 보완하기

솔팅(salting)

솔트(salt)는 단방향 해시 함수에서 다이제스트를 생성할 때 추가되는 바이트 단위의 임의의 문자열이다. 그리고 이 원본 메시지에 문자열을 추가하여 다이제스를 생성하는 것을 솔팅(salting)이라 한다. 예를 들어 다음과 같이 "redfl0wer"에 솔트인 "8zff4fgflgfd93fgdl4fgdgf4mlf45p1"를 추가해 다이제스트를 생성할 수 있다.

password1

그림 1 패스워드 "redfl0wer"에 솔트를 추가해 다이제스트 생성

이 방법을 사용하면, 공격자가 "redfl0wer"의 다이제스트를 알아내더라도 솔팅된 다이제스트를 대상으로 패스워드 일치 여부를 확인하기 어렵다. 또한 사용자별로 다른 솔트를 사용한다면 동일한 패스워드를 사용하는 사용자의 다이제스트가 다르게 생성되어 인식 가능성 문제가 크게 개선된다.

솔트와 패스워드의 다이제스트를 데이터베이스에 저장하고, 사용자가 로그인할 때 입력한 패스워드를 해시하여 일치 여부를 확인할 수 있다. 이 방법을 사용할 때에는 모든 패스워드가 고유의 솔트를 갖고 솔트의 길이는 32바이트 이상이어야 솔트와 다이제스트를 추측하기 어렵다.

키 스트레칭(key stretching)

입력한 패스워드의 다이제스트를 생성하고, 생성된 다이제스트를 입력 값으로 하여 다이제스트를 생성하고, 또 이를 반복하는 방법으로 다이제스트를 생성할 수도 있다. 이렇게 하면 입력한 패스워드를 동일한 횟수만큼 해시해야만 입력한 패스워드의 일치 여부를 확인할 수 있다. 이것이 기본적인 키 스트레칭 과정이다.

잘 설계된 패스워드 저장 시스템에서는 하나의 다이제스트를 생성할 때 어느 정도(일반적인 장비에서 0.2초 이상)의 시간이 소요되게 설정한다. 이는 억지 기법 공격(brute-force attack)으로 패스워드를 추측하는 데 많은 시간이 소요되도록 하기 위한 것이다.

최근에는 일반적인 장비로 1초에 50억 개 이상의 다이제스트를 비교할 수 있지만, 키 스트레칭을 적용하여 동일한 장비에서 1초에 5번 정도만 비교할 수 있게 한다. GPU(Graphics Processing Unit)를 사용하더라도 수백에서 수천 번 정도만 비교할 수 있다. 50억 번과는 비교할 수도 없을 정도로 적은 횟수다. 앞으로 컴퓨터 성능이 더 향상되면 몇 번의 반복을 추가하여 보완할 수 있다.

다음 그림은 솔트를 추가한 패스워드에 여러 단계의 해시 함수를 적용하여 다이제스트를 생성하는 과정을 나타낸 것이다.

password2

그림 2 솔팅과 키 스트레칭을 적용하여 다이제스트 생성

앞에서 설명한 바와 같이 솔팅과 키 스트레칭으로 구성된 암호화 시스템을 구현하려고 한다면 이미 검증된 암호화 시스템을 사용할 것을 권장한다. 널리 알려진 검증된 시스템을 사용하면, 암호화 시스템을 잘못 구현해서 발생하는 위험을 피할 수 있다.

이에 비해 자신만의 암호화 시스템을 구현하는 것은 매우 위험하다. 이 경우 취약점을 확인하기 어렵고, 대부분의 경우 구현된 암호화 시스템을 점검하고 확인하는 사람은 암호화 시스템을 구현한 당사자 한 명이다. 만약 구현한 암호화 시스템에 취약점이 있다면, 많은 사람들이 사용할수록 그만큼 많은 사람들이 피해를 입게 된다. 이런 취약점이 내포된 시스템은 여러 차례 발견되었고, 이와 같은 시스템을 사용한 프로그램들이 여러 해 동안 BSD나 Linux에서 사용되어 왔다.

다음 절에서는 위에서 설명한 사항들을 고려하여 선택할 수 있는 대안을 제시한다.

Adaptive Key Derivation Functions

adaptive key derivation function은 다이제스트를 생성할 때 솔팅과 키 스트레칭을 반복하며 솔트와 패스워드 외에도 입력 값을 추가하여 공격자가 쉽게 다이제스트를 유추할 수 없도록 하고 보안의 강도를 선택할 수 있다.

이 함수들은 GPU와 같은 장비를 이용한 병렬화를 어렵게 하는 기능을 제공한다. 이와 같은 기능은 프로그램이 언어에서 제공하는 라이브러리만으로는 구현하기 어렵다.

adaptive key derivation function 중 주요한 key derivation function은 다음과 같다.

PBKDF2

가장 많이 사용되는 key derivation function은 PBKDF2(Password-Based Key Derivation Function)이다. 해시 함수의 컨테이너인 PBKDF2는 솔트를 적용한 후 해시 함수의 반복 횟수를 임의로 선택할 수 있다. PBKDF2는 아주 가볍고 구현하기 쉬우며, SHA와 같이 검증된 해시 함수만을 사용한다.

PBKDF2의 기본 파라미터는 다음과 같은 5개 파라미터다.

DIGEST = PBKDF2(PRF, Password, Salt, c, DLen)  
  • PRF: 난수(예: HMAC)
  • Password: 패스워드
  • Salt: 암호학 솔트
  • c: 원하는 iteration 반복 수
  • DLen: 원하는 다이제스트 길이

PBKDF2는 NIST(National Institute of Standards and Technology, 미국표준기술연구소)에 의해서 승인된 알고리즘이고, 미국 정부 시스템에서도 사용자 패스워드의 암호화된 다이제스트를 생성할 때 사용한다.

bcrypt

bcrypt는 애초부터 패스워드 저장을 목적으로 설계되었다. Niels Provos와 David Mazières가 1999년 발표했고 현재까지 사용되는 가장 강력한 해시 메커니즘 중 하나이다. bcrypt는 보안에 집착하기로 유명한 OpenBSD에서 기본 암호 인증 메커니즘으로 사용되고 있고 미래에 PBKDF2보다 더 경쟁력이 있다고 여겨진다.

bcrypt에서 "work factor" 인자는 하나의 해시 다이제스트를 생성하는 데 얼마만큼의 처리 과정을 수행할지 결정한다. "work factor"를 조정하는 것만으로 간단하게 시스템의 보안성을 높일 수 있다.

다만 PBKDF2나 scrypt와는 달리 bcrypt는 입력 값으로 72 bytes character를 사용해야 하는 제약이 있다.

// Sample code for jBCrypt is a Java
// gensalt is work factor and the default is 10
String hashed = BCrypt.hashpw(password, BCrypt.gensalt(11));

// Check that an unencrypted password matches one that has
// previously been hashed
if (BCrypt.checkpw(candidate, hashed))  
    System.out.println("It matches");
else  
    System.out.println("It does not match");

scrypt

scrypt는 PBKDF2와 유사한 adaptive key derivation function이며 Colin Percival이 2012년 9월 17일 설계했다. scrypt는 다이제스트를 생성할 때 메모리 오버헤드를 갖도록 설계되어, 억지 기법 공격(brute-force attack)을 시도할 때 병렬화 처리가 매우 어렵다. 따라서 PBKDF2보다 안전하다고 평가되며 미래에 bcrypt에 비해 더 경쟁력이 있다고 여겨진다. scrypt는 보안에 아주 민감한 사용자들을 위한 백업 솔루션을 제공하는 Tarsnap에서도 사용하고 있다. 또한 scrypt는 여러 프로그래밍 언어의 라이브러리로 제공받을 수 있다.

scrypt의 파라미터는 다음과 같은 6개 파라미터다.

DIGEST = scrypt(Password, Salt, N, r, p, DLen)  
  • Password: 패스워드
  • Salt: 암호학 솔트
  • N: CPU 비용
  • r: 메모리 비용
  • p: 병렬화(parallelization)
  • DLen: 원하는 다이제스트 길이

마치며

MD5, SHA-1, SHA-256, SHA-512 등의 해시 함수는 메시지 인증과 무결성 체크를 위한 것이다. 이것을 패스워드 인증을 위해 사용하면 앞에서 말한 인식 가능성과 빠른 처리 속도에 기인하는 취약점이 존재한다.

이를 해결하기 위해서는 위에서 언급한 key derivation function을 사용하는 것을 권장한다.

ISO-27001의 보안 규정을 준수하고, 서드파티의 라이브러리에 의존하지 않으면서 사용자 패스워드의 다이제스트를 생성하려면 PBKDF2-HMAC-SHA-256/SHA-512을 사용하면 된다.

매우 강력한 패스워드 다이제스트를 생성하는 시스템을 쉽게 구현하고 싶다면 bcrypt를 사용하는 것이 좋다. 대부분의 프로그래밍 언어에서 라이브러리를 사용할 수 있고, 검색 엔진에서 "bcrypt <프로그래밍 언어>"로 검색하면 쉽게 예제를 구할 수 있다.

구현하려는 시스템이 매우 민감한 정보를 다루고, 보안 시스템을 구현하는 데 많은 비용을 투자할 수 있다면 scrypt를 사용하면 된다.

이와 함께 패스워드 보안을 위해 더 쉽게 취할 수 있는 조치가 있다.

패스워드 다이제스트의 강도는 결국 패스워드 자체의 길이와 유일성 같은 엔트로피에 의해서 결정된다. 따라서 사용자가 안전한 패스워드를 설정하도록 패스워드 정책을 설정하는 것이 매우 중요하다. 사용자가 모두 다른 패스워드를 사용하도록 강제하는 것이 최상이겠지만 현실적으로는 어렵기 때문에 최대한 긴 패스워드를 사용하도록 권장해야 한다.

참고자료

  1. 닐스 퍼거슨∙브루스 슈나이어∙타다요시 쿄노, 실용 암호학, 에이콘, 2011.
  2. PBKDF2: http://en.wikipedia.org/wiki/PBKDF2
  3. bcrypt: http://en.wikipedia.org/wiki/Bcrypt
  4. scrypt: http://en.wikipedia.org/wiki/scrypt
  5. password security: http://throwingfire.com/storing-passwords-securely/
  6. Java crypt: http://www.mindrot.org/projects/jBCrypt/
  7. Java scrypt: http://www.jarvana.com/jarvana/view/com/lambdaworks/scrypt/1.0/scrypt-1.0-sources.jar!/com/lambdaworks/crypto/SCrypt.java
  8. ighashgpu - SHA1, MD5 & MD4 해시 크래커: http://kldp.org/node/109911


728x90

'암호학' 카테고리의 다른 글

파일 암호화후 몸값요구하는 랜섬웨어 CryptoLocker 주의!-한국트렌트랩  (0) 2013.11.04
base 64 에 대한 설명  (0) 2012.01.24
sha -1  (0) 2009.10.11
posted by 블르샤이닝 2013. 11. 4. 14:13
728x90
출처 : 한국 트랜트랩

10월파일 암호화후 몸값요구하는 랜섬웨어 CryptoLocker 주의!
28일2013년 10월 28일   |  by Kervin Alintanahin (Threats Analyst)

최신 랜섬웨어(몸값요구형 악성코드)인 CryptoLocker는 특정 파일을 암호화한 후 300달러(또는 300유로)의 복호화 툴을 사용자에게 보여주면서 요금 지불을 강요하는 것으로 알려져 있습니다. 이번 블로그에서는 이 악성코드가 어떻게 PC에 침입하는지, 그리고 또다른 악성코드-온라인뱅킹 사기툴 ZBOT과 어떻게 연관되어 있는지 알아보도록 합니다.

그림1. 복호화 툴 구입을 유도하는 화면

트렌드마이크로는 지난 블로그에서 CryptoLocker가 PC 접근을 차단할 뿐만 아니라 파일을 잠그거나 암호화해 300달러의 복호화 툴을 구입하도록 유도하는 사례를 보고했습니다. 그리고 이번달에 들어 어떤 스팸메일 활동이 보고되었으며 이는 CryptoLocker 감염에 관여하고 있는 것으로 확인되었습니다. 이 스팸메일에는 TROJ_UPATRE군에 속하는 악성파일이 첨부되어 있었습니다. 이 악성코드군은 파일 사이즈가 작고 다운로드 기능을 갖추고 있다는 특징이 있습니다.

트렌드마이크로 클라우드 보안센터(SPN)의 피드백을 통해 랜셈웨어 CryptoLocker와 TROJ_UPATRE군이 연관되어 있다는 정보를 확인했습니다. 그리고 TROJ_UPATRE.VNA로 탐지되는 악성파일이 첨부된 이메일을 확인했습니다.

그림2. 악성파일이 첨부된 스팸메일

이 첨부파일은 실행되면 또다른 파일을 다운로드해 cjkienn.exe로 저장합니다(TSPY_ZBOT.VNA로 탐지). 그리고 TSPY_ZBOT.VNA는 TROJ_CRILOCK.NS로 탐지되는 CryptoLocker를 다운로드합니다.

그림3. CryptoLocker의 감염경로

몇가지 이유에서 이 위협은 매우 골칫거리입니다. 우선 ZBOT의 변종을 들 수 있습니다. 이 악성코드는 온라인뱅킹 인증 관련 정보를 수집하는 것으로 알려져 있습니다. 사이버범죄자는 수집한 정보를 이용해 은행에서 불법거래를 할 수 있습니다. 그리고 CryptoLocker는 PC에 저장된 개인적인 파일이나 중요한 파일에 접근할 수 없게 합니다.

■CryptoLocker의 암호화

CryptoLocker의 몸값요구 메시지에서는 RSA-2048 암호화를 이용한다고 말하고 있으나 분석 결과 이 악성코드는 AES+RSA 암호화를 이용하고 있는 것으로 밝혀졌습니다.

RSA 암호는 비대칭키 암호, 즉 2개의 키를 사용하는 방식입니다. 1개는 정보를 암호화하기 위해, 다른 1개는 복호하기 위해 사용됩니다. 키에는 외부의 제3자도 입수할 수 있는 공개키와 사용자가 관리하는 비밀키가 있습니다. 한편 AES 암호는 대칭키 암호를 사용하는 방식으로, 즉 동일한 키가 암호화 및 복호화에 사용됩니다.

이 악성코드는 AES 키를 이용해 파일을 암호화합니다. 복호를 위한 AES 키는 이 악성코드에 의해 암호화된 파일 내에 기록되어 있습니다. 그러나 이 키는 악성코드 내에 삽입된 RSA 공개키로 암호화되어 있습니다. 즉 암호화된 파일을 복호하기 위해 비밀키가 필요하게 되는데 그것을 입수할 수는 없습니다.

어떤 파일이 암호화되어 있는지는 PC의 자동실행 레지스트리를 확인해보면 알 수 있습니다.

그림4. PC 레지스트리 정보에서 확인할 수 있는 암호화된 파일 리스트

■CryptoLocker에 대한 트렌드마이크로의 대책

알 수 없는 발신자가 보낸 이메일의 첨부파일을 열 때는 주의를 기울여야 합니다. 트렌드마이크로 클라우드 보안센터(SPN)의 이메일 레퓨테이션 기술은 이번 위협과 관련된 이메일을 차단합니다. 웹 레퓨테이션 기술은 접속 도메인명을 생성하는 구조인 DGA(Domain Generation Algorithm)에 의해 생성된 관련 url을 탐지합니다. 파일 레퓨테이션 기술은 앞서 말한 악성코드를 탐지하고 제거합니다. 트렌드마이크로 제품의 행위기반 탐지기능은 CryptoLocker 감염으로부터 PC를 모니터링하고 악성코드의 실행을 방지합니다.

그림5. 당사제품이 관련 악성코드를 탐지

원문 :
ランサムウェア「CryptoLocker」、オンライン銀行詐欺ツール「ZBOT」を経てコンピュータに侵入 
by Kervin Alintanahin (Threats Analyst) 


728x90

'암호학' 카테고리의 다른 글

안전한 패스워드 저장  (0) 2015.09.16
base 64 에 대한 설명  (0) 2012.01.24
sha -1  (0) 2009.10.11
posted by 블르샤이닝 2012. 1. 24. 15:20
728x90
역시 대학교때 공부를 열심히 했어야해...base64는 기본적으로 암호적인 요소보다는 파일의 전송할시 영어외에 언어에 대한 깨짐 현상을 막기위해서 제공하는 방법이였다.(물론 암호학적으로도 쓰이겠지만...안쓰인다고는 않했어요^^) 
곧 웹 프로그래밍을 배워야겠군

출처 : http://blog.naver.com/PostView.nhn?blogId=wjdtjdgus956&logNo=120132827418

베이스가 64라는 것은 모든 정보를 64진수로 표시한다는
것인데, 컴퓨터는 2진수를 사용하므로 64진수로 표시하기 위해서는
2^6 = 64 즉 6 비트 2진수 열이 필요하다.

그런데 대개 컴퓨터에서 가장 기본이 되는 정보 단위는 8 비트씩 엮어진 바이트이므로
6비트와 8비트가 각각 나누어 떨어질 수 있는 공배수의 최소값 (최소 공배수)를 구하면 24비트가 된다.

24비트는 8비트 바이트에서는 3바이트가 되고, 64진수로 나타내기 위한 6비트 단위로는 4 단위가 된다. (바이트라고 반복하기 말하면 혼동이 될 것 같아서 "단위"라는 말로 대치하였다.)

따라서 Base64의 인코딩 원리는 3바이트 단위마다 (즉 24비트 마다) 6비트씩 쪼개어서 6비트 짜리 문자 4개로 만드는 것이 되겠다.

이 때 6비트씩 쪼개진 단위를 A-Z a-z 0-9 +- (모두 64개 문자)로 각각 대응시키면 Base64 인코딩이 된다.

Base64 Encoding/Decoding


그런데 입력되는 정보가 모두 3바이트씩 떨어진다는 보장이 없으므로 3바이트로 나누어떨어지지 않는 경우 = 문자로 채우기를 한다. 즉 Base64로 인코딩 된 데이타에서 = 가 보이면 그 것은 다시 원래의 정보로 되돌아 갈때 (디코딩 될때) 아무 것도 없는 것이라는 소리가 된다.
(Base64로 인코딩 정보의 끝에 최대 나올 수 있는 = 의 수는 2개가 되겠다. 즉 끝부분에 =가 없거나 1개가 있거나 2개가 있는 것이 모두 나올 수 있는 경우가 되겠다.)

디코딩은 A-Z a-z 0-9 +- 문자를 각각 6비트의 정보로 바꾸어서 4 단위 (6*4=24 비트) 마다 합쳐서 3바이트 (3*8=24 비트) 로 다시 복원시키면 된다.

이러한 2진수 데이터를 64진수형으로 변환하여 64개의 아스키 코드에 대입하는것이 Base64 알고리즘의 기본이다. 또한 이런 변환을 하는 이유는 암호화에도 있겠지만 보통은 안전한 64개의 아스키문자열로 변환하여 원할한 데이터를 전송하는데 있다. 예를 들자면 한국어의 경우 2바이트 문자열로 그대로 전송할시 문자열의 깨짐이 발생 할 수 있다. 이는 데이터 전송시 원하지 않는 결과이며 이러한것을 막기 위해 안전한 아스키코드 문자로 변환하여 전송 하는것이다. 보통 이러한 Base64인코딩 디코딩은 이메일 전송시 많이 사용된다. 하지만 데이터가 기존의 데이터보다 약 30%이상 커진다는 단점이 있다.
 그럼 일반 문자열을 Base64로 인코딩은 어떻게 하면 될까? 답은 다음의 스텝대로 시도하면 된다.

  1. 소스의 바이너리 데이타로 부터 3바이트씩 꺼낸다. 만약 나머지 소스 문자열이 3바이트가 되지 않는다면 0으로 채운다.
  2. 최초 바이트의 MSB를 6비트씩 4개의 숫자로
  3. 각각의 수치를 하단의 표를 토대로 아스키 문자로 변환한다. 다만 실제의 데이터 길이가 3바이트에 미치지 못한다면 '='로 대체 한다.
  4. 이후 데이터가 없어질때까지 1~3을 반복한다.
728x90
posted by 블르샤이닝 2009. 10. 11. 22:37
728x90

 
sha-1에 대한 인철이 발표 자료와 소스이다...뭐 이제 이해해야하지만...ㅋㅋ 이해는 했다고 치더라도 어떻게 만들까가 문제군;;ㄷㄷ
728x90