OneTimeSecret vs PrivateNote: 암호화 위치가 중요한 이유

같은 링크를 만드는 두 가지 방법

서버 측 암호화에서 보낸 사람은 TLS로 비밀을 서비스에 제출합니다. 서비스는 평문을 받고, 암호화하고, 암호문을 저장합니다. 그다음 페이로드를 저장하고, 전달하고, 만료시키고, 삭제할 수 있습니다. 평문이 암호문이 되기 전에 서비스 안으로 들어오므로, 애플리케이션 서버는 암호화 과정의 일부입니다.

클라이언트 측 암호화에서 보낸 사람의 기기가 먼저 암호화합니다. 서비스는 암호문을 받아 저장합니다. 그 업로드는 TLS로 이동합니다. 서비스는 표준 페이로드를 복호화하는 데 필요한 키를 받지 않습니다. 수신자의 기기가 로컬에서 복호화합니다. 서비스는 평문에 접근하지 않고도 페이로드를 저장하고, 전달하고, 만료시키고, 삭제할 수 있습니다.

두 설계 모두 임시 링크, 제한된 접근, 만료를 제공할 수 있습니다. 둘 다 암호화되었다고 정확히 말할 수 있습니다. OneTimeSecret는 첫 번째 구조를 쓰고, PrivateNote는 두 번째를 씁니다. 따라서 관련 질문은 일회용 링크가 암호화되어 있는지 자체가 아니라, 그 링크가 작동하려면 어떤 시스템이 평문에 접근해야 하는가입니다.

OneTimeSecret: 서버 측 암호화

일반적인 OneTimeSecret 흐름에서 보낸 사람은 TLS로 비밀을 제출합니다. 애플리케이션은 평문을 받고, 서버에서 암호화하고, 암호화된 페이로드를 저장합니다.

이것은 저장된 데이터에 의미 있는 보호를 제공합니다. 암호화된 저장소만 얻는다고 해서, 복호화에 필요한 자료가 공격자에게 없을 때 그 내용이 반드시 드러나지는 않습니다.

구조상의 절충은 저장 전에 일어납니다. TLS는 비밀이 브라우저와 OneTimeSecret 사이를 이동하는 동안 보호하지만, 애플리케이션은 암호화하기 위해 평문을 처리해야 합니다. 따라서 애플리케이션 서버는 암호학적 신뢰 경계 안에 있습니다.

그 순간의 악의적이거나 침해된 애플리케이션 프로세스는 저장을 위해 암호화되기 전에 비밀에 접근할 수 있습니다. 클라이언트 측 암호화는 비밀이 서비스에 도달하기 전에 암호화해서 바로 이 의존을 제거합니다.

OneTimeSecret의 암호 문구는 암호화 경계를 바꾸지 않습니다

OneTimeSecret 문서는 선택적 암호 문구를 설명합니다. 암호 문구를 쓰면, OneTimeSecret는 보낸 사람이 제공한 암호 문구로 비밀을 자사 서버에서 암호화한다고 말합니다. 암호 문구 자체는 저장하지 않고, 조회 때 암호 문구를 검증하는 데 쓰는 bcrypt 해시를 보관한다고 말합니다. 그 문서에 따르면 그 해시 자체로는 비밀을 복호화할 수 없고, 저장된 암호 문구 보호 비밀은 원래 암호 문구 없이는 복호화할 수 없습니다.

조회도 같은 서버 측 경계를 씁니다. 수신자가 TLS로 암호 문구를 OneTimeSecret에 제공합니다. 서비스가 그것을 검증하고, 평문을 돌려주기 전에 서버에서 복호화를 수행합니다.

이것은 암호화가 일어날 때 애플리케이션 프로세스가 비밀과 암호 문구에 접근하고, 조회 중에는 암호 문구와 그 결과인 평문을 다시 처리한다는 뜻입니다. 어느 지점에서든 동작하는 악의적이거나 침해된 애플리케이션 프로세스는 그 정보를 포착할 수 있습니다. 이것은 암호화와 복호화가 어디에서 실행되는지의 결과이며, OneTimeSecret가 그 값을 기록하거나 오용한다는 주장은 아닙니다.

OneTimeSecret의 공개 문서만으로는 내부 키 계층의 모든 세부, 예를 들어 서버 측 키 자료, 비밀별 키, 키 도출, 제공된 암호 문구가 정확히 어떻게 결합되는지가 확정되지는 않습니다. 이 비교를 위해 그 구현 세부까지 추측할 필요는 없습니다. 문서화된 관련 속성은 암호화와 복호화가 서비스 측에서 일어난다는 점입니다.

자체 호스팅은 그 서버 신뢰를 합리적으로 만들 수 있습니다

OneTimeSecret는 오픈 소스입니다. 조직은 비밀을 공개 서비스로 보내는 대신, 기업 보안 경계 안에서 자체 인스턴스를 운영할 수 있습니다.

그 배포에서 애플리케이션 서버를 신뢰하는 일은 조직이 이미 운영하는 인프라를 신뢰하는 일입니다. 암호화가 여전히 그곳에서 일어나므로 평문은 여전히 그 서버에 도달합니다. 경계 반대편에 있는 당사자는 조직 자신의 호스트, 운영자, 백업입니다. 비밀이 지나는 경로의 일부로 그 시스템을 이미 받아들이는 팀에게는 서버 측 암호화가 합리적인 선택일 수 있습니다. 운영자가 더 이상 외부 서비스가 아니므로, 서버 측과 클라이언트 측 위협 모델 사이의 간극이 좁아집니다.

PrivateNote는 업로드 전에 암호화합니다

표준 PrivateNote는 업로드 전에 암호화됩니다. 보낸 사람의 브라우저, 또는 로컬 CLI, Chrome 확장 프로그램, 편집기 확장 프로그램, MCP 프로세스가 무작위 키를 생성하고 AES-256-GCM으로 페이로드를 암호화합니다. 암호문만 업로드됩니다. TLS가 그 암호문을 브라우저에서 PrivateNote의 Cloudflare 워커로 운반합니다. 복호화 키는 URL 프래그먼트, 즉 # 뒤의 부분에 놓입니다. 예를 들어 https://privatenote.ai/note/abc123#…입니다. 프래그먼트는 클라이언트 측에서 처리되며 HTTPS 요청에 포함되지 않습니다(RFC 3986, §3.5, URL 표준). 워커는 메모 식별자를 받고 같은 TLS 연결로 암호문을 돌려줍니다. 브라우저는 프래그먼트를 유지하고 로컬에서 복호화합니다.

암호 문구는 링크 채널이 침해되면 키를 보호합니다

PrivateNote의 암호 문구는 OneTimeSecret의 암호 문구와 다른 일을 합니다. 메모는 기기를 떠나기 전에 이미 암호문입니다. 암호 문구를 추가하면 브라우저가 Argon2id로 그 문구에서 래핑 키를 도출하고, 그 래핑 키로 메모의 키를 암호화합니다. 그러면 URL 프래그먼트에는 래핑된 키가 있습니다. 수신자에게는 링크와 암호 문구가 둘 다 필요합니다. 브라우저가 키를 로컬에서 푼 다음에야 메모를 복호화합니다.

PrivateNote는 암호 문구를 받지 않습니다. 생성 요청에는 암호문, 솔트, 그리고 수신자 브라우저가 암호 문구를 로컬에서 시도하는 데 필요한 매개변수가 실립니다. 암호 문구를 검증하는 일이 목적인 서버 측 해시는 없습니다. 잘못된 암호 문구는 기기에서 복호화에 실패합니다.

암호 문구는 링크를 나르는 채널이 침해되면 클라이언트 측 키를 로컬에서 추가로 보호합니다. 그 채널이 보는 것은 혼자서는 메모를 열 수 없는, 래핑된 키입니다. 그것이 PrivateNote를 평문 경로 밖에 두는 메커니즘은 아닙니다. 그 분리는 암호 문구가 있든 없든 표준 메모에 이미 있습니다. 암호 문구는 링크와 다른 채널로 공유하십시오. 같은 메시지는 두 층을 하나로 무너뜨립니다. 비밀번호를 안전하게 공유하기와 같은 규칙입니다.

PrivateNote의 키 처리는 작동 방식에 설명되어 있습니다. 콘텐츠 키는 Argon2id로 래핑되고, 래핑된 키는 링크 안에서 이동합니다.

남아 있는 웹 클라이언트 신뢰 가정

브라우저의 클라이언트 측 암호화는 신뢰가 필요 없는 웹 애플리케이션이 아닙니다. 암호학은 로컬에서 실행될 수 있지만, 그것을 구현하는 JavaScript는 사이트가 전달합니다. 브라우저는 그 세션에 받은 코드를 신뢰합니다.

애플리케이션, CDN, 배포 파이프라인을 통해 그 JavaScript를 바꿀 수 있는 사람은 클라이언트를 바꾸고 이후 브라우저 세션에서 키를 포착할 수 있습니다. 그것은 데이터베이스를 훔치는 것과는 다른 실패입니다. 저장소 침해는 암호문을 노출합니다. 악의적인 코드 전달은 키가 실제로 있는 동안 엔드포인트를 공격합니다.

나중의 데이터베이스 덤프는 그곳에 저장된 적 없는 클라이언트 측 키를 만들어 낼 수 없습니다. 활발히 침해된 클라이언트는 그 세션 동안 다뤄진 비밀을 공격할 수 있습니다. 같은 가정이 PrivateNote의 위협 모델에도 적혀 있습니다. 전달된 애플리케이션 코드가 악의적으로 수정되지 않았고, 암호화와 복호화 순간에 보낸 사람과 수신자의 기기를 신뢰한다는 것입니다.

설치형 소프트웨어는 방금 다운로드한 페이지에 대한 그 의존을 좁힙니다. CLI, 편집기 확장 프로그램, 네이티브 앱은 설치한 코드를 실행합니다. 그 클라이언트도 운영체제, 서명, 의존성, 업데이트 채널에 의존합니다. 개발자 도구는 브라우저와 같은 분리를 씁니다. 로컬에서 암호화하고, 암호문을 업로드하고, 키는 프래그먼트에 둡니다.

수명과 기밀성

일회용 링크는 서로 다른 두 질문에 답합니다. 암호화된 페이로드는 얼마나 오래 존재해야 합니까? 그리고 존재하는 동안 누가 복호화할 수 있습니까? 조회나 만료 뒤에 파기하면 창이 짧아집니다. 그 창 동안 누가 읽을 수 있었는지는 정하지 않습니다. 수명과 기밀성은 서로를 돕습니다. 하나가 다른 하나를 대신하지는 않습니다.

페이로드가 권한일 때 구분이 가장 선명합니다. API 키, 데이터베이스 자격 증명, 클라우드 토큰, 복구 코드, 인프라 비밀번호. 비밀 공유 서비스가 존재하는 이유는 보낸 사람이 그 정보를 맡기는 시스템을 더 줄이고 싶기 때문입니다. 중개자가 불투명한 암호화 객체를 운반하고, 만료를 적용하고, 삭제하기만 하면 된다면, 서버는 비밀이나 그것을 여는 키를 받지 않고도 그 일을 할 수 있습니다.

경계가 놓이는 곳

“암호화됨”은 신뢰 경계가 어디에 있는지를 말해 주지 않습니다. 쓸 만한 기준은 최소 신뢰 경계입니다. 누가 평문을 보아야 하는지에 적용한 최소 권한 원칙입니다. 현대 암호 공학에서 목표는 서버가 바르게 행동한다고 신뢰하는 데 그치지 않고, 애초에 신뢰가 수학적으로 필요해지는 정도를 줄이는 것입니다.

OneTimeSecret는 서버 측 암호화 시스템을 설명합니다. 암호 문구 보호가 있으면, 저장된 비밀은 이후 암호 문구 없이는 복호화할 수 없고, 그 암호 문구가 알려지지 않은 한 서버 침해가 있어도 비밀은 안전하다고 말합니다. 약한 암호 문구는 무차별 대입될 수 있습니다. 약하다면 그 침해 뒤에도 비밀이 복구될 수 있습니다. 암호화가 그 서버에서 일어나므로 평문과 암호 문구는 생성 때 OneTimeSecret에 도달하고, 그 서버가 복호화할 수 있도록 조회 때 암호 문구가 다시 전송됩니다.

PrivateNote는 다른 구조적 선택을 합니다. 페이로드는 서비스에 도달하기 전에 암호화되고, 표준 페이로드 키는 클라이언트 측에 남습니다. 암호 문구를 설정하면, 링크를 나르는 채널이 침해되었을 때 그 클라이언트 측 키를 로컬에서 추가로 보호합니다. 그것은 PrivateNote로 전송되지 않습니다.

OneTimeSecret는 비밀을 암호화합니다. PrivateNote 서비스를 쓰는 클라이언트는 서비스가 받기 전에 그것을 암호화합니다. 그 구분은 어느 제공자가 악의적이라고 가정하는 데 의존하지 않습니다. 질문을 구조로 줄입니다. 서비스가 작동하려면 몇 개의 시스템이 평문에 접근해야 합니까?

자주 묻는 질문

주요 출처

OneTimeSecret에 대한 구조 정보는 2026년 9월 23일 공개 문서와 대조해 검토했습니다. 제품 구현과 문서는 바뀔 수 있습니다.

• OneTimeSecret 문서
• 보안과 암호 문구에 대한 OneTimeSecret 설명
• OneTimeSecret 소스 코드
• PrivateNote 암호화 작동 방식
• 개발자를 위한 PrivateNote, CLI 포함
• RFC 3986, 3.5절. 역참조 전에 프래그먼트를 URI에서 분리합니다
• URL 표준, 프래그먼트. 프래그먼트의 클라이언트 측 처리