제스트의 블로그

압축 해제하고 서버 실행하면 끝이다.

서버 실행할때 커맨드 라인으로 옵션을 입력하거나 미리 설정파일을 만들어 놓고 사용 할 수 있다.

Mongo 설정 파일 yml 구조를 사용.

tab 없이 스페이스로만 영역을 설정. 머 이런것들 어려우니 작업후 yaml validator로 검증하는게 빠르다.

단일 서버 실행용.

linux 특정 위치에 특정 설정 파일을 생성.

ex) vi mongo.yml

마지막으로 실행해보자. 

./bin/mongd -f mongo.yml

앞의 글에서 Padding에 대한 내용을 이야기 하면서 Padding을 하지 않을 경우
개발자가 임의로 SEED 알고리즘을 기준으로 할 때 128비트(16바이트)블럭으로
암호화할 데이터를 가공해 주어야 한다고 한 바 있다.

암호화 서비스에 대한 활발한 구현이 진행되기 이전에 구현된 어플리케이션을 보면
Padding을 미쳐 구현하지 않아서(초기에 제공된 SEED 소스만 하더라도 Padding은
제공소스에서 제외)개발자가 임의적으로 16바이트 블럭을 만들어서 Padding을
하지 않는 방법으로 암호화를 하곤 하였다.

예를들면 패스워드 "abcd1234"를 암호화를 할때 "abcd1234        "처럼 공백으로
16바이트를 만들어서 암호화하곤 했는데 재밌는 사실은 16바이트를 암호화할 때
Padding을 하면 32바이트가 되지만 Padding을 하지 않으면 16바이트가 된다.

//Padding을 할 경우에는 다음과 같이 선언을 하였을 것이다.

스크랩:http://blog.paran.com/blog/detail/postBoard.kth?blogDataId=35385570&pmcId=javacipher&totalCount=13&preViewPage=0&ajaxPage=1&preFBlogId=35385570&preLBlogId=27788506&pageStyle=null&myCateId=0&yearMonth=null&rDay=null&style=Board&p_eye=

...(중략)...
PaddedBufferedBlockCipher blockCipher = new PaddedBufferedBlockCipher(
    new SEEDEngine());
...(중략)...

//Padding을 하지 않을 경우는 다음과 같다.

...(중략)...
BufferedBlockCipher blockCipher = new BufferedBlockCipher(
    new SEEDEngine());
...(중략)...

Paddig을 하지 않았을 때 만약에 암호화할 데이터가 다음과 같이 16바이트 블럭이 아닐 경우

byte[] data = { (byte) 0x00, (byte) 0x11, (byte) 0x22, (byte) 0x33,
  (byte) 0x44, (byte) 0x55, (byte) 0x66, (byte) 0x77,
  (byte) 0x88, (byte) 0x99, (byte) 0xaa, (byte) 0xbb,
  (byte) 0xcc, (byte) 0xdd, (byte) 0xee, (byte) 0xff, (byte) 0x33 };
  
  
DataLengthException이 발생할 것이다.

대칭키 암호화 알고리즘은 비트나 바이트, 워드 단위로 암호화하는 스트림(stream) 암호와 일정한 크기의 블럭을 단위로

암호화하는 블럭 암호 알고리즘으로 구분된다.

앞에서 예제로 보인 DES, SEED, AES와 같은 알고리즘은 블럭 단위로 암호화하는 알고리즘이다.

몇블럭씩 암호화할 것인지에 대해서는 알고리즘별로 차이를 보이는데 SEED와 같은 알고리즙은 128비트(16바이트) 단위로 암호화를 하게 된다.

다행히 암호화를 할 데이터가 16바이트 단위로 나눠진다면 몰라도 데이터는 항상 15바이트나 17바이트처럼 모자라거나 넘치기 마련이다. 블럭 암호화 알고리즘에서는 이렇게 모자라거나 넘치는 문제를 해결하기 위하여 16바이트 단위로 만들기 위해 임의의 숫자를 암호화할 데이터에 추가하게 되는데 이를 Padding이라고 한다. 따라서 15바이트 데이터는 1바이트를 Padding하여 16바이트 블럭으로 만들것이며, 17바이트처럼 넘치는 데이터는 15바이트를 Padding하여 32바이트를 만들게 된다.

앞의 예제에서 PaddedBufferedBlockCipher 라고 선언한 부분은 바로 블럭 암호화 알고리즘이면서 Padding까지 하겠다는 의미이다.
Padding을 하지 않을 경우라면 16바이트 단위로 암호화할 데이터를 인위적으로 가공을 개발을 해주어야 한다.

블럭암호화 알고리즘은 Padding이라는 절차의 문제로 평문보다 최대 16바이트 길이가 늘어날 수 있다는 것을 감안해야 한다.

스트림사이퍼의 경우는 블럭단위가 아니라 비트 단위 XOR 연산을 수행하기 때문에 별도의 Padding 절차가 필요없으며 따라서 평문이나 이를 암호화한 암호문이나 데이터의 길이가 동일하고 키 길이를 마음대로 지정할 수 있다는 장점이 있다.
아래는 대표적인 스트림 암호화 알고리즘인 RC4에 대한 예제이다.

import org.bouncycastle.crypto.StreamCipher;
import org.bouncycastle.crypto.engines.RC4Engine;
import org.bouncycastle.crypto.params.KeyParameter;
import org.bouncycastle.util.encoders.Base64;

...(중략)...

    //스트림 암호화에서 키길이는 반드시 16바이트를 고집할 필요는 없지만...
   byte[] key = {(byte)0x01,(byte)0x02,(byte)0x03,(byte)0x04,(byte)0x05,(byte)0x06,(byte)0x07,(byte)0x08,
               (byte)0x09,(byte)0x10,(byte)0x11,(byte)0x12,(byte)0x13,(byte)0x14,(byte)0x15,(byte)0x16}; 
 
    
  byte[] data = "12345대한민국asdddddddddddddddddddddddddd".getBytes();

  //스트림 암호화 시작
  StreamCipher cipher = new RC4Engine();
  cipher.init(true, new KeyParameter(key));
 
  byte[] out = new byte[data.length];

   try {
  cipher.processBytes(data, 0, data.length, out, 0);
   } catch (Exception e) {
    throw new Exception("암호화 오류가 발생하였습니다.올바른 키로 암호화하였는지 확인하십시오");
  } 
     
   System.out.println("암호화된 데이터의 길이 ="+out.length);
   System.out.println(new String(Base64.encode(out)));

  //스트림 복호화 시작
  cipher.init(false, new KeyParameter(key));
  byte[] out2 = new byte[out.length];

   try {
 cipher.processBytes(out, 0, out.length, out2, 0);
   } catch (Exception e) {

     throw new Exception("복호화 오류가 발생하였습니다.올바른 키로 복호화하였는지 확인하십시오");
  } 
  
   System.out.println("복호화된 데이터의 길이 ="+out2.length);
   System.out.println(new String(out2));

...(중략)...

스크랩:http://blog.paran.com/blog/detail/postBoard.kth?blogDataId=35205253&pmcId=javacipher&totalCount=13&preViewPage=0&ajaxPage=1&preFBlogId=35385570&preLBlogId=27788506&pageStyle=null&myCateId=0&yearMonth=null&rDay=null&style=Board&p_eye=