aes 알고리즘 : 128 이중 암호화 vs 256 한번 암호화 -> 뭐가 더 강력할까요?

wonjnlee의 이미지

aes를 이용하여

128비트로 두번 암호화한 내용과
256비트로 한번만 암호화한 내용 중
어떤 것이 더 강력할까요?

익명 사용자의 이미지

암호학에 대해서 잘 모르신다면 무조건 후자입니다.

과거 DES가 쓰이던 시절에는 키 길이가 최대 56비트밖에 되지 않았고, 알고리즘 자체를 손대는 대신 임시 땜빵용으로 키 A로 암호화 - 키 B로 복호화 - 키 C로 다시 암호화하는 3DES를 썼습니다. 키를 어떻게 관리하느냐에 따라서 실질적인 비트 수는 달라지죠. 가령 A=B=C라면 실질적으로 56비트 DES와 차이가 없는데 시간만 세 배로 불어나며, A=C일 때에는 키는 112비트짜리죠. 그러나 Meet-in-the-middle 때문에 실질적인 키 비트 수는 이것보다 더 줄어듭니다.

질문하신 분의 상황도 키 A와 키 B가 서로 같다면 결국 128비트짜리 AES와 동일합니다. 앞서 말한 공격 때문에 128비트 AES를 두 번 돌리는 것이 256비트와 동등하다는 보장은 할 수 없으며, 도리어 제대로 된 256비트 AES만 못한 성능이나 안정성이 나올 수도 있습니다.

유명한 격언이 있습니다: https://motherboard.vice.com/en_us/article/why-you-dont-roll-your-own-crypto

wonjnlee의 이미지

답변 감사합니다.
제가 비교하고자 한 내용은
1. 128 이중 암호화 : 서로 다른 값을 갖는 두개의 키로 두번 암호화
2. 256 단일 암호화 : 단순히 하나의 키값으로 한번 암호화
입니다.

암호학에 대해 잘 몰라서..
그렇다면 결론적으로 256 한번이 더 빠르고 안전하다는 말씀이신가요?
전 두번 복호화하는 과정이 더 복잡할거라 생각해서...

 의 이미지

대개의 경우, 128 단일 암호화만 가지고도 충분합니다.

http://csrc.nist.gov/groups/ST/toolkit/documents/aes/CNSS15FS.pdf
2003년의 CNSS Policy에 따르면 SECRET level까지는 AES 128만으로 충분하고, TOP SECRET은 AES 192 혹은 AES 256을 쓰라고 나와 있군요.

그럼에도 불구하고 AES 128 가지고는 만족을 못 하시겠다면, 보안 시스템의 강도는 가장 약한 요소에 의해 결정된다는 사실을 유념할 필요가 있습니다. 그리고 그 약한 요소는 대개의 경우 암호화 알고리즘이 아닙니다.

암호화 키를 부주의하게 다루거나, 부적절한 mode of operation을 사용하거나, 암호화 시스템을 이루는 소프트웨어에 취약점이 있거나 하는 게 대체로 보안을 약화시키는 결정적인 요소이지요. 저 학부 때 암호론 교수님께서는 반쯤 농담으로 "cryptoanalysis 방법은 다양하게 있지만 가장 practical하고 싸게 먹히는 방법은 key buying attack이다. 암호화 키를 아는 놈을 매수하는 거지. 슈퍼컴퓨터로 암호를 깨는 비용보다 훨씬 싸게 먹힌다"고 말씀하시곤 했지요. 실제로 보안 시스템의 가장 약한 요소가 사람인 경우가 드물지 않게 있어요. 강의 시간에 언급하기에는 다소 부적절하지만, 조금 더 형량이 센 위법행위라도 저지를 수 있다면 Rubber-hose cryptanalysis를 이용할 수도 있지요.

https://xkcd.com/538/

https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis

그런 경우에는 AES 128을 단일에서 이중으로 적용하거나 AES 256으로 업그레이드하는 일 따위로는 보안을 조금도 강화하지 못한다는 말씀입니다. 그저 눈에 띄는 숫자에만 주목하는 스펙놀음일 뿐이죠. 실제로 안전한 보안 시스템을 구성하는 건 소위 전문가들에게도 쉬운 일이 아니고, 상당한 시간과 노력을 들여 검증을 거쳐야 하는 문제입니다.

가장 쉬운 방법은 그냥 널리 알려져 검증을 거친 오픈소스를 가져다 쓰세요. openpgp 같은 것 있잖아요. 그럼에도 불구하고 어떻게든 직접 구현하셔야겠다 싶으시면, 최소한 AES를 쓰실 때는 mode of operation 정도는 아셔야 합니다.

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

tyhan의 이미지

안전성은 같고 성능은 256이 더 빠릅니다.
키 길이도 결국 128*2, 256으로 같으니 128을 두번 사용할 이유가 없습니다.

간혹 256을 쓸 수 없는 환경(추가 라이브러리를 설치할수 없는 환경등)에서는
두번 하는것을 사용할수는 있을 것 같습니다.

ymir의 이미지

암호에서 취약성은, 암호 알고리즘 그 자체보다는 키 관리에 있습니다.
키가 유출되지 않은 상태라면, 암호 알고리즘 자체를 깨기는 무척 어렵다는 거죠.

따라서 일반적으로 성능과 안전성을 고려하여 적절한 알고리즘 하나를 선정하면 됩니다.
암호 알고리즘 측면에서 두 번 encrypt 하는 건 별 의미 없죠.

암호 알고리즘이 아닌, 내 데이터 보호의 관점에서 봤을 때..
데이터 보호 알고리즘 자체를 감추는 것도, 보안성을 높이는 방법 중의 하나이긴 합니다.
원래라면 key 와 algorithm + key length + mode 만 알아내면 되는데...
거기에 encrypt 를 몇 번 돌렸는지도 알아내야 하니까요.

그런데 2번 encrypt 했다는 내용이 공개되면, 결과적으로 한 번이나 두 번이나 차이가 없어지게 되죠.
거기다가 이 옵션을 위해 가장 비싼 encrypt 를 한 번 더 수행하게 되니.. 비용대비 효과는 최악입니다.

상대적으로 안전하냐 아니냐는..
이 알고리즘을 공개했을 때에도 그 안전성이 유지되느냐의 관점으로 보시면 됩니다.

되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Mizz 』

wonjnlee의 이미지

중요한 것은

1. 결국 키를 알게 되면 한번하나 두번하나 위험한 것은 똑같다.
2. 키를 알고 있는 사람을 데려다가 고문(?)하면 몇번을 꼬아내던 상관없다.

이런 원리가 되겠군요 ㅋㅋㅋㅋㅋ
사실 암호화 하는 과정이 너무 비싸다는 것은 저도 인정합니다. 두번 암호화하게 되면 실질적으로 암호하는데만 걸리는 시간이 엄청 늘어나더군요.
(그래봤자 밀리세컨드 단위지만, 그래도 전체적인 크기로 보면 꽤 중첩이 심하더군요)

정리하면 128 두번보다는 256 한번이 훨씬 효율적이다 이 말씀이신가요?
사실 효율적보다는 데이터가 얼마나 견고하냐가 더 중요하긴 합니다만..

 의 이미지

Double AES128이나 AES256이나 현재 수준에서 알려진 가장 효과적인 cryptoanalysis, 실용적으로 동원 가능한 컴퓨팅 자원 및 시간 안에 뚫릴 염려는 전혀 없습니다.

물론 근미래에 수학(계산 이론, 알고리즘, etc), 물리(열역학, etc) 및 기타 공학 분야에서 지금으로선 상상조차 못 할 수준의 breakthrough가 일어난다면, 얘기가 달라지겠죠.

그런 일이 일어나고 난 뒤에 무슨 일이 생길지 어떻게 예측할 수 있겠습니까.

AES128이라도 제대로 구현하고, 제대로 사용한다면(mode of operation 등) 귀하의 보안 시스템의 취약점은 최소한 암호화 알고리즘에 있지는 않을 겁니다.

이제는 안전하지 않다고 여겨지는 56-bit DES의 cryptoanalysis에 대해 조사해보세요. 현재까지 발견된 최선의 알고리즘조차 거의 2^40에 이르는 known plaintext를 필요로 합니다. 이런저런 이유로 known plaintext가 조금씩 유출되는 거야 어쩔 수 없는 일이긴 한데, 문자 그대로 수 테라바이트씩 유출되어 공격에 활용되는 상황이 과연 현실적인가요? 그럼에도 보안 시스템에서 DES는 퇴출되었지요...

대체 얼마나 엄중한 비밀이길래 AES128로도 만족을 못 하셔서 Double AES128이나 AES256 같은 걸 고려하고 계시는지 모르겠는데, AES128을 직접 깨기 위해 필요한 것보다 훨씬 적은 비용으로 아래와 같은 공격들을 무난히 시도해 볼 수 있을 겁니다.

1. 암호화 키가 생성, 전달 및 사용되는 과정에서 해킹이나 기타 물리적 접근으로 키를 추출.
2. 데이터가 암호화되기 직전, 혹은 복호화된 직후에 해킹이나 기타 물리적 접근으로 데이터를 추출.
3. 권한 있는 사용자를 매수하거나 기타 위력을 동원하여 키 혹은 데이터를 유출하게 함.

등등. 비록 불법적이지만 상당한 자금을 투입하면 현실화될 수 있는 공격들에 대해서는 충분히 대비를 하고 계시겠지요?

민감한 데이터를 다루는 컴퓨터는 아예 인터넷에 연결되어 있지도 않게 안전한 인트라넷을 구성하고, 자격 없는 사람이 여기에 물리적으로 접근하는 걸 막으려면 경비체계를 구성해야 할 겁니다. 부주의한 관리자가 패스워드 따위를 모니터 옆에 써붙여놓는다던가 하지는 않는지 주의해야 하고, 혹시 매수당하거나 협박당하거나 하는 일이 없도록 신변에도 만전을 기울여야겠죠. 돈이 좀 들겠지만 꼭 지켜야 할 비밀이라면 어쩔 수 없지요.

쓸데없이 너무 오버하는 것 같다고 생각하시나요?
Double AES128이나 AES256을 쓰겠다고 하시는 귀하의 말씀도 제게 그렇게 들립니다. :(

wonjnlee의 이미지

답변 감사드립니다! 아, 물론 전혀 쓸데없이 오버한다고 생각되지도 않습니다.
제가 궁금한 이유는, 단순히 이중으로 암호화 하면 과연 얼마나 효과가 있을지에 대한 궁금함 때문이었습니다.
대학원 시절에 컴퓨터 보안 과목을 들으면서도 그랬고, '하나의 암호를 풀면 또 다른 새로운 암호가 있다면 얼마나 강력할 수 있을까?'에 대한 질문이 늘 있었거든요.
다만 256의 경우 키가 2배이기는 하지만, 한번의 암호화만 풀면 평문이 존재할 수 있을텐데 그럼에도 얼마나 더 견고할까?하는 궁금함 때문이었습니다.

엄중한 비밀이나 불만족보다는 단순히 궁금함을 해결하기 위한 질문이라고 생각해주시면 감사하겠습니다.

ymir의 이미지

일단 암호 알고리즘 측면에서는 aes-128 과 같기 때문에, 별 의미 없다고 설명드렸고..

데이터 보호의 관점에서 보면..
두 번 다 동일한 키를 사용한다면, '두 번' 했다는 사실을 감출 수 있는 만큼만 안전할 테고..
서로 다른 키를 이용한다면, 두 개의 암호키를 모두 입수해야 하는 비용이 추가되는 정도인데..
두 개의 암호키를 같은 패턴으로 관리한다면 역시나 무의미한 상황이죠.

결과적으로 서로 다른 두 개의 암호키를 다른 패턴으로 관리하는게 아니라면..
두 번이라는 사실을 감출 수 있는 정도 만큼은 안전하겠네요.

decrypt 한 번으로 원본을 내주는게 불안한 상황이라, encrypt 한 번 더 추가하신 거라면..
암호화 하기 전에 특정 패턴으로, 워터 마크처럼 xor 로 마스크를 씌웠다고 해 봅니다.
해킹하는 쪽에서는 decrypt 이후에, '어떤 패턴' 으로 마스크를 씌웠는지 패턴을 입수해야 합니다.
패턴은 PSK 나 암호처럼 '고정된 값'을 쓸 수도 있지만, '특정한 공식'으로 생성할 수도 있겠죠.

오히려 암호화 두 번 보다 알아내야 할 게 많으니, 오히려 난이도는 올라가겠죠.

각설하고, 다시 정리하자면..
암호 알고리즘 별로 성능이나 암호 강도가 조금씩 차이가 있기는 하지만..
알고리즘 자체의 난이도는 현 컴퓨팅 파워로는 충분히 안전한 상태라고 보시면 됩니다.

여전히 핵심은 키 관리에 있고, 이 키를 얼마나 안전하게 관리하느냐에 따라 안전성 여부가 갈립니다.
데이터를 좀 더 꼬아놓고, 그 사실을 비밀로 감추느라 시간을 투자하는 것보다는..
먼저 키를 어떻게 관리할 것인지에 집중하는게 좀 더 도움이 될 것 같습니다.

decrypt 한 번에 원본을 내줬다는 상황은, 이미 키가 유출된 상황과 같거든요.

되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Mizz 』

 의 이미지

흠.

다른 모든 문제를 제끼고, 순수히 학문적 측면에서 두 암호화 알고리즘을 비교해 보라는 말씀이신가요.

짧게 답해드리지요. 모릅니다.

상식적으로 생각해보세요. 암호화 알고리즘이 왜 암호화 알고리즘이라고 불리겠습니까.
키를 모르는 상황에서 키를 알아내거나 암호문을 복호화해내거나 하는 일이 엄청 어렵기 때문에 그렇습니다.
바꿔 말하면, 그런 문제를 효율적으로 풀어내는 방법을 인류가 아직 찾지 못했습니다.
(최소한 제가 아는 바로는 그렇습니다. 미국 정보기관 깊숙한 어딘가에는 있을지도 모르지요. 근데 알 게 뭡니까.)

우리는 알려진 풀이에 대해서는 어떤 풀이가 다른 풀이보다 더 간단하다거나 적은 비용을 필요로 한다던가 하는 식으로 평가할 수 있습니다.
그런데 풀지 못한 문제 두 개를 가지고 어느 쪽이 더 어렵다느니 쉽다느니 말할 수 있는 건가요?
과거의 몇몇 저명한 수학자들도, 당대에 풀리지 않은 수학 난제들의 난이도를 잘못 예측하는 경우가 제법 있었어요.

좀 더 쉬운 예를 들어 설명해 드리죠. P 문제는 NP-complete 문제보다 쉬울까요?
왠지 그럴 것만 같지만 사실 이 질문조차 답할 수가 없지요. 그게 바로 그 유명한 난제 P=NP 문제 아니겠습니까.

일반론적인 이야기는 여기까지 하고, 구체적으로 들어가 보죠.

Quote:
대학원 시절에 컴퓨터 보안 과목을 들으면서도 그랬고, '하나의 암호를 풀면 또 다른 새로운 암호가 있다면 얼마나 강력할 수 있을까?'에 대한 질문이 늘 있었거든요.

대학원 수준 컴퓨터 보안 과목을 수강하면서 meet-in-the-middle(이하 MitM) 공격에 대해서 못 들어보셨다는 건 저로서는 좀 의아한 일입니다. 어쩌면 배우셨는데 지금 기억을 못 하시는 것일 수도 있죠. 강의 자료 남겨두셨나요? 아마도 DES하고 AES 사이에 Triple DES 다루면서 살짝 짚고 넘어갔을텐데요.

물론 Double DES는 분명히 MitM 공격에 취약합니다만, 사실 생각해보면 이 공격을 시도하는 게 과연 얼마나 이득을 주는지는 다시 생각해 볼 여지가 있습니다. MitM 공격은 원래 시간과 (스토리지) 공간을 교환하는 방식으로 동작하지요. 2^112 DES 계산이 필요한 brute force attack(이하 bfa) 대신 2^57의 DES 계산과 2^56개의 DES block을 저장할 수 있는 스토리지가 필요하다는 말씀입니다.

스토리지 요구량을 대충 셈해도 최소 2^62 byte입니다. 4 exabyte 정도 되는군요. 2011년에 전세계 데이터 스토리지 용량이 295 exabyte쯤 되었다고 합니다만, 지금쯤은 훨씬 더 늘었겠죠. 각국 정보기관이나 IT 대기업 등 대규모 IT 인프라를 운영할 역량이 되는 집단이라면 아마 어떻게 해 볼 수도 있을 텐데요. 뭐 솔직히 제가 그렇게 대단한 사람은 아닌지라 그런 집단에서 엄청난 비용을 들여서 캐낼 만한 가치가 있는 비밀을 갖고 있진 않지만, 글쎄요. 물론 누군가는 가지고 있겠죠.

사정이 이러니, Double AES128쯤 되면 아무리 MitM 공격이 가능하다고 한들 당분간은 큰 문제가 없을 거라고 예측해도 큰 무리는 아닐 겁니다. 같은 방법으로 계산해 보면 2^135 byte의 스토리지와 2^129의 AES 계산입니다. 계산량은 둘째치고 저 정도 규모의 스토리지가 어떤 방법으로든 지구상에 구현될 날이 과연 언제 올지 궁금하네요.

물론 그렇다고 해도, 이론상으로나마 그런 공격이 가능한 Double AES128보다는 아직 그런 종류의 공격이 가능한지조차 알려지지 않은 AES256이 현재로선 더 안전해 보이지 않는가, 하는 기대를 가질 수는 있겠습니다.

뿐만 아니라 AES256을 쓰는 게 Double AES128을 쓰는 것보다 더 안정적일 거라고 기대할 수 있는 이유가 하나 더 있습니다. AES256은 애초에 256-bit key를 가지고 쓰라고 만든 완제품이지요. 그 반면 Double AES128은 128-bit key를 가지고 쓰라고 만든 물건을 비전문가가 임의로 조립해서 만든 거에요.

물론 경우에 따라서는 임기응변으로 조립해서 만든 물건을 써야만 하는 경우도 있습니다. 하지만 애초에 용도에 딱 맞게 만들어져 나온 완제품이 있으면, 애써 그걸 피할 이유가 어디 있겠습니까. 특히나 보안처럼 오랜 시간과 노력을 들여 검증을 거쳐야 하는 분야에서 말이죠.

Aegas의 이미지

옛날에 DES라는 블록암호 표준이 있었는데, 그게 키 길이가 너무 작아서 안전성에 문제가 있었죠. 그래서 키 길이를 늘이기 위해 나온 아이디어가 여러번 다른 키로 암호화하는 겁니다. 실제로 표준으로 채택된 것은 triple DES, 즉, 3번 암호화하는 건데, 두 번 짜리가 채택되지 않은 이유는, 두 번 다른 키로 암호화하는 경우 meet-in-the-middle 공격이 하나 있어서 실질적인 키 길이가 두 배로 늘어나지 않기 때문입니다. 실질적으로는 키 길이가 한 비트 정도 더 늘어나는 선에서 그칩니다. 암호학 교과서들을 찾아보면 대체로 있는 얘깁니다.

AES라고 해도 이야기는 그리 다르지 않습니다. 기본적으로는, AES128을 두 번 반복하는 것은 별 의미가 없고 그냥 AES256을 쓰는 것이 낫습니다,

ㅇㅇ의 이미지

시간이 좀 된 질문이긴 한데.. 제가 생각하는 답변이 안보여서 답변드립니다.

첫째로 살펴볼 점은 암호화 알고리즘의 보안성을 고려할 때는 암호화 알고리즘 자체는 일반적으로 공개된다는 전제하에 계산됩니다. 따라서 공격자는 암호화 알고리즘 즉, AES128를 2번 사용했다는 걸 이미 공격전에 인지하고 있다는 가정이 필요합니다.


위의 사실은 인지 한 상태에서, AES-128을 사용한 메세지에 무차별 대입법을 사용한 키복구 공격을 하려면 필요한 계산력은 약 2^128입니다. (실제로는 2^126 정도에 푸는 알고리즘이 있다고 합니다) AES-128을 2번 사용한걸 공략하려면 결과적으로 연산에 2배의 시간이 걸리므로 단순계산으로 보안성이 최대 2배까지 증가할 수 있습니다.

반면 같은 방법으로 AES-256를 공략하기 위해서는 약 2^256의 계산력이필요합니다. 즉 수학적으로만 따져봤을때 AES-128를 100번 하던 1000번하던 AES-256 한번이 훨씬 더 강력 합니다.

"다만 256의 경우 키가 2배이기는 하지만, 한번의 암호화만 풀면 평문이 존재할 수 있을텐데 그럼에도 얼마나 더 견고할까?하는 궁금함 때문이었습니다."
-> AES-256을 공략해서 평문을 한번 얻는게 AES-128보다 훨씬 어렵기 때문에 이론상 전혀 걱정할 이유가 없습니다. (약 2의 128승배 어렵습니다.)

다만 위의 계산은 무차별 대입법을 기준으로 보안성을 계산한 것이고, AES 알고리즘을 공략하는 다른 방법이 존재할 수있습니다. 예를들면 AES 알고리즘을 대상으로 하는 연관키 공격이라는게 있습니다. 키를 생성하는 키 스케쥴러를 공략하는 방법으로 이건 오히려 키 길이가 길 수록 공격에 더 취약합니다. 어쨌든 위에 답변이 달린것 처럼 알고리즘을 직접 공략하는 방법이 발견이 아직 안된 것일 뿐, 직접 공략하는 방법이 없다고 증명된게 아니기 때문에 답변은 오직 "현재까지 알려진 공략법"에 근거하는 수밖에 없습니다.

수학적인 것보다 보다 현실적인 답변으로는, AES 알고리즘 자체를 공략하는건 불가능하고 AES 키 길이보다는 키 보관 따위가 더 중요하다는 것이죠. 그런 의미에서 AES-128로 2번 암호화 시키는게 의미가 있을 수는 있습니다. 실제로 미 국가안보국에서는 통신에 암호화를 두번씩 합니다. 같은 알고리즘을 두번 연속 적용하는 것은 아니고, 서로 다른 알고리즘을 서로 다른 레이어에서 적용하도록 되어있습니다.

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.