대칭키
서버와 클라이언트가 같은 키를 사용. 클라이언트에서 암호화한 키를 서버에서 똑같이 사용하여 복호화한다.
문제점?
서버와 클라이언트가 어떻게 같은 키를 가지게 할 것인가가 문제다. 만약 클라이언트에서 서버로 암호키를 전송한다면, 중간에 패킷 스니핑 등으로 해당 암호키를 탈취하면 보안의 의미가 없어진다.또한 서버가 클라이언트와 통신을 할 때 각각의 클라이언트에 대해 각각의 대칭키를 가지게 되면 키의 개수가 급증한다.
비대칭키 (공개키)
A키로 암호화하고, B키로 복호화한다. 개인키로 암호화 한 정보는 그 쌍이 되는 공개키로만 복호화가 가능하고, 공개키로 암호화한 정보는 그 쌍이 되는 개인키로만 복호화가 가능하다. 예를 들어, 네이버는 개인키를 보유하고, 공개키를 클라이언트(유저)들에게 공개한다. 유저는 해당 공개키로 암호화를 하여 네이버 서버에 데이터를 전송한다. 공개키로는 해당 암호문을 해독할 수 없기 때문에 개인키를 가진 네이버만 복호화가 가능하다. 또한 네이버가 유저에게 전송하는 데이터 중 일부는 네이버의 개인키로 암호화되며, 이는 공개키로 해독 가능하다. 따라서 해당 암호화된 데이터가 해독가능하다면 네이버 공식사이트로 인지할 수 있고, 해독 불가능하다면 네이버 피싱 사이트 등 다른 사이트임을 알 수 있어서 보안을 유지 가능하다.
HTTPS
https는 최초 접속 시 공개키-개인키 방식, 즉 비대칭키 방식으로 데이터를 주고 받는다. 그러나 비대칭키는 성능적으로 큰 오버헤드를 유발하기 때문에 이후 통신에는 대칭키를 사용한다. 이러한 대칭키를 공유할 때 비대칭키를 사용하기 때문에 기존 대칭키 스니핑 등으로 인한 문제점은 해결 가능하다.
