KR102173677B1 - 형태 보존 암호화에서 한글의 인코딩 및 디코딩 방법 및 그 장치 - Google Patents

형태 보존 암호화에서 한글의 인코딩 및 디코딩 방법 및 그 장치 Download PDF

Info

Publication number
KR102173677B1
KR102173677B1 KR1020150020138A KR20150020138A KR102173677B1 KR 102173677 B1 KR102173677 B1 KR 102173677B1 KR 1020150020138 A KR1020150020138 A KR 1020150020138A KR 20150020138 A KR20150020138 A KR 20150020138A KR 102173677 B1 KR102173677 B1 KR 102173677B1
Authority
KR
South Korea
Prior art keywords
numbers
byte
bytes
korean
characters
Prior art date
Application number
KR1020150020138A
Other languages
English (en)
Other versions
KR20160097811A (ko
Inventor
김건우
이상수
조수형
Original Assignee
한국전자통신연구원
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 한국전자통신연구원 filed Critical 한국전자통신연구원
Priority to KR1020150020138A priority Critical patent/KR102173677B1/ko
Publication of KR20160097811A publication Critical patent/KR20160097811A/ko
Application granted granted Critical
Publication of KR102173677B1 publication Critical patent/KR102173677B1/ko

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/34Encoding or coding, e.g. Huffman coding or error correction

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Document Processing Apparatus (AREA)
  • Storage Device Security (AREA)

Abstract

본 발명은 형태 보존 암호화에서 한글의 인코딩 및 디코딩 방법 및 그 장치에 관한 것으로, 형태 보존 암호화의 특성을 유지하면서 한글이 포함된 입력 문자열을 숫자열로 인코딩하고 숫자열을 한글이 포함된 문자열로 디코딩하는 방법 및 그 장치에 관한 것이다.
이에 따른 본 발명은, 상술한 과제를 해결하기 위한 본 발명은, 입력 문자열을 수신하는 단계, 상기 입력 문자열을 구성하는 적어도 하나의 2 바이트 또는 3 바이트의 한글 문자를 2개 또는 3개의 숫자로 각각 인코딩하는 단계 및 상기 인코딩된 결과를 암호화하여 암호문을 출력하는 단계를 포함하는 것을 특징으로 하는 방법 및 장치에 관한 것이다.

Description

형태 보존 암호화에서 한글의 인코딩 및 디코딩 방법 및 그 장치{Method and Apparatus for Encoding and Decoding of Korean Language in Format-Preserving Encryption}
본 발명은 형태 보존 암호화에서 한글의 인코딩 및 디코딩 방법 및 그 장치에 관한 것으로, 형태 보존 암호화의 특성을 유지하면서 한글이 포함된 입력 문자열을 숫자열로 인코딩하고 숫자열을 한글이 포함된 문자열로 디코딩하는 방법 및 그 장치에 관한 것이다.
형태 보존 암호화(Format-Preserving Encryption; FPE)에서는 평문과 동일한 길이와 포맷을 가지는 암호문이 출력된다. 예를 들어, 형태 보존 암호화를 이용하여 13자리 주민 번호를 암호화하면 이진수 형태의 128 bit 값이 생성되는 것이 아니라, 입력 문자열과 동일하게 랜덤한 13자리 숫자로 구성된 암호가 출력된다. 이 13자리 숫자로 구성된 암호를 형태 보존 암호화를 이용하여 복호 하면 원래의 문자열인 주민번호 13자리가 출력된다. 마찬가지로, 길이가 n인 한글을 포함하는 문자열을 형태 보존 암호화로 암호화하면 길이가 n인 암호가 생성되고, 이 암호를 형태 보존 암호화로 복호 하면 길이가 n인 한글을 포함하는 문자열이 복구되어야 한다.
페이스텔(feistel) 구조 기반의 형태 보존 암호화는 미국의 Voltage Security가 기반 특허(US 7,864,952 B2 Data processing systems with format-preserving encryption and decryption engines)를 가지고 있다. 기반 특허에는 입력 문자열을 숫자열로 변환하는 인코딩 방법과 역으로 입력 숫자열을 문자열로 변환하는 디코딩 방법이 개시되어 있다. 또한, 페이스텔 구조 기반의 형태 보존 암호화 표준을 다루는 NIST의 표준문서인 "NIST Special Publication 800-38G Draft: Recommendation for Block Cipher Modes of Operation-Methods for Format-Preserving Encryption"에는, 인코딩을 위해 문자 하나를 하나의 숫자로 변환해야 한다고 개시하고 있으며, 다만 구체적인 방법은 언급하고 있지 않다.
상기한 두 참조 문헌과 기존의 형태 보존 암호화에서 입력 문자열을 숫자열로 변환하고 숫자열을 문자열로 변환하는 방식에 의하면, 1 바이트 문자 하나를 인덱스 값인 숫자 하나로 변환하는 인코딩 방법과 숫자 하나를 1 바이트 문자 하나로 역변환하는 디코딩 방법이 사용된다. 이는 아스키 코드로 표현되는 영문자, 숫자, 특수 문자에는 적합한 방식이다.
종래의 형태 보존 암호화에서는 형태 보존 암호화의 입력 문자열이 영어 대소문자, 숫자, 특수 문자와 한글을 포함한다면 각 문자는 고유의 하나의 숫자로 변환된다. 즉, 종래의 형태 보존 암호화에서는 인코딩 단계에서 숫자 10개('0'~'9'), 영대문자 26개('A'~'Z'), 영소문자 26개('a'~'z'), 특수 문자 33개('$', '*', '^', '@', …), 한글 2,350개(euc-kr인 경우) 또는 11,172개(utf-8인 경우)가 서로 다른 숫자로 변환된다.
도 1을 참조하면, 종래의 형태 보존 암호화에서는 한글을 제외한 각각의 문자를 95개의 숫자로 변환한다. 구체적으로, 숫자, 영어 대소문자, 특수 문자의 경우, 숫자는 0~9, 영대문자는 10~35, 영소문자는 36~61, 특수 문자는 62~94의 숫자로 각각 변환된다. 이때, 숫자, 영대문자, 영소문자, 특수 문자의 변환 순서는 바뀔 수 있다. 즉, 영소문자가 0~25, 숫자가 26~35으로 변환되거나 이와 유사한 다른 방식으로 변환되는 것도 가능하다.
도 2를 참조하면, 종래의 형태 보존 암호화에서는 디코딩 단계에서, 0~9의 숫자는 '0'~'9'의 숫자 문자, 10~35의 숫자는 'A'~'Z'의 영대문자, 36~61의 숫자는 'a'~'z'의 영소문자, 62~94의 숫자는 '$', '*', '^', '@', …의 특수 문자로 각각 변환된다.
종래의 형태 보존 암호화 방식을 한글에 동일하게 적용하면, 도 1에서 2,350개의 한글은 95~2,444(euc-kr인 경우)의 숫자로, 도 2에서 11,172개의 한글은 95~11,266(utf-8인 경우)의 숫자로 변환된다.
숫자, 영어 대소문자, 특수 문자인 경우 하나의 문자가 아스키 코드로 1 바이트 길이를 갖기 때문에 하나의 문자를 숫자로 변환할 수 있다. 그러나 한글의 경우 하나의 문자가 아스키 코드로 2 바이트(euc-kr인 경우) 또는 3 바이트(utf-8인 경우) 길이를 갖기 때문에 종래의 형태 보존 암호화를 적용하여 암호화하면 길이가 보존되지 않는 문제점이 있다.
페이스텔 구조 기반의 형태 보존 암호화에서는 문자열을 숫자열로 변환할 때 변환되는 숫자열의 범위를 줄이는 것이 바람직하다. 상술한 종래의 형태 보존 암호화에 따르면, 한글의 경우 각각의 문자를 모두 숫자로 변환하면 모두 2,445개(euc-kr 인 경우) 또는 11,267개(utf-8인 경우)의 숫자가 사용되므로, 형태 보존 암호화의 성능을 저하하는 원인이 된다.
본 발명은 상기한 문제점을 해결하기 위한 것으로, 형태 보존 암호화에서 영문자, 숫자, 특수 문자 외에 한글에 대한 형태 보존(예를 들어, 길이 보존)을 지원하면서, 2 바이트(euc-kr인 경우) 또는 3 바이트(utf-8인 경우) 한글이 포함된 입력 문자열을 숫자열로 변환하는 인코딩 방법과 역으로 숫자열을 원래의 문자열로 변환하는 디코딩 방법 및 그 장치를 제공한다.
상술한 과제를 해결하기 위한 본 발명은, 입력 문자열을 수신하는 단계, 상기 입력 문자열을 구성하는 적어도 하나의 2 바이트 또는 3 바이트의 한글 문자를 2개 또는 3개의 숫자로 각각 인코딩하는 단계 및 상기 인코딩된 결과를 암호화하여 암호문을 출력하는 단계를 포함하는 것을 특징으로 한다.
본 발명에 따른 형태 보존 암호화에서 한글의 인코딩 및 디코딩 방법 및 그 장치는, 형태 보존 암호화에서 종래 기술(euc-kr인 경우 2,350개, utf-8인 경우 11,172개) 비해 매우 적은 수의 숫자(euc-kr인 경우 94개, utf-8인 경우 68개)만을 이용하여 한글을 인코딩 및 디코딩할 수 있다.
또한, 본 발명에 따른 형태 보존 암호화에서 한글의 인코딩 및 디코딩 방법 및 그 장치는, 형태 보존 암호화의 인코딩 및 디코딩 후에도 입력 문자열의 길이가 보존되는 특성이 유지되도록 한다.
도 1은 종래 기술에 따른 형태 보존 암호화에서 인코딩 방법을 설명하기 위한 도면이다.
도 2는 종래 기술에 따른 형태 보존 암호화에서 디코딩 방법을 설명하기 위한 도면이다.
도 3은 본 발명의 제1 실시 예에 따른 Euc-kr을 사용하는 형태 보존 암호화에서 인코딩 방법을 설명하기 위한 도면이다.
도 4는 본 발명의 제2 실시 예에 따른 Euc-kr을 사용하는 형태 보존 암호화에서 인코딩 방법을 설명하기 위한 도면이다.
도 5는 본 발명의 제3 실시 예에 따른 Euc-kr을 사용하는 형태 보존 암호화에서 디코딩 방법을 설명하기 위한 도면이다.
도 6은 본 발명의 제4 실시 예에 따른 Euc-kr을 사용하는 형태 보존 암호화에서 디코딩 방법을 설명하기 위한 도면이다.
도 7은 본 발명의 제5 실시 예에 따른 Utf-8을 사용하는 형태 보존 암호화에서 인코딩 방법을 설명하기 위한 도면이다.
도 8은 본 발명의 제6 실시 예에 따른 Utf-8을 사용하는 형태 보존 암호화에서 인코딩 방법을 설명하기 위한 도면이다.
도 9는 본 발명의 제7 실시 예에 따른 Utf-8을 사용하는 형태 보존 암호화에서 디코딩 방법을 설명하기 위한 도면이다.
도 10은 본 발명의 제8 실시 예에 따른 Utf-8을 사용하는 형태 보존 암호화에서 디코딩 방법을 설명하기 위한 도면이다.
도 11은 본 발명의 실시 예에 따른 형태 보존 암호화에서 한글의 인코딩 방법을 나타낸 순서도이다.
도 12는 본 발명의 실시 예에 따른 형태 보존 암호화에서 한글의 디코딩 방법을 나타낸 순서도이다.
도 13은 본 발명의 실시 예에 따른 본 발명의 실시 예에 따른 형태 보존 암호화에서 한글의 인코딩/디코딩 장치의 구성을 나타낸 블록도이다.
본 명세서의 실시 예를 설명함에 있어, 관련된 공지 구성 또는 기능에 대한 구체적인 설명이 본 명세서의 요지를 흐릴 수 있다고 판단되는 경우, 그 상세한 설명은 생략될 수 있다.
본 명세서에서 어떤 구성 요소가 다른 구성 요소에 "연결되어 있다."거나 "접속되어 있다."라고 언급된 때에는, 해당 구성 요소가 다른 구성 요소에 직접적으로 연결되어 있거나 또는 접속되어 있는 경우뿐만 아니라, 해당 구성 요소와 다른 구성 요소의 사이에 다른 구성 요소가 존재하는 경우도 포함하는 것으로 이해되어야 할 것이다.
본 명세서에서 사용되는 "포함한다," "포함할 수 있다." 등의 표현은 개시된 해당 기능, 동작, 구성 요소 등의 존재를 가리키며, 추가적인 하나 이상의 기능, 동작, 구성 요소 등을 제한하지 않는다. 또한, 본 명세서에서, "포함하다." 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.  
본 명세서에서 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다.
이하, 첨부된 도면을 참조하여 본 발명을 설명한다.
본 발명은 형태 보존 암호화에서, 기존에 2 바이트의 한글 한 자를 1 바이트의 숫자 하나로 인코딩함으로써 입력 문자열의 형태(길이)가 보존되지 않던 문제를 해결하기 위한 것으로, 2 바이트(euc-kr 인 경우) 또는 3 바이트(utf-8인 경우)의 한글 한 자를 1 바이트의 숫자 두 개(euc-kr 인 경우) 또는 세 개(utf-8인 경우)로 인코딩하는 방법에 관한 것이다.
또한, 본 발명은 본 발명에 따라 인코딩된 입력 문자열에 대하여, 1 바이트의 숫자 두 개(euc-kr 인 경우) 또는 세 개(utf-8인 경우)를 2 바이트(euc-kr 인 경우) 또는 3 바이트(utf-8인 경우)의 한글 한자로 디코딩하는 방법에 관한 것이다.
이하에서는, 본 발명이 적용되는 각각이 실시 예들에 따라 본 발명의 기술적 특징을 상세히 설명한다.
Euc -kr을 사용하는 한글의 인코딩과 디코딩
Euc-kr 방식에서는, 한글을 표현할 때 첫 번째 바이트와 두 번째 바이트를 로드하여 2 바이트로 합친다. 예를 들어, '가'를 표현하는 경우, Euc-kr 방식에서는 첫 번째 바이트 0xB0와 두 번째 바이트 0xA1을 로드하고 이들을 합친 2 바이트 0xB0A1으로 '가'를 표현한다.
Euc-kr 방식에서 한글 문자는 총 2,350글자이며, 모든 한글 문자는 다음 표 1의 2 바이트 중 하나로 표현될 수 있다.
0xB0A1~0xB0FE, 0xB1A1~0xB1FE, 0xB2A1~0xB2FE, 0xB3A1~0xB3FE, 0xB4A1~0xB4FE,
0xB5A1~0xB5FE, 0xB6A1~0xB6FE, 0xB7A1~0xB7FE, 0xB8A1~0xB8FE, 0xB9A1~0xB9FE,
0xBAA1~0xBAFE, 0xBBA1~0xBBFE, 0xBCA1~0xBCFE, 0xBDA1~0xBDFE, 0xBEA1~0xBEFE,
0xBFA1~0xBFFE, 0xC0A1~0xC0FE, 0xC1A1~0xC1FE, 0xC2A1~0xC2FE, 0xC3A1~0xC3FE,
0xC4A1~0xC4FE, 0xC5A1~0xC5FE, 0xC6A1~0xC6FE, 0xC7A1~0xC7FE, 0C8A1~0xC8FE
상기 2 바이트들을 참고하면, 2 바이트를 구성하는 각각의 바이트는 모두 0xA1에서 0xFE 사이의 94개 값 중 하나로 구성됨을 알 수 있다. 즉, Euc-kr 방식에서 모든 한글 문자는, 94개 값의 바이트 조합으로 표현된다.
이에 따라 본 발명에서는, Euc-kr 방식을 사용하는 형태 보존 암호화에서, 한글 문자를 표현하기 위한 94개의 바이트를 94개의 숫자에 각각 대응시키고, 한글 문자를 구성하는 2개의 바이트를 각각 대응하는 숫자로 변환함으로써, 한글 한 자(2 바이트)를 2개의 숫자(2 바이트)로 인코딩한다.
인코딩 방법
■ 제1 실시 예: 입력 문자열이 영어 대소문자, 숫자, 특수 문자 중 적어도 하나와 한글 문자를 함께 포함하는 경우
입력 문자열이 영어 대소문자, 숫자, 특수 문자 중 적어도 하나와 한글 문자를 함께 포함하는 경우, 본 발명에서 영어 대소문자, 숫자, 특수 문자는 종래 기술에 따라 0~94의 숫자로 인코딩되고, 한글 문자는 한글 문자를 표현하는 두 개의 바이트는 각각 95~188의 숫자로 인코딩된다. 이를 위하여, 본 발명에서는 아래와 같이, 한글 문자를 표현하는 0xA1~0xFE 사이의 바이트를 95~188 사이의 숫자에 각각 대응시킨다. 결과적으로, 본 발명에서는 다음의 표 2와 같이 한글 한 자를 95~188 사이의 숫자 두 개로 인코딩한다.
0xA1→95, 0xA2→996, 0xA3→997, …, 0xFD→9187, 0xFE→9188
구체적으로, 도 3을 참조하면, Euc-kr 방식에서 '가'는 0xB0와 0xA1의 두 개의 바이트가 합쳐진 0xb0a1의 2 바이트로 표현된다. 상기한 본 발명에 따르면, 0xB0와 0xA1는 각각 숫자 110과 95에 대응하므로, 한글 '가'는 110과 95의 숫자 두 개로 인코딩된다. Euc-kr 방식에서 '나'는 0xB3와 0xAA의 두 개의 바이트가 합쳐진 0xB3AA의 2 바이트로 표현된다. 상기한 본 발명에 따르면, 0xB3와 0xAA는 각각 숫자 113과 104에 대응하므로, 한글 '나'는 113과 104의 숫자 두 개로 인코딩된다. Euc-kr 방식에서 '한'은 0xC7과 0xD1의 두 개의 바이트가 합쳐진 0xC7D1의 2 바이트로 표현된다. 상기한 본 발명에 따르면, 0xC7과 0xD1은 각각 숫자 133과 143에 대응하므로, 한글 '한'는 133과 143의 숫자 두 개로 인코딩된다. Euc-kr 방식에서 '국'은 0xB1과 0xB9의 두 개의 바이트가 합쳐진 0xB1AB9의 2 바이트로 표현된다. 상기한 본 발명에 따르면, 0xB1과 0xB9는 각각 숫자 111과 119에 대응하므로, 한글 '국'은 111과 119의 숫자 두 개로 인코딩된다.
상기한 본 발명의 제1 실시 예에 따를 때, 형태 보존 암호화의 입력 문자열이 '0190ABYZabyz~~가나다라한국'이라면 형태 보존 암호화의 인코딩 과정에서 입력 문자열은 다음과 같이 인코딩된다.
'0190ABYZabyz~~'→"0 1 9 0 10 11 34 35 36 37 60 61 94 94"
'가나다라한국' →"110 95 113 104 114 151 116 177 133 143 111 119"
상기에서, 숫자, 영어 대소문자, 특수 문자는 종래 기술에 따라 각각에 대응하는 0~94 사이의 숫자로 인코딩된다. 따라서, 총 14개의 문자가 14개의 숫자로 변환되고, 변환 전후의 문자열 길이는 14 바이트로 동일하다.
한편, 상기에서 한글 문자는, 본 발명의 제1 실시 예에 따라, 한글 문자를 구성하는 2 바이트 각각에 대응하는 95~188 사이의 숫자로 인코딩된다. 따라서, 총 6개의 문자가 12개의 숫자로 변환되고, 변환 전후의 문자열 길이는 12 바이트로 동일하다. 종래 기술에서는, 6개의 문자가 6개의 숫자로 각각 변환되므로, 변환 전후의 문자열 길이는 12 바이트에서 6 바이트로 줄어든다.
■ 제2 실시 예: 입력 문자열이 한글 문자만 포함하는 경우
입력 문자열이 한글 문자만 포함하는 경우, 본 발명에서 한글 문자는 한글 문자를 표현하는 두 개의 바이트는 각각 0~93의 숫자로 인코딩된다. 이를 위하여, 본 발명에서는 아래와 같이, 한글 문자를 표현하는 0xA1~0xFE 사이의 바이트를 0~93 사이의 숫자에 각각 대응시킨다. 결과적으로, 본 발명에서는 다음의 표 3과 같이 한글 한 자를 0~93 사이의 숫자 두 개로 인코딩한다.
0xA1→0, 0xA2→1, 0xA3→2, …, 0xFD→92, 0xFE→93
구체적으로, 도 4를 참조하면, Euc-kr 방식에서 '가'는 0xB0와 0xA1의 두 개의 바이트가 합쳐진 0xb0a1의 2 바이트로 표현된다. 상기한 본 발명에 따르면, 0xB0와 0xA1는 각각 숫자 15와 0에 대응하므로, 한글 '가'는 15와 0의 숫자 두 개로 인코딩된다. Euc-kr 방식에서 '나'는 0xB3와 0xAA의 두 개의 바이트가 합쳐진 0xB3AA의 2 바이트로 표현된다. 상기한 본 발명에 따르면, 0xB3와 0xAA는 각각 숫자 18과 9에 대응하므로, 한글 '나'는 18과 9의 숫자 두 개로 인코딩된다. Euc-kr 방식에서 '한'은 0xC7과 0xD1의 두 개의 바이트가 합쳐진 0xC7D1의 2 바이트로 표현된다. 상기한 본 발명에 따르면, 0xC7과 0xD1은 각각 숫자 38과 48에 대응하므로, 한글 '한'는 38과 48의 숫자 두 개로 인코딩된다. Euc-kr 방식에서 '국'은 0xB1과 0xB9의 두 개의 바이트가 합쳐진 0xB1AB9의 2 바이트로 표현된다. 상기한 본 발명에 따르면, 0xB1과 0xB9는 각각 숫자 16과 24에 대응하므로, 한글 '국'은 16과 24의 숫자 두 개로 인코딩된다.
상기한 본 발명의 제2 실시 예에 따를 때, 형태 보존 암호화의 입력 문자열이 '가나다라한국'이라면 형태 보존 암호화의 인코딩 과정에서 입력 문자열은 다음과 같이 인코딩된다.
'가나다라한국' →"110 95 113 104 114 151 116 177 133 143 111 119"
상기에서, 한글 문자는, 본 발명의 제2 실시 예에 따라, 한글 문자를 구성하는 2 바이트 각각에 대응하는 0~93 사이의 숫자로 인코딩된다. 따라서, 총 6개의 문자가 12개의 숫자로 변환되고, 변환 전후의 문자열 길이는 12 바이트로 동일하다. 종래 기술에서는, 6개의 문자가 6개의 숫자로 각각 변환되므로, 변환 전후의 문자열 길이는 12 바이트에서 6 바이트로 줄어든다.
상기한 실시 예들에 따르면, 종래 기술에서 변환 전후의 한글 문자열 길이가 보존되지 않던 것과 달리, 본 발명에서는 변환 전후 한글 문자열의 길이가 보존되어, 형태 보존 암호화의 특성을 유지시킨다. 또한, 종래 기술에서는 한글 문자의 인코딩을 위해 2,350개의 숫자가 필요하였으나, 본 발명에서는 94개의 숫자만 필요하다.
본 발명의 제1 실시 예와 제2 실시 예에 있어서, 제1 실시 예는 입력 문자열의 인코딩을 위하여 189개의 숫자가 필요하나, 제2 실시 예는 한글로만 이루어진 입력 문자열에 적용되며, 인코딩을 위하여 94개의 숫자만 필요하다는 차이점이 있다.
디코딩 방법
■ 제3 실시 예: 입력 문자열이 영어 대소문자, 숫자, 특수 문자 중 적어도 하나와 한글 문자를 함께 포함하는 경우
입력 문자열이 영어 대소문자, 숫자, 특수 문자 중 적어도 하나와 한글 문자를 함께 포함하는 경우, 본 발명에서 0~94의 숫자는 종래 기술에 따라 영어 대소문자, 숫자, 특수 문자로 디코딩되고, 95~188의 숫자는 연속되는 두 개의 숫자가 하나의 한글 문자로 디코딩된다. 이를 위하여, 본 발명에서는 아래와 같이, 95~188의 숫자를 한글 문자를 표현하는 0xA1~0xFE 사이의 바이트에 각각 대응시킨다. 결과적으로, 본 발명에서는 95~188 사이의 숫자 두 개를 다음의 표 4와 같이 한글 한 자로 디코딩한다. 본 발명의 제3 실시 예는, 본 발명의 제1 실시 예에 대한 역변환에 해당한다.
95→0xA1, 96→0xA2, 97→0xA3, …, 187→0xFD, 188→0xFE
구체적으로, 도 5를 참조하면, 숫자 110과 95는 각각 0xB0와 0xA1에 대응하고, 0xB0와 0xA1를 결합한 0xb0a1는 한글 '가'로 디코딩된다. 숫자 113과 104는 각각 0xB3와 0xAA에 대응하고, 0xB3와 0xAA를 결합한 0xB3AA는 한글 '나'로 디코딩된다. 숫자 133과 143은 각각 0xC7과 0xD1에 대응하고, 0xC7과 0xD1를 결합한 0xC7D1는 한글 '한'으로 디코딩된다. 숫자 111과 119는 각각 0xB1과 0xB9에 대응하고, 0xB1과 0xB9를 결합한 0xB1AB9는 한글 '국'으로 디코딩된다.
상기한 본 발명의 제3 실시 예에 따를 때, 형태 보존 암호화의 입력 문자열이 '0 1 9 0 10 11 34 35 36 37 60 61 94 110 95 113 104 114 151 116 177 133 143 111 119'라면 형태 보존 암호화의 디코딩 과정에서 입력 문자열은 다음과 같이 디코딩된다.
'0 1 9 0 10 11 34 35 36 37 60 61 94 94'→" 0190ABYZabyz~~"
'110 95 113 104 114 151 116 177 133 143 111 119'→" 가나다라한국"
상기에서, 0~94 사이의 숫자는 종래 기술에 따라 각각에 대응하는 숫자, 영어 대소문자, 특수 문자로 인코딩된다. 따라서, 총 14개의 숫자가 14개의 문자로 변환되고, 변환 전후의 문자열 길이는 14 바이트로 동일하다.
한편, 상기에서 95~188 사이의 숫자는, 본 발명의 제3 실시 예에 따라, 연속된 두 개의 숫자에 각각 대응하는 두 개의 바이트가 결합된 2 바이트에 대응하는 한글 문자로 디코딩된다. 따라서, 총 12개의 숫자가 6개의 한글 문자로 변환되고, 변환 전후의 문자열 길이는 12 바이트로 동일하다. 종래 기술에서는, 12개의 숫자가 12개의 한글 문자로 각각 변환되므로, 변환 전후의 문자열 길이는 12 바이트에서 24 바이트로 늘어난다.
■ 제4 실시 예: 입력 문자열이 한글 문자만 포함하는 경우
입력 문자열이 한글 문자만 포함하는 경우, 본 발명에서 0~93의 숫자는 연속되는 두 개의 숫자가 하나의 한글 문자로 디코딩된다. 이를 위하여, 본 발명에서는 아래와 같이, 0~93 사이의 숫자를 한글 문자를 표현하는 0xA1~0xFE 사이의 바이트에 각각 대응시킨다. 결과적으로, 본 발명에서는 0~93 사이의 숫자 두 개를 다음의 표 5와 같이 한글 한 자로 디코딩한다. 본 발명의 제4 실시 예는, 본 발명의 제2 실시 예에 대한 역변환에 해당한다.
0→0xA1, 1→0xA2, 4→0xA3, …, 92→0xFD, 93→0xFE
구체적으로, 도 6을 참조하면, 숫자 15와 0은 각각 0xB0와 0xA1에 대응하고, 0xB0와 0xA1를 결합한 0xb0a1는 한글 '가'로 디코딩된다. 숫자 18과 9는 각각 0xB3와 0xAA에 대응하고, 0xB3와 0xAA를 결합한 0xB3AA는 한글 '나'로 디코딩된다. 숫자 38과 48은 각각 0xC7과 0xD1에 대응하고, 0xC7과 0xD1를 결합한 0xC7D1는 한글 '한'으로 디코딩된다. 숫자 16과 24는 각각 0xB1과 0xB9에 대응하고, 0xB1과 0xB9를 결합한 0xB1AB9는 한글 '국'으로 디코딩된다.
상기한 본 발명의 제4 실시 예에 따를 때, 형태 보존 암호화의 입력 문자열이 '15 0 18 9 19 56 21 82 38 48 16 24'라면 형태 보존 암호화의 디코딩 과정에서 입력 문자열은 다음과 같이 디코딩된다.
'15 0 18 9 19 56 21 82 38 48 16 24'→" 가나다라한국"
상기에서 0~94 사이의 숫자는, 본 발명의 제4 실시 예에 따라, 연속된 두 개의 숫자에 각각 대응하는 두 개의 바이트가 결합된 2 바이트에 대응하는 한글 문자로 디코딩된다. 따라서, 총 12개의 숫자가 6개의 한글 문자로 변환되고, 변환 전후의 문자열 길이는 12 바이트로 동일하다. 종래 기술에서는, 12개의 숫자가 12개의 한글 문자로 각각 변환되므로, 변환 전후의 문자열 길이는 12 바이트에서 24 바이트로 늘어난다.
상기한 실시 예들에 따르면, 종래 기술에서 변환 전후의 한글 문자열 길이가 보존되지 않던 것과 달리, 본 발명에서는 변환 전후 한글 문자열의 길이가 보존되어, 형태 보존 암호화의 특성을 유지시킨다.
Utf -8을 사용하는 한글의 인코딩과 디코딩
Utf-8 방식에서는, 한글을 표현할 때 첫 번째 바이트, 두 번째 바이트 및 세 번째 바이트를 로드하여 3 바이트로 합친다. 예를 들어, '가'를 표현하는 경우, Utf-8 방식에서는 첫 번째 바이트 0xEA, 두 번째 바이트 0xB0, 세 번째 바이트 0x80을 로드하고 이들을 합친 3 바이트 0xEAB080으로 '가'를 표현한다.
Utf-8 방식에서 한글 문자는 총 11,172글자이며, 모든 한글 문자는 다음 표 6의 3 바이트 중 하나로 표현될 수 있다.
0xEAB080~0xEAB0BF, 0xEAB180~0xEAB1BF, 0xEAB280~0xEAB2BF,
0xEAB380~0xEAB3BF, 0xEAB480~0xEAB4BF, 0xEAB580~0xEAB5BF,
0xEAB680~0xEAB6BF, 0xEAB780~0xEAB7BF, 0xEAB880~0xEAB8BF,
0xEAB980~0xEAB9BF, 0xEABA80~0xEABABF, 0xEABB80~0xEABBBF,
0xEABC80~0xEABCBF, 0xEABD80~0xEABDBF, 0xEABE80~0xEABEBF,
0xEABF80~0xEABFBF,
0xEB8080~0xEB80BF, 0xEB8180~0xEB81BF, 0xEB8280~0xEB82BF,
0xEB8380~0xEB83BF, 0xEB8480~0xEB84BF, 0xEB8580~0xEB85BF,
0xEB8680~0xEB86BF, 0xEB8780~0xEB87BF, 0xEB8880~0xEB88BF,
0xEB8980~0xEB89BF, 0xEB8A80~0xEB8ABF, 0xEB8B80~0xEB8BBF,
0xEB8C80~0xEB8CBF, 0xEB8D80~0xEB8DBF, 0xEB8E80~0xEB8EBF,
0xEB8F80~0xEB8FBF,
…,
0xED9880~0xED98BF, 0xED9980~0xED99BF, 0xED9A80~0xED9ABF,
0xED9B80~0xED9BBF, 0xED9C80~0xED9CBF, 0xED9D80~0xED9DBF,
0xED9E80~0xED9EA3
상기 3 바이트들을 참고하면, 3 바이트 중 첫 번째 바이트는 0xEA~0xED 사이의 4개 값 중 하나로 구성되고, 두 번째 바이트 및 세 번째 바이트는 0x80~0xBF 사이의 64개 값 중 하나로 구성됨을 알 수 있다. 즉, Utf-8 방식에서 모든 한글 문자는 64+4개 값의 바이트 조합으로 표현된다.
이에 따라 본 발명에서는, Utf-8 방식을 사용하는 형태 보존 암호화에서, 한글 문자를 표현하기 위한 68개의 바이트를 68개의 숫자에 각각 대응시키고, 한글 문자를 구성하는 3개의 바이트를 각각 대응하는 숫자로 변환함으로써, 한글 한 자(3 바이트)를 3개의 숫자(3 바이트)로 인코딩한다.
인코딩 방법
■ 제5 실시 예: 입력 문자열이 영어 대소문자, 숫자, 특수 문자 중 적어도 하나와 한글 문자를 함께 포함하는 경우
입력 문자열이 영어 대소문자, 숫자, 특수 문자 중 적어도 하나와 한글 문자를 함께 포함하는 경우, 본 발명에서 영어 대소문자, 숫자, 특수 문자는 종래 기술에 따라 0~94의 숫자로 인코딩되고, 한글 문자는 한글 문자를 표현하는 세 개의 바이트가 각각 95~162의 숫자로 인코딩된다. 이를 위하여, 본 발명에서는 아래와 같이, 한글 문자를 표현하는 0x80~0xBF 사이의 바이트를 95~158 사이의 숫자에 각각 대응시키고, 0xEA~0xED 사이의 바이트는 159~162 사이의 숫자에 각각 대응시킨다. 결과적으로, 본 발명에서는 한글 한 자를 다음의 표 7과 같이 95~162 사이의 숫자 세 개로 인코딩한다.
0x80→95, 0x81→96, 0x82→97, …, 0xBE→157, 0xBF→158,
0xEA→159, 0xEB→160, 0xEC→161, 0xED→162
구체적으로, 도 7을 참조하면, Utf-8 방식에서 '가'는 0xEA, 0xB0와 0x80의 세 개의 바이트가 합쳐진 0xEAB080의 3 바이트로 표현된다. 상기한 본 발명에 따르면, 0xEA, 0xB0와 0x80는 각각 숫자 159, 143과 95에 대응하므로, 한글 '가'는 159, 143과 95의 숫자 세 개로 인코딩된다. Utf-8 방식에서 '나'는 0xEB, 0x82와 0x98의 세 개의 바이트가 합쳐진 0xEB8298의 3 바이트로 표현된다. 상기한 본 발명에 따르면, 0xEB, 0x82와 0x98은 각각 숫자 160, 97과 119에 대응하므로, 한글 '나'는 160, 97과 119의 숫자 세 개로 인코딩된다. Utf-8 방식에서 '한'은 0xED, 0x95와 0x9C의 세 개의 바이트가 합쳐진 0xED959C의 3 바이트로 표현된다. 상기한 본 발명에 따르면, 0xED, 0x95와 0x9C는 각각 숫자 162, 116과 123에 대응하므로, 한글 '한'는 162, 116과 123의 숫자 세 개로 인코딩된다. Utf-8 방식에서 '국'은 0xEA, 0xB5와 0xAD의 세 개의 바이트가 합쳐진 0xEAB5AD의 3 바이트로 표현된다. 상기한 본 발명에 따르면, 0xEA, 0xB5와 0xAD는 각각 숫자 159, 148과 140에 대응하므로, 한글 '국'은 159, 148과 140의 숫자 세 개로 인코딩된다.
상기한 본 발명의 제5 실시 예에 따를 때, 형태 보존 암호화의 입력 문자열이 '0190ABYZabyz~~가나다라한국'이라면 형태 보존 암호화의 인코딩 과정에서 입력 문자열은 다음과 같이 인코딩된다.
'0190ABYZabyz~~'→"0 1 9 0 10 11 34 35 36 37 60 61 94 94"
'가나다라한국' →"159 143 95 160 97 119 160 106 131 160 124 155 162 116 123 159 148 140"
상기에서, 숫자, 영어 대소문자, 특수 문자는 종래 기술에 따라 각각에 대응하는 0~94 사이의 숫자로 인코딩된다. 따라서, 총 14개의 문자가 14개의 숫자로 변환되고, 변환 전후의 문자열 길이는 14 바이트로 동일하다.
한편, 상기에서 한글 문자는, 본 발명의 제5 실시 예에 따라, 한글 문자를 구성하는 3 바이트 각각에 대응하는 95~162 사이의 숫자로 인코딩된다. 따라서, 총 6개의 문자가 18개의 숫자로 변환되고, 변환 전후의 문자열 길이는 18 바이트로 동일하다. 종래 기술에서는, 6개의 문자가 6개의 숫자로 각각 변환되므로, 변환 전후의 문자열 길이는 18 바이트에서 6 바이트로 줄어든다.
■ 제6 실시 예: 입력 문자열이 한글 문자만 포함하는 경우
입력 문자열이 한글 문자만 포함하는 경우, 본 발명에서 한글 문자는 한글 문자를 표현하는 세 개의 바이트는 각각 0~67의 숫자로 인코딩된다. 이를 위하여, 본 발명에서는 아래와 같이, 한글 문자를 표현하는 0x80~0xBF 사이의 바이트를 0~63 사이의 숫자에 각각 대응시키고, 0xEA~0xED 사이의 바이트는 64~67 사이의 숫자에 각각 대응시킨다. 결과적으로, 본 발명에서는 한글 한 자를 다음의 표 8과 같이 67 사이의 숫자 세 개로 인코딩한다.
0x80→0, 0x81→1, 0x82→2, …, 0xBE→62, 0xBF→63,
0xEA→64, 0xEB→65, 0xEC→66, 0xED→67
구체적으로, 도 8을 참조하면, Utf-8 방식에서 '가'는 0xEA, 0xB0와 0x80의 세 개의 바이트가 합쳐진 0xEAB080의 3 바이트로 표현된다. 상기한 본 발명에 따르면, 0xEA, 0xB0와 0x80는 각각 숫자 64, 48과 0에 대응하므로, 한글 '가'는 64, 48과 0의 숫자 세 개로 인코딩된다. Utf-8 방식에서 '나'는 0xEB, 0x82와 0x98의 세 개의 바이트가 합쳐진 0xEB8298의 3 바이트로 표현된다. 상기한 본 발명에 따르면, 0xEB, 0x82와 0x98은 각각 숫자 65, 3과 24에 대응하므로, 한글 '나'는 65, 3과 24의 숫자 세 개로 인코딩된다. Utf-8 방식에서 '한'은 0xED, 0x95와 0x9C의 세 개의 바이트가 합쳐진 0xED959C의 3 바이트로 표현된다. 상기한 본 발명에 따르면, 0xED, 0x95와 0x9C는 각각 숫자 67, 21과 28에 대응하므로, 한글 '한'는 67, 21과 28의 숫자 세 개로 인코딩된다. Utf-8 방식에서 '국'은 0xEA, 0xB5와 0xAD의 세 개의 바이트가 합쳐진 0xEAB5AD의 3 바이트로 표현된다. 상기한 본 발명에 따르면, 0xEA, 0xB5와 0xAD는 각각 숫자 64, 53과 45에 대응하므로, 한글 '국'은 64, 53과 45의 숫자 세 개로 인코딩된다.
상기한 본 발명의 제6 실시 예에 따를 때, 형태 보존 암호화의 입력 문자열이 '가나다라한국'이라면 형태 보존 암호화의 인코딩 과정에서 입력 문자열은 다음과 같이 인코딩된다.
'가나다라한국' →"64 48 0 65 2 24 65 11 36 65 29 60 67 21 28 64 53 45"
상기에서, 한글 문자는, 본 발명의 제6 실시 예에 따라, 한글 문자를 구성하는 3 바이트 각각에 대응하는 0~67 사이의 숫자로 인코딩된다. 따라서, 총 6개의 문자가 18개의 숫자로 변환되고, 변환 전후의 문자열 길이는 18 바이트로 동일하다. 종래 기술에서는, 6개의 문자가 6개의 숫자로 각각 변환되므로, 변환 전후의 문자열 길이는 18 바이트에서 6 바이트로 줄어든다.
상기한 실시 예들에 따르면, 종래 기술에서 변환 전후의 한글 문자열 길이가 보존되지 않던 것과 달리, 본 발명에서는 변환 전후 한글 문자열의 길이가 보존되어, 형태 보존 암호화의 특성을 유지시킨다. 또한, 종래 기술에서는 한글 문자의 인코딩을 위해 11,267개의 숫자가 필요하였으나, 본 발명에서는 68개의 숫자만 필요하다.
본 발명의 제5 실시 예와 제6 실시 예에 있어서, 제5 실시 예는 입력 문자열의 인코딩을 위하여 163개의 숫자가 필요하나, 제6 실시 예는 한글로만 이루어진 입력 문자열에 적용되며, 인코딩을 위하여 68개의 숫자만 필요하다는 차이점이 있다.
디코딩 방법
■ 제7 실시 예: 입력 문자열이 영어 대소문자, 숫자, 특수 문자 중 적어도 하나와 한글 문자를 함께 포함하는 경우
입력 문자열이 영어 대소문자, 숫자, 특수 문자 중 적어도 하나와 한글 문자를 함께 포함하는 경우, 본 발명에서 0~94의 숫자는 종래 기술에 따라 영어 대소문자, 숫자, 특수 문자로 디코딩되고, 95~162의 숫자는 연속되는 세 개의 숫자가 하나의 한글 문자로 디코딩된다. 이를 위하여, 본 발명에서는 아래와 같이, 95~162의 숫자를 한글 문자를 표현하는 0xEA~0xED 사이의 바이트 및 0x80~0xBF 사이의 바이트에 각각 대응시킨다. 결과적으로, 본 발명에서는 95~162 사이의 숫자 세 개를 다음의 표 9와 같이 한글 한 자로 디코딩한다. 본 발명의 제7 실시 예는, 본 발명의 제5 실시 예에 대한 역변환에 해당한다.
95→0x80, 96→0x81, 97→0x82, …, 157→0xBE, 158→0xBF
159→0xEA, 160→0xEB, 161→0xEC, 162→0xED
구체적으로, 도 9를 참조하면, 숫자 159, 143과 95는 각각 0xEA, 0xB0와 0x80에 대응하고, 0xEA, 0xB0와 0x80을 결합한 0xEAB080는 한글 '가'로 디코딩된다. 숫자 160, 97과 119는 각각 0xEB, 0x82와 0x98에 대응하고, 0xEB, 0x82와 0x98을 결합한 0xEB8298은 한글 '나'로 디코딩된다. 숫자 162, 116과 123은 각각 0xED, 0x95와 0x9C 에 대응하고, 0xED, 0x95와 0x9C를 결합한 0xED959C는 한글 '한'으로 디코딩된다. 숫자 159, 148과 140은 각각 0xEA, 0xB5와 0xAD에 대응하고, 0xEA, 0xB5와 0xAD를 결합한 0xEAB5AD는 한글 '국'으로 디코딩된다.
상기한 본 발명의 제7 실시 예에 따를 때, 형태 보존 암호화의 입력 문자열이 '0 1 9 0 10 11 34 35 36 37 60 61 94 94 159 143 95 160 97 119 160 106 131 160 124 155 162 116 123 159 148 140'이라면 형태 보존 암호화의 디코딩 과정에서 입력 문자열은 다음과 같이 디코딩된다.
'0 1 9 0 10 11 34 35 36 37 60 61 94 94'→" 0190ABYZabyz~~"
'159 143 95 160 97 119 160 106 131 160 124 155 162 116 123 159 148 140'→" 가나다라한국"
상기에서, 0~94 사이의 숫자는 종래 기술에 따라 각각에 대응하는 숫자, 영어 대소문자, 특수 문자로 인코딩된다. 따라서, 총 14개의 숫자가 14개의 문자로 변환되고, 변환 전후의 문자열 길이는 14 바이트로 동일하다.
한편, 상기에서 95~162 사이의 숫자는, 본 발명의 제7 실시 예에 따라, 연속된 세 개의 숫자에 각각 대응하는 세 개의 바이트가 결합된 3 바이트에 대응하는 한글 문자로 디코딩된다. 따라서, 총 18개의 숫자가 6개의 한글 문자로 변환되고, 변환 전후의 문자열 길이는 18 바이트로 동일하다. 종래 기술에서는, 18개의 숫자가 18개의 한글 문자로 각각 변환되므로, 변환 전후의 문자열 길이는 18 바이트에서 54 바이트로 늘어난다.
■ 제8 실시 예: 입력 문자열이 한글 문자만 포함하는 경우
입력 문자열이 한글 문자만 포함하는 경우, 본 발명에서 0~67의 숫자는 연속되는 세 개의 숫자가 하나의 한글 문자로 디코딩된다. 이를 위하여, 본 발명에서는 아래와 같이, 0~67 사이의 숫자를 한글 문자를 표현하는 0xEA~0xED 사이의 바이트 및 0x80~0xBF 사이의 바이트에 각각 대응시킨다. 결과적으로, 본 발명에서는 0~67 사이의 숫자 세 개를 다음의 표 10과 같이 한글 한 자로 디코딩한다. 본 발명의 제8 실시 예는, 본 발명의 제6 실시 예에 대한 역변환에 해당한다.
0→0x80, 1→0x81, 2→0x82, …, 62→0xBE, 63→0xBF
64→0xEA, 65→0xEB, 66→0xEC, 67→0xED
구체적으로, 도 10을 참조하면, 숫자 64, 48과 0은 각각 0xEA, 0xB0와 0x80에 대응하고, 0xEA, 0xB0와 0x80을 결합한 0xEAB080는 한글 '가'로 디코딩된다. 숫자 65, 3과 24는 각각 0xEB, 0x82와 0x98에 대응하고, 0xEB, 0x82와 0x98을 결합한 0xEB8298은 한글 '나'로 디코딩된다. 숫자 67, 21과 28은 각각 0xED, 0x95와 0x9C 에 대응하고, 0xED, 0x95와 0x9C를 결합한 0xED959C는 한글 '한'으로 디코딩된다. 숫자 64, 53과 45는 각각 0xEA, 0xB5와 0xAD에 대응하고, 0xEA, 0xB5와 0xAD를 결합한 0xEAB5AD는 한글 '국'으로 디코딩된다.
상기한 본 발명의 제8 실시 예에 따를 때, 형태 보존 암호화의 입력 문자열이 '64 48 0 65 2 24 65 11 36 65 29 60 67 21 28 64 53 45라면 형태 보존 암호화의 디코딩 과정에서 입력 문자열은 다음과 같이 디코딩된다.
'64 48 0 65 2 24 65 11 36 65 29 60 67 21 28 64 53 45'→" 가나다라한국"
상기에서 0~67 사이의 숫자는, 본 발명의 제8 실시 예에 따라, 연속된 세 개의 숫자에 각각 대응하는 세 개의 바이트가 결합된 3 바이트에 대응하는 한글 문자로 디코딩된다. 따라서, 총 18개의 숫자가 6개의 한글 문자로 변환되고, 변환 전후의 문자열 길이는 18 바이트로 동일하다. 종래 기술에서는, 18개의 숫자가 18개의 한글 문자로 각각 변환되므로, 변환 전후의 문자열 길이는 18 바이트에서 54 바이트로 늘어난다.
상기한 실시 예들에 따르면, 종래 기술에서 변환 전후의 한글 문자열 길이가 보존되지 않던 것과 달리, 본 발명에서는 변환 전후 한글 문자열의 길이가 보존되어, 형태 보존 암호화의 특성을 유지시킨다.
도 11은 본 발명의 실시 예에 따른 형태 보존 암호화에서 한글의 인코딩 방법을 나타낸 순서도이다.
도 11을 참조하면, 본 발명에 따른 인코딩 장치는 인코딩 방식이 Euc-kr 방식인지 Utf-8 방식인지 여부를 판단한다(1101).
인코딩 방식이 Euc-kr인 경우, 인코딩 장치는 입력 문자열이 한글만 포함하는지 여부를 판단한다(1103).
입력 문자열이 한글 이외에, 숫자, 영문 대소문자, 특수 문자 중 적어도 하나를 포함하는 경우, 인코딩 장치는 본 발명의 제1 실시 예에 따라 입력 문자열을 인코딩한다(1105). 즉, 인코딩 장치는, 영어 대소문자, 숫자, 특수 문자는 0~94의 숫자로 인코딩하고, 한글 문자는 한글 문자를 표현하는 두 개의 바이트를 각각 95~188의 숫자로 인코딩한다.
반대로, 입력 문자열이 한글만 포함하는 경우, 인코딩 장치는 본 발명의 제2 실시 에에 따라 입력 문자열을 인코딩한다(1107). 즉, 인코딩 장치는, 한글 문자에 대해서 한글 문자를 표현하는 두 개의 바이트를 각각 0~93의 숫자로 인코딩한다.
한편, 인코딩 방식이 Utf-8 방식인 경우, 인코딩 장치는 입력 문자열이 한글만 포함하는지 여부를 판단한다(1109).
입력 문자열이 한글 이외에, 숫자, 영문 대소문자, 특수 문자 중 적어도 하나를 포함하는 경우, 인코딩 장치는 본 발명의 제5 실시 예에 따라 입력 문자열을 인코딩한다(1111). 즉, 인코딩 장치는, 영어 대소문자, 숫자, 특수 문자는 0~94의 숫자로 인코딩하고, 한글 문자는 한글 문자를 표현하는 세 개의 바이트가 각각 95~162의 숫자로 인코딩한다.
반대로, 입력 문자열이 한글만 포함하는 경우, 인코딩 장치는 본 발명의 제6 실시 에에 따라 입력 문자열을 인코딩한다(1113). 즉, 인코딩 장치는, 한글 문자에 대해서 한글 문자를 표현하는 세 개의 바이트를 각각 0~67의 숫자로 인코딩의 숫자로 인코딩한다.
이후에, 인코딩 장치는, 인코딩된 숫자열을 암호화하여 암호문을 출력한다(1115).
도 12는 본 발명의 실시 예에 따른 형태 보존 암호화에서 한글의 디코딩 방법을 나타낸 순서도이다.
도 12를 참조하면, 본 발명에 따른 디코딩 장치는 디코딩 방식이 Euc-kr 방식인지 Utf-8 방식인지 여부를 판단한다(1201).
디코딩 방식이 Euc-kr인 경우, 디코딩 장치는 입력 문자열이 한글만 포함하는지 여부를 판단한다(1203).
입력 문자열이 한글 이외에, 숫자, 영문 대소문자, 특수 문자 중 적어도 하나를 포함하는 경우, 디코딩 장치는 본 발명의 제3 실시 예에 따라 입력 문자열을 디코딩한다(1205). 즉, 디코딩 장치는, 0~94의 숫자는 영어 대소문자, 숫자, 특수 문자로 디코딩하고, 95~188의 숫자는 연속되는 두 개의 숫자를 하나의 한글 문자로 디코딩한다.
반대로, 입력 문자열이 한글만 포함하는 경우, 디코딩 장치는 본 발명의 제4 실시 에에 따라 입력 문자열을 디코딩한다(1207). 즉, 디코딩 장치는, 0~93의 숫자에 대해서 연속되는 두 개의 숫자를 하나의 한글 문자로 디코딩한다.
한편, 인코딩 방식이 Utf-8 방식인 경우, 디코딩 장치는 입력 문자열이 한글만 포함하는지 여부를 판단한다(1209).
입력 문자열이 한글 이외에, 숫자, 영문 대소문자, 특수 문자 중 적어도 하나를 포함하는 경우, 디코딩 장치는 본 발명의 제7 실시 예에 따라 입력 문자열을 디코딩한다(1211). 즉, 디코딩 장치는, 0~94의 숫자는 영어 대소문자, 숫자, 특수 문자로 디코딩하고, 95~162의 숫자는 연속되는 세 개의 숫자를 하나의 한글 문자로 디코딩한다.
반대로, 입력 문자열이 한글만 포함하는 경우, 디코딩 장치는 본 발명의 제8 실시 에에 따라 입력 문자열을 디코딩한다(1213). 즉, 디코딩 장치는, 0~67의 숫자에 대해서 연속되는 세 개의 숫자를 하나의 한글 문자로 디코딩한다.
이후에, 디코딩 장치는, 디코딩된 숫자열을 역암호화하여 평문을 출력한다(1215).
도 13은 본 발명의 실시 예에 따른 본 발명의 실시 예에 따른 형태 보존 암호화에서 한글의 인코딩/디코딩 장치의 구성을 나타낸 블록도이다.
도 13을 참조하면, 본 발명에 따른 인코딩/디코딩 장치(1300)는 입력부(1301), 제어부(1303) 및 출력부(1305)를 포함하여 구성될 수 있다.
입력부(1301)는 암호화하고자 하는 입력 문자열을 입력받을 수 있다. 입력 문자열을 숫자, 영어 대소문자, 특수 문자, 한글 문자 중 적어도 하나로 구성될 수 있다.
제어부(1303)는 입력 문자열을 형태 보존 암호화 방식에 따라 암호화한다. 제어부(1303)는 본 발명에 따른 인코딩/디코딩 방법에 따라, 입력 문자열을 인코딩/디코딩하고, 그 결과물을 암호화한다. 제어부(1303)의 구체적인 인코딩/디코딩 방법은 상술한 바와 같다.
다양한 실시 예에서, 제어부(1303)는 논리적으로 인코더(1307) 및 디코더(1309)로 구성될 수 있다. 인코더(1307)는 본 발명의 제1, 제2, 제5, 제6 실시 예 중 어느 하나에 따라 입력 문자열을 인코딩한다. 디코더(1309)는 본 발명의 제3, 제4, 제7, 제8 실시 예 중 어느 하나에 따라 입력 문자열을 디코딩한다.
출력부(1305)는 제어부(1303)에 의하여 암호화된 암호문을 출력한다.
본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 다양한 수정 및 변형이 가능할 것이다. 그리고 본 명세서와 도면에 개시된 실시 예들은 본 발명의 내용을 쉽게 설명하고, 이해를 돕기 위해 특정 예를 제시한 것일 뿐이며, 본 발명의 범위를 한정하고자 하는 것은 아니다. 따라서 본 발명의 범위는 여기에 개시된 실시 예들 이외에도 본 발명의 기술적 사상을 바탕으로 도출되는 모든 변경 또는 변형된 형태가 본 발명의 범위에 포함되는 것으로 해석되어야 한다.
1300: 인코딩/디코딩 장치 1301: 입력부
1303: 제어부 1305: 저장부
1307: 인코더 1309: 디코더

Claims (10)

  1. 한글 문자를 포함하는 문자열을 암호화하는 방법으로서,
    상기 문자열 중 상기 한글 문자를 인코딩 방식에 따라 2바이트 또는 3바이트로 인코딩하는 단계;
    상기 2바이트의 상기 한글 문자 1개를 2 개의 1바이트 숫자에 대응시키거나, 또는 상기 3바이트의 상기 한글 문자 1개를 3 개의 1바이트의 숫자에 대응시키는 단계; 및
    상기 대응된 숫자로 구성되는 숫자열을 암호문으로서 출력하는 단계를 포함하고,
    상기 숫자열의 바이트는 상기 문자열의 바이트와 동일한, 암호화 방법.
  2. 제1항에서,
    상기 인코딩하는 단계는, 상기 한글 문자를 Euc-kr 방식에 따라 상기 2바이트로 인코딩하고,
    상기 대응시키는 단계는, 상기 2바이트의 각각의 바이트를 95와 188 사이의 숫자에 각각 대응시키는, 암호화 방법.
  3. 제2항에서,
    상기 대응시키는 단계는,
    상기 문자열에 한글 문자만 포함될 때, 상기 2바이트의 각각의 바이트를 0과 93 사이의 숫자에 각각 대응시키는, 암호화 방법.
  4. 제1항에서,
    상기 인코딩하는 단계는, 상기 한글 문자를 Utf-8 방식에 따라 상기 3바이트로 인코딩하고,
    상기 대응시키는 단계는, 상기 3바이트의 각각의 바이트를 95와 162 사이의 숫자에 각각 대응시키는, 암호화 방법.
  5. 제4항에서,
    상기 대응시키는 단계는,
    상기 문자열에 한글 문자만 포함될 때, 상기 3바이트의 각각의 바이트를 0과 67 사이의 숫자에 각각 대응시키는, 암호화 방법.
  6. 한글 문자를 포함하는 입력 문자열의 암호문을 디코딩하는 방법으로서,
    상기 암호문을 복호화하여 숫자열을 출력하는 단계;
    상기 숫자열을 구성하는 적어도 하나의 연속된 2개 또는 연속된 3개의 1바이트 숫자를 2바이트 또는 3바이트의 한글 문자로 각각 디코딩하는 단계; 및
    상기 디코딩된 한글 문자를 포함하는 문자열을 출력하는 단계
    를 포함하고,
    상기 문자열의 바이트는 상기 숫자열의 바이트와 동일한, 디코딩 방법.
  7. 제6항에서,
    상기 암호문은, 상기 입력 문자열을 구성하는 2바이트의 한글 문자를 각각의 바이트마다 95와 188 사이의 숫자에 각각 대응시켜 2개의 숫자로 인코딩한 결과를 암호화한 것이고,
    상기 디코딩하는 단계는,
    상기 연속된 2개의 숫자를 상기 2바이트의 한글 문자로 디코딩할 때,
    상기 연속된 2개의 숫자를 0xA1과 0xFE 사이의 바이트에 각각 대응시켜 2 바이트의 한글 문자로 변환하는, 디코딩 방법.
  8. 제6항에서,
    상기 암호문은, 한글 문자만을 포함하는 상기 입력 문자열의 2바이트의 한글 문자를 각각의 바이트마다 0과 93사이의 숫자에 각각 대응시켜 2개의 숫자로 인코딩한 결과를 암호화한 것이고,
    상기 디코딩하는 단계는,
    상기 연속된 2개의 숫자를 상기 2바이트의 한글 문자로 디코딩할 때,
    상기 연속된 2개의 숫자를 0xA1과 0xFE 사이의 바이트에 각각 대응시켜 2 바이트의 한글 문자로 변환하는, 디코딩 방법.
  9. 제6항에서,
    상기 암호문은, 상기 입력 문자열을 구성하는 3바이트의 한글 문자를 각각의 바이트마다 95와 162 사이의 숫자에 각각 대응시켜 3개의 숫자로 인코딩한 결과를 암호화한 것이고,
    상기 디코딩하는 단계는,
    상기 연속된 3개의 숫자를 상기 3바이트의 한글 문자로 디코딩할 때, 상기 연속된 3개의 숫자가 각각 95부터 158 사이의 숫자이면 상기 연속된 3개의 숫자를 0x80과 0xBF 사이의 바이트에 각각 대응시켜 3바이트의 한글 문자로 변환하고,
    상기 연속된 3개의 숫자가 각각 159와 162 사이의 숫자이면 상기 연속된 3개의 숫자를 0xEA와 0xED 사이의 바이트에 각각 대응시켜 3바이트의 한글 문자로 변환하는, 디코딩 방법.
  10. 제6항에 있어서,
    상기 암호문은, 한글 문자만을 포함하는 상기 입력 문자열의 3바이트의 한글 문자를 각각의 바이트마다 0과 67사이의 숫자에 각각 대응시켜 3개의 숫자로 인코딩한 결과를 암호화한 것이고,
    상기 디코딩하는 단계는,
    상기 연속된 3개의 숫자를 상기 3바이트의 한글 문자로 디코딩할 때, 상기 연속된 3개의 숫자가 각각 0과 63사이의 숫자이면 상기 연속된 3개의 숫자를 0x80과 0xBF 사이의 바이트에 각각 대응시켜 3바이트의 한글 문자로 변환하고,
    상기 연속된 3개의 숫자가 각각 64와 67 사이의 숫자이면 상기 연속된 3개의 숫자를 0xEA와 0xED 사이의 바이트에 각각 대응시켜 3바이트의 한글 문자로 변환하는, 디코딩 방법.

KR1020150020138A 2015-02-10 2015-02-10 형태 보존 암호화에서 한글의 인코딩 및 디코딩 방법 및 그 장치 KR102173677B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020150020138A KR102173677B1 (ko) 2015-02-10 2015-02-10 형태 보존 암호화에서 한글의 인코딩 및 디코딩 방법 및 그 장치

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020150020138A KR102173677B1 (ko) 2015-02-10 2015-02-10 형태 보존 암호화에서 한글의 인코딩 및 디코딩 방법 및 그 장치

Publications (2)

Publication Number Publication Date
KR20160097811A KR20160097811A (ko) 2016-08-18
KR102173677B1 true KR102173677B1 (ko) 2020-11-03

Family

ID=56874289

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020150020138A KR102173677B1 (ko) 2015-02-10 2015-02-10 형태 보존 암호화에서 한글의 인코딩 및 디코딩 방법 및 그 장치

Country Status (1)

Country Link
KR (1) KR102173677B1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114866487B (zh) * 2022-03-08 2024-03-05 国网江苏省电力有限公司南京供电分公司 一种海量电网调度数据采集与存储系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100480065B1 (ko) * 2002-10-15 2005-03-31 엘지전자 주식회사 컬러 단문 메시지 전송 방법
JP2006221656A (ja) * 2005-02-11 2006-08-24 Fujitsu Ltd データ文書の高速符号化方法及びシステム
JP2007065253A (ja) * 2005-08-31 2007-03-15 Fujitsu Broad Solution & Consulting Inc 文字コード暗号処理プログラム、および文字コード暗号処理方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20100021817A (ko) * 2008-08-18 2010-02-26 주식회사 케이티테크 텍스트 데이터 압축 방법

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100480065B1 (ko) * 2002-10-15 2005-03-31 엘지전자 주식회사 컬러 단문 메시지 전송 방법
JP2006221656A (ja) * 2005-02-11 2006-08-24 Fujitsu Ltd データ文書の高速符号化方法及びシステム
JP2007065253A (ja) * 2005-08-31 2007-03-15 Fujitsu Broad Solution & Consulting Inc 文字コード暗号処理プログラム、および文字コード暗号処理方法

Also Published As

Publication number Publication date
KR20160097811A (ko) 2016-08-18

Similar Documents

Publication Publication Date Title
US7821427B2 (en) Data processing system and method
US20090274294A1 (en) Data compression apparatus and data decompression apparatus
US20180253559A1 (en) Secured lossless data compression using encrypted headers
CN101996298A (zh) 加密方法及与加密方法相对应的解密方法
CN111259414A (zh) 一种文件存储为音频实现加密的方法、装置和设备
Dheemanth LZW data compression
JP2013097338A (ja) 暗号化プログラム、復号化プログラム、暗号化方法、復号化方法、システムおよびコンテンツの生成方法
Wen et al. Research on base64 encoding algorithm and PHP implementation
US20190036543A1 (en) A Method of Protecting Data Using Compression Algorithms
CN109923516A (zh) 加强计算机安全性,可变字长编码以及可变长码解码的技术
KR102173677B1 (ko) 형태 보존 암호화에서 한글의 인코딩 및 디코딩 방법 및 그 장치
Nandi et al. Modified compression techniques based on optimality of LZW code (MOLZW)
KR101445339B1 (ko) 기밀성과 무결성을 제공하는 통합 암호화 장치 및 그 방법
US8077868B2 (en) Mechanism for transport-safe codings for cryptographic use
US8018359B2 (en) Conversion of bit lengths into codes
CN106817216A (zh) 一种基于Zlib库和AES算法的ZIP包解压方法
Shanmugasundaram et al. IIDBE: A lossless text transform for better compression
KR101428650B1 (ko) 암호화 방법 및 복호화 방법
Ramesh et al. An indirect encryption using compression with random bit stuffing
Kadhem et al. Proposed Data Coding Method
US8452005B2 (en) Unicode-compatible encipherment
Kim et al. Encoding of Korean characters with less radix in format-preserving encryption
Sankar et al. A Comparative Study: Data Compression on TANGLISH Natural Language Text
US7999705B2 (en) Unicode-compatible base-N range coding
US20110128168A1 (en) Unicode-compatible entropy coding

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant