암호화 링크 공유

브라우저 모드에서는 — 읽을 수 없습니다. 암호화 키는 URL의 # 뒤에 위치하며, HTTP 사양상 브라우저는 프래그먼트를 네트워크 요청에 포함하지 않으므로 키는 우리 서버에 도달하지 않습니다. 암호화된 블롭은 URL 경로로 도착하므로(표준 nginx 액세스 로그를 통해 서버 로그가 암호문을 잠시 기록할 수 있음) 키 없이는 AES-GCM-256 암호문이며 복호화할 수 없습니다.

Privnote는 암호화된 블롭을 데이터베이스에 저장한 후 첫 조회 후 삭제합니다. 브라우저 모드에서 이 도구는 비밀 데이터베이스를 사용하지 않습니다 — 블롭이 URL 자체에 있으므로 "한 번만 보기"를 강제할 수 없습니다. 절충점: 암호화 키는 우리 서버에 도달하지 않지만, 링크는 누군가 가지고 있는 한 재사용 가능합니다. (이 도구의 서버 저장 모드는 Privnote와 더 유사합니다.)

비밀이 그 안에 실려 가기 때문입니다. 주소에는 암호화된 본문과 초기화 벡터, 선택적인 솔트, 그리고 키 자체가 담깁니다. 그래서 링크의 길이는 보내시는 내용의 길이를 따라 자랍니다. 텍스트 4킬로바이트면 링크가 6킬로바이트쯤 되는데, 요즘 브라우저는 모두 그 정도를 감당합니다. 설계도 여기서 따라 나옵니다. 나중에 찾아낼 수 있는 사본이 어디에도 놓여 있지 않고, 같은 이유로 링크를 잃으면 비밀을 되살릴 방법도 없습니다. 실용적인 결과가 둘입니다. 링크는 통째로 보내세요. 두 줄로 끊긴 링크는 다시 이어 붙여도 작동하지 않습니다. 그리고 유난히 긴 링크라면 작은 비밀 두어 개로 나누는 편이 낫습니다.

링크는 비밀이 새지 않는 방식으로 새기 때문입니다. 링크 하나만 있으면 비밀이 열립니다. 그렇게 설계된 것이지요. 그런데 그 링크는 대화 기록에, 전달된 메시지에, 화면 캡처에, 그것을 실어 나른 무언가의 로그에 남습니다. 비밀번호는 다른 길로 가는 두 번째 요소를 더해 줍니다. 링크는 한 통로로 보내고 비밀번호는 전화로 말해 주면, 대화를 읽은 사람도 아무것도 열지 못합니다. 동료가 봐도 상관없는 것이라면 비밀번호를 건너뛰셔도 됩니다. 통로 자체가 약한 고리인 곳에서는 반드시 쓰세요. 그리고 대부분의 통로가 그렇습니다.

브라우저 모드에서는: URL을 가진 사람이 있는 한입니다. 만료를 강제할 데이터베이스 상태가 없으므로, 모든 수신자 기기에서 삭제되었다고 신뢰할 때까지 공유된 링크를 지속적인 것으로 취급하세요. (서버 저장 모드에서는 명시적 TTL이 적용됩니다 — "만료 시간" 참조.)

예 — 그것이 서버 저장 모드입니다. 읽기 후 삭제 방식의 서버 측 저장을 사용하며, 다른 신뢰 가정을 가집니다(서버를 신뢰해야 함). 브라우저 모드(암호문이 URL에 있음)는 데이터베이스가 없는 옵션으로 함께 제공됩니다.