Signal은 정말 훌륭한 암호화 논문을 계속 발표함에도 불구하고, 제품 관점에서는 무엇이 성공할지 몰라 이것저것 시도하는 느낌임. 포스트양자 핸드셰이크, 스토리, 머니 트랜스퍼 등 새로운 시도를 시도하고 있지만, 여전히 SDK, API, 봇 지원이 부재함. 공식 라이브러리도 미완성에다가 문서도 없음. 기능이 여전히 많은 부분 클라이언트에 숨어있음. 프로토콜 명세를 공개해 놓긴 했지만, 그걸로 직접 라이브러리 만들라고 하는 건 실제 제품 운영 방법과 완전히 동떨어진 무책임한 태도임. 수백만 명이 사용하는 플랫폼에 이 정도 기본이 안 되어 있음. WhatsApp, iMessage 같은 앱들은 개발자에게 뭐라도 열어주는데 Signal은 개발자 관련은 철저히 배제하는 분위기임. 제품 담당자가 없는 게 아닐까 싶을 정도로 명확한 전략을 찾아볼 수 없음. 오랜 Signal 사용자이자 적극적으로 홍보도 해왔던 입장에서는, Signal이 뜨거운 암호화 기술을 덕지덕지 붙인, 애플 생태계보다도 개발자에 더 닫힌 메신저로 느껴짐. 그럼에도 제품 만든 분들에겐 감사함
공감함. 특히 "스토리" 기능은 정말로 뭐가 될지 그냥 던져보는 느낌이 확 들었음. Signal이 아나키즘을 지향하는 비영리 단체 출신이라 목표 자체가 보통 회사와 다르다고 생각함. 앱이 본연의 임무엔 충실하니 괜찮지만, SDK가 있으면 정말 좋을 것 같음
API나 비즈니스 봇 같은 기능이 정말 중요한지 궁금함. WhatsApp, iMessage는 비즈니스용 API가 있지만, 일반 사용자로서는 실제로 그걸로 비즈니스와 상호작용한 적이 없음. 대신 가끔 봇이 귀찮게 하는 경험만 있었음. Signal에서 진짜 문제는 앱이 조용히 구버전이 되거나 업데이트가 멈추면 알림을 안 주고 메시지를 완전히 놓치는 상황임. 메신저의 핵심 미션인데 그게 안 됨
오히려 API랑 봇이 없다는 게 나에겐 오히려 장점임
나는 그런 기능 없이 지금처럼 안전하고 쓸 만한 메신저 만드는 데 집중해줬으면 좋겠음
내가 Signal에서 정말 짜증나는 건, 발신자가 듣는 링 소리가 실제 수신자 폰에서 울리지 않아도 들린다는 점임. 예전부터 일부러 이렇게 하고 있다며 방어해 온 공식적인 정책임. 예전의 잠수함 사운드 없앤 이후로 계속 이러고 있음
Signal 프로토콜 이름이 SPQR라서 깜짝 놀랐음. SPQR는 라틴어로 "Senatus Populusque Romanus"의 약자임 위키피디아 참고. 너무 멋짐
미래 지향적인 프로토콜 이름에 SPQR을 사용한 건 오지맨디아스(Ozymandias) 같은 느낌이 있음
아주 영리한 작명임. BBC 미니시리즈 "Rome"에서 로마 군단병 문신으로 자주 나온다고 익히 알고 있음 Rome 위키피디아
Strength and Honor(강인함과 명예)
이런 유머는 Hacker News에서만 볼 수 있다고 생각함. 예전에 "수학자가 자기 사물함 번호를 외우는 법"을 다룬 만화가 떠오름. ("1975? 그건 3,900,625의 제곱근이지!")
혹시 그냥 "SPQR"이 "Speaker"처럼 들리니까 채팅앱과 어울려서 그렇게 지은 건 아닐까? 모든 걸 로마와 엮을 필요는 없음
Signal의 가장 큰 약점은 전화번호로 신원을 구분하는 방식임. 해커뿐 아니라 권위주의 정부 입장에서도 언제든 전화번호를 탈취할 수 있음. 미래의 위협을 고민하는 것도 중요하지만 우선순위가 바뀌어야 함
많은 보안 메신저들이 전화번호 없이도 돌아가고, 메타데이터까지 지워가며 서비스를 제공하고 있음. 전화번호와 SIM카드가 개인에게 묶이는 국가에서는 Signal의 방식이 진입장벽임
전화번호 요구는 스팸 방지 측면이 있어서 쉬우면서도 신뢰도 있는 방법임
전화번호로 신원을 확인한다는 것 자체가 치명적인 문제로 느껴지진 않음. 권위주의 정부가 번호를 탈취하더라도 메시지 기록까지 얻는 건 아님. 신호를 받은 사용자는 이미 경고를 받게 됨. Signal이 문제 없는 건 아니고, 비판과 기준 제시는 반드시 필요하지만, 여전히 일반인이 쓸 수 있는 유일한 완전 종단간 암호화와 메타데이터 보호 메신저임. 더 보안·프라이버시 강한 서비스도 있지만 내 할머니도 쓸 수 있다는 점이 진짜 중요함. Signal이 보안은 충분히 다졌으니 이제 프라이버시에 집중하면 좋겠음. 비판하면서도 여전히 강력히 추천하고 스스로 친구들에게 적극적으로 권장함. 기부도 여러 번 함 Signal의 투명성 보고 참고
Signal에는 "등록 잠금"이라는 기능이 있어서, 비밀번호 설정 시 SIM 탈취로 계정이 도용되는 것을 막을 수 있음
Signal의 SPQR는 PQ3와 비슷하게 ML-KEM 기반 라쳇 구조지만, 키 전송 방식이 다름. ML-KEM 키 길이가 커서 PQ3는 키를 가끔만 주기적으로 보내고, Signal은 메시지와 함께 나눠보내는 식임. 숨겨진 대역폭, 보안상 chunking이 오히려 더 안전하고 효율적이라는 판단임. 에러 정정 코딩 때문에 전체 대역폭은 늘 수 있지만, 각 메시지 사이즈는 일정해짐. 애플은 네트워크 제어권이 더 세니까 적극적인 재키 교체 방어가 수월할 것임
iMessage가 실제로 현재 환경에서 의미 있나 싶음. 왜냐면 대부분의 iPhone 사용자는 iCloud 백업을 E2E 없이 쓰고, 완전 암호화 백업은 선택 옵션임. 즉 법 집행 요청이 오면 애플이 암호를 풀어줄 수 있으니, 양자컴퓨터까지 오지 않아도 이미 충분히 취약함
SPQR(Sparse Post-Quantum Ratchet)란 이름 보고 Signal팀에 로마역사 마니아가 있는 듯함
다들 로마제국에 대해 얼마나 자주 생각함?
어쩌면 채팅앱 최적의 단어 "Speaker"의 변주로 작명한 것일 수도 있음
Signal의 가장 큰 약점은 전화번호 기반 신원 인증임. 해커만이 아니라 권위주의 정부도 언제든 번호 소유권을 탈취할 위험이 있음. 미래의 위협도 좋지만 우선순위가 바뀌어야 함
전화번호 없이도 잘 운영되는 보안 메신저들이 많음. 이런 서비스들은 메타데이터 보호도 뛰어남. 많은 나라에서 SIM카드 실명제라 Signal 방식은 현실적으로 진입장벽이 큼
Signal이 메시지 전송 기반 역할, 즉 '전송 버스'가 되길 바람. 예를 들어 특정 연락처(아내 등)에게 내 위치 정보를 안전하게 요청하고 줄 수 있다면 Google을 통하지 않아도 됨. 신원 인증을 이미 해결했으니, 이제 Signal 위에서 앱을 만드는 걸 독려해야 한다고 생각함. 2FA도 Signal로 하면 SMS보다 더 안전할 거라 생각함
Signal로 써드파티 앱이 거의 나오지 않는 이유가 AGPL 3 라이선스 때문이 아닐까 싶음
현대 Signal 프로토콜과 Matrix, MLS 같은 것과의 비교도 꼭 보고 싶음. 빠르게 발전해서 따라가기 힘든데, 현 시점에서 관계도가 궁금함
요약하자면, Signal Protocol은 Signal이 시시각각 발전시켜 온 암호 프로토콜 계열을 통칭함. 더블 라쳇 기반으로 시작해서 PQXDH(초기 키 교환에 Kyber512 적용), 이제 SPQR 라쳇(세션 갱신 암호까지 PQ적용)까지 장착함. Signal의 장점은 메타데이터 보호(그룹 구조 안 노출, sealed sender 등)이고, 완전히 중앙화된 운영, 원본 구현 외에는 제3자 구현 금지(AGPL+CLA).
Matrix는 오픈스탠다드로, Olm+Megolm(더블라쳇+그룹키 라쳇) 조합을 쓰고, 메타데이터는 서버 오픈해 보여주는 구조임(그룹 구조 서버 노출, 속성 값 평문 저장 등 개선 작업 중: Element 블로그 - 방 메타데이터 암호화 계획). 분산 구조여서 누구나 서버를 만들 수 있음.
마지막으로 MLS(RFC 9420)는 그룹 멤버십·키교환 프로토콜로, 더블라쳇 대체 가능하고 최근 PQ 적용 제안들도 있음. 퍼포먼스는 그룹 당 O(log N)으로 효율적임. 아직 성숙하지 않았고, 더블라쳇에 비해 복잡함. 확산은 더딘 편이지만, IETF 표준으로 Google은 RCS, Discord/웹엑스 VoIP 등에서 도입함. 메타데이터 은닉이나 암호학적 부정성(deniability)은 제공하지 않음
이 글은 내가 본 암호화 관련 글 중 최고급으로 잘 쓰여 있음. 암호화 관련해서 일정 수준 이해력이 있다고 생각하지만, 비슷한 주제의 다른 글은 중간에 진짜 눈이 피곤해졌는데, 이번 글은 전혀 낯선 주제를 다뤄도 흐름을 완전히 따라갈 수 있었음
양자암호 위협에 대해 잘 아는 분이 지금 Signal의 최신 프로토콜이 어떻게 더 안전해졌는지 쉽게 설명해 줄 수 있나? 읽어도 왜 더 안전해졌는지 정확히 모르겠음. 실제 체감 속도 저하가 있는지도 궁금함
간단히 설명하자면, 아군의 적이 "지금은 해독할 수 없지만, 언젠가 양자컴퓨터가 가능해지면, 미래에 현재 모은 암호문을 모아놓고 한번에 푸는 것"이 표준적인 위협 시나리오임. "Harvest and decrypt"라는 모델임. Signal이 지금 비밀을 꼭 오래 보존해야 하거나 앞으로 안전하게 지켜야 한다면 오늘부터 PQ 키합의가 필요함. 그래서 PQXDH와 같은 새로운 프로토콜이 필요한 이유임.
PQ 라쳇이 중요한 건, 만약 공격자가 장기적으로 암호문을 수집할 뿐 아니라 언젠가 디바이스 해킹·특정 구현 결함을 통한 키 유출이 생길 수 있다는 매우 현실적인 위협 때문임. Forward secrecy와 post-compromise security라는 2중 방어가 필요함. 순간마다 키를 계속 갱신하면 한번이라도 공격에 노출돼도 과거 메시지나 미래 메시지까지 위험해지진 않음. 이 방어가 양자암호 환경에서도 제대로 동작하려면 전체 라쳇 구조까지 PQ로 완성해야 함. 그렇지 않으면 공격자가 라쳇 구간만 노리게 되고, 모든 보안성이 깨짐
기존 Signal의 양자내성 암호 구현은 PCS(침해 이후 보안)가 없었음. 이번엔 제공함. 드디어 PCS의 의미를 알게 되어 좋았음. 새로운 개념이라 기대했지만 OTR(오프더레코드) 프로토콜에서도 이미 사용하던 방식이라는 점이 조금 아쉬웠음. 이 키 교환은 자주 일어나는 게 아니라 실제 성능 저하는 거의 없음
공식 블로그 요약:
사용자 입장에선 앱 사용 경험이 변하지 않음
이번 프로토콜 변경은 자동적이므로 별도 조치 필요 없음
이로 인해 미래 양자컴퓨터 위협까지 대비하고, 기존 보안 원칙(전방/침해후 보안)을 고수하게 됨
Hacker News 의견
Signal은 정말 훌륭한 암호화 논문을 계속 발표함에도 불구하고, 제품 관점에서는 무엇이 성공할지 몰라 이것저것 시도하는 느낌임. 포스트양자 핸드셰이크, 스토리, 머니 트랜스퍼 등 새로운 시도를 시도하고 있지만, 여전히 SDK, API, 봇 지원이 부재함. 공식 라이브러리도 미완성에다가 문서도 없음. 기능이 여전히 많은 부분 클라이언트에 숨어있음. 프로토콜 명세를 공개해 놓긴 했지만, 그걸로 직접 라이브러리 만들라고 하는 건 실제 제품 운영 방법과 완전히 동떨어진 무책임한 태도임. 수백만 명이 사용하는 플랫폼에 이 정도 기본이 안 되어 있음. WhatsApp, iMessage 같은 앱들은 개발자에게 뭐라도 열어주는데 Signal은 개발자 관련은 철저히 배제하는 분위기임. 제품 담당자가 없는 게 아닐까 싶을 정도로 명확한 전략을 찾아볼 수 없음. 오랜 Signal 사용자이자 적극적으로 홍보도 해왔던 입장에서는, Signal이 뜨거운 암호화 기술을 덕지덕지 붙인, 애플 생태계보다도 개발자에 더 닫힌 메신저로 느껴짐. 그럼에도 제품 만든 분들에겐 감사함
공감함. 특히 "스토리" 기능은 정말로 뭐가 될지 그냥 던져보는 느낌이 확 들었음. Signal이 아나키즘을 지향하는 비영리 단체 출신이라 목표 자체가 보통 회사와 다르다고 생각함. 앱이 본연의 임무엔 충실하니 괜찮지만, SDK가 있으면 정말 좋을 것 같음
API나 비즈니스 봇 같은 기능이 정말 중요한지 궁금함. WhatsApp, iMessage는 비즈니스용 API가 있지만, 일반 사용자로서는 실제로 그걸로 비즈니스와 상호작용한 적이 없음. 대신 가끔 봇이 귀찮게 하는 경험만 있었음. Signal에서 진짜 문제는 앱이 조용히 구버전이 되거나 업데이트가 멈추면 알림을 안 주고 메시지를 완전히 놓치는 상황임. 메신저의 핵심 미션인데 그게 안 됨
오히려 API랑 봇이 없다는 게 나에겐 오히려 장점임
나는 그런 기능 없이 지금처럼 안전하고 쓸 만한 메신저 만드는 데 집중해줬으면 좋겠음
내가 Signal에서 정말 짜증나는 건, 발신자가 듣는 링 소리가 실제 수신자 폰에서 울리지 않아도 들린다는 점임. 예전부터 일부러 이렇게 하고 있다며 방어해 온 공식적인 정책임. 예전의 잠수함 사운드 없앤 이후로 계속 이러고 있음
Signal 프로토콜 이름이 SPQR라서 깜짝 놀랐음. SPQR는 라틴어로 "Senatus Populusque Romanus"의 약자임 위키피디아 참고. 너무 멋짐
미래 지향적인 프로토콜 이름에 SPQR을 사용한 건 오지맨디아스(Ozymandias) 같은 느낌이 있음
아주 영리한 작명임. BBC 미니시리즈 "Rome"에서 로마 군단병 문신으로 자주 나온다고 익히 알고 있음 Rome 위키피디아
Strength and Honor(강인함과 명예)
이런 유머는 Hacker News에서만 볼 수 있다고 생각함. 예전에 "수학자가 자기 사물함 번호를 외우는 법"을 다룬 만화가 떠오름. ("1975? 그건 3,900,625의 제곱근이지!")
혹시 그냥 "SPQR"이 "Speaker"처럼 들리니까 채팅앱과 어울려서 그렇게 지은 건 아닐까? 모든 걸 로마와 엮을 필요는 없음
Signal의 가장 큰 약점은 전화번호로 신원을 구분하는 방식임. 해커뿐 아니라 권위주의 정부 입장에서도 언제든 전화번호를 탈취할 수 있음. 미래의 위협을 고민하는 것도 중요하지만 우선순위가 바뀌어야 함
아직 모르는 사람이 있을까 봐 공유함: Signal에서 사용자 이름으로 전화번호 비공개 기능 소개(2024년 2월)
많은 보안 메신저들이 전화번호 없이도 돌아가고, 메타데이터까지 지워가며 서비스를 제공하고 있음. 전화번호와 SIM카드가 개인에게 묶이는 국가에서는 Signal의 방식이 진입장벽임
전화번호 요구는 스팸 방지 측면이 있어서 쉬우면서도 신뢰도 있는 방법임
전화번호로 신원을 확인한다는 것 자체가 치명적인 문제로 느껴지진 않음. 권위주의 정부가 번호를 탈취하더라도 메시지 기록까지 얻는 건 아님. 신호를 받은 사용자는 이미 경고를 받게 됨. Signal이 문제 없는 건 아니고, 비판과 기준 제시는 반드시 필요하지만, 여전히 일반인이 쓸 수 있는 유일한 완전 종단간 암호화와 메타데이터 보호 메신저임. 더 보안·프라이버시 강한 서비스도 있지만 내 할머니도 쓸 수 있다는 점이 진짜 중요함. Signal이 보안은 충분히 다졌으니 이제 프라이버시에 집중하면 좋겠음. 비판하면서도 여전히 강력히 추천하고 스스로 친구들에게 적극적으로 권장함. 기부도 여러 번 함 Signal의 투명성 보고 참고
Signal에는 "등록 잠금"이라는 기능이 있어서, 비밀번호 설정 시 SIM 탈취로 계정이 도용되는 것을 막을 수 있음
Signal이 이번에 SPQR(양자 저항형 라쳇)을 적용한 후, iMessage의 PQ3와 비교하면 어떤 위치인지 궁금함. Cyph와 Simplex의 과거 양자저항 메시징 시도에 대한 고찰도 들어보고 싶음. iMessage PQ3 소개 / Cyph - Post-Quantum Castle / Simplex - 양자저항 기능
Signal의 SPQR는 PQ3와 비슷하게 ML-KEM 기반 라쳇 구조지만, 키 전송 방식이 다름. ML-KEM 키 길이가 커서 PQ3는 키를 가끔만 주기적으로 보내고, Signal은 메시지와 함께 나눠보내는 식임. 숨겨진 대역폭, 보안상 chunking이 오히려 더 안전하고 효율적이라는 판단임. 에러 정정 코딩 때문에 전체 대역폭은 늘 수 있지만, 각 메시지 사이즈는 일정해짐. 애플은 네트워크 제어권이 더 세니까 적극적인 재키 교체 방어가 수월할 것임
iMessage가 실제로 현재 환경에서 의미 있나 싶음. 왜냐면 대부분의 iPhone 사용자는 iCloud 백업을 E2E 없이 쓰고, 완전 암호화 백업은 선택 옵션임. 즉 법 집행 요청이 오면 애플이 암호를 풀어줄 수 있으니, 양자컴퓨터까지 오지 않아도 이미 충분히 취약함
SPQR(Sparse Post-Quantum Ratchet)란 이름 보고 Signal팀에 로마역사 마니아가 있는 듯함
다들 로마제국에 대해 얼마나 자주 생각함?
어쩌면 채팅앱 최적의 단어 "Speaker"의 변주로 작명한 것일 수도 있음
Signal의 가장 큰 약점은 전화번호 기반 신원 인증임. 해커만이 아니라 권위주의 정부도 언제든 번호 소유권을 탈취할 위험이 있음. 미래의 위협도 좋지만 우선순위가 바뀌어야 함
Signal이 메시지 전송 기반 역할, 즉 '전송 버스'가 되길 바람. 예를 들어 특정 연락처(아내 등)에게 내 위치 정보를 안전하게 요청하고 줄 수 있다면 Google을 통하지 않아도 됨. 신원 인증을 이미 해결했으니, 이제 Signal 위에서 앱을 만드는 걸 독려해야 한다고 생각함. 2FA도 Signal로 하면 SMS보다 더 안전할 거라 생각함
현대 Signal 프로토콜과 Matrix, MLS 같은 것과의 비교도 꼭 보고 싶음. 빠르게 발전해서 따라가기 힘든데, 현 시점에서 관계도가 궁금함
Matrix는 오픈스탠다드로, Olm+Megolm(더블라쳇+그룹키 라쳇) 조합을 쓰고, 메타데이터는 서버 오픈해 보여주는 구조임(그룹 구조 서버 노출, 속성 값 평문 저장 등 개선 작업 중: Element 블로그 - 방 메타데이터 암호화 계획). 분산 구조여서 누구나 서버를 만들 수 있음.
마지막으로 MLS(RFC 9420)는 그룹 멤버십·키교환 프로토콜로, 더블라쳇 대체 가능하고 최근 PQ 적용 제안들도 있음. 퍼포먼스는 그룹 당 O(log N)으로 효율적임. 아직 성숙하지 않았고, 더블라쳇에 비해 복잡함. 확산은 더딘 편이지만, IETF 표준으로 Google은 RCS, Discord/웹엑스 VoIP 등에서 도입함. 메타데이터 은닉이나 암호학적 부정성(deniability)은 제공하지 않음
이 글은 내가 본 암호화 관련 글 중 최고급으로 잘 쓰여 있음. 암호화 관련해서 일정 수준 이해력이 있다고 생각하지만, 비슷한 주제의 다른 글은 중간에 진짜 눈이 피곤해졌는데, 이번 글은 전혀 낯선 주제를 다뤄도 흐름을 완전히 따라갈 수 있었음
양자암호 위협에 대해 잘 아는 분이 지금 Signal의 최신 프로토콜이 어떻게 더 안전해졌는지 쉽게 설명해 줄 수 있나? 읽어도 왜 더 안전해졌는지 정확히 모르겠음. 실제 체감 속도 저하가 있는지도 궁금함
간단히 설명하자면, 아군의 적이 "지금은 해독할 수 없지만, 언젠가 양자컴퓨터가 가능해지면, 미래에 현재 모은 암호문을 모아놓고 한번에 푸는 것"이 표준적인 위협 시나리오임. "Harvest and decrypt"라는 모델임. Signal이 지금 비밀을 꼭 오래 보존해야 하거나 앞으로 안전하게 지켜야 한다면 오늘부터 PQ 키합의가 필요함. 그래서 PQXDH와 같은 새로운 프로토콜이 필요한 이유임.
PQ 라쳇이 중요한 건, 만약 공격자가 장기적으로 암호문을 수집할 뿐 아니라 언젠가 디바이스 해킹·특정 구현 결함을 통한 키 유출이 생길 수 있다는 매우 현실적인 위협 때문임. Forward secrecy와 post-compromise security라는 2중 방어가 필요함. 순간마다 키를 계속 갱신하면 한번이라도 공격에 노출돼도 과거 메시지나 미래 메시지까지 위험해지진 않음. 이 방어가 양자암호 환경에서도 제대로 동작하려면 전체 라쳇 구조까지 PQ로 완성해야 함. 그렇지 않으면 공격자가 라쳇 구간만 노리게 되고, 모든 보안성이 깨짐
기존 Signal의 양자내성 암호 구현은 PCS(침해 이후 보안)가 없었음. 이번엔 제공함. 드디어 PCS의 의미를 알게 되어 좋았음. 새로운 개념이라 기대했지만 OTR(오프더레코드) 프로토콜에서도 이미 사용하던 방식이라는 점이 조금 아쉬웠음. 이 키 교환은 자주 일어나는 게 아니라 실제 성능 저하는 거의 없음
공식 블로그 요약:
Sono pazzi, questi Romani(로마인들은 정말 이상함)