먼저 확인해야 할 사항:통신의 TLS, 단말기 및 서버에 암호화 저장, E2EE는 보호하는 상황이 다릅니다. 동기화가 E2EE라 하더라도, 단말기의 로컬 파일이나 내보낸 PDF까지 동일한 암호화가 지속된다는 보장은 없습니다.
최종 확인: 。 필자는 SimpleMemo의 개발자입니다. 다른 회사 제품은 공식 자료를 비교하고 있으며, 각 앱에 대한 침입 시험이나 독립적인 보안 감사를 수행한 결과가 아닙니다.
TLS·저장 시 암호화·E2EE는 무엇이 다릅니까?
통신 중: 연결 대상까지의 경로를 보호합니다
TLS은 앱과 서버 등의 통신 경로를 보호합니다. 연결 대상이 처리하는 본문까지 연결 대상에서 숨기는 구조가 아닙니다. HTTPS에서 보낸 메모를 서비스가 검색·배포하는 것과 모순되지 않습니다.
저장 시: 어떤 파일을 누구의 키로 암호화할지
단말기 내의 데이터베이스, 동기화 서버, 백업은 별도의 복사본입니다. 서버 디스크가 암호화되어 있더라도, 서비스가 키를 관리하고 있다면, 필요한 처리 시에 복호화할 수 있습니다. 전체 단말기의 암호화와 앱이 메모별로 암호화하는 메커니즘도 구분합니다.
E2EE：동기화 대상에게 본문의 복호화 키를 전달하지 않음
엔드투엔드 암호화에서는 해당 단말기 측에서 암호화 및 복호화합니다. 다만, 제목이나 시간 등의 메타데이터, 공개 링크, AI 기능으로의 전송, 복호 후의 내보내기는 별도로 확인이 필요합니다. 앱에 E2EE 기능이 있더라도, 자신의 노트에서 반드시 유효하다고는 할 수 없습니다.
AES-GCM·AES-CBC·제로 지식을 구분하다
AES-GCM는 암호화와 인증을 결합하여 변조 탐지에 사용되는 인증 태그를 생성합니다. AES-CBC는 비밀성을 제공하는 모드이며, 그것만으로는 변조 감지를 수행하지 않습니다. 인증은 MAC 등과 같은 다른 메커니즘과 적절히 결합해야 합니다. CBC라는 이름만으로는 제품이 파손된 것으로 판단할 수 없습니다. NIST의 GCM 사양、CBC를 포함하는 암호 모드 사양.
「256」은 키 길이이며, 키를 누가 가지고 있는지나 백업 설정에 대해서는 설명하지 않습니다. AES-GCM을 사용하는 E2EE도, AES-GCM에서 단말 내부만 보호하는 설계도 있습니다.
제로나레지는 스토리지 제품에서 “사업자가 본문을 복호화할 수 없는” 설계를 설명하는 말로 사용됩니다. 암호화 방식의 이름이나 모든 데이터가 전혀 수집되지 않는다는 보장은 아닙니다. 암호화된 키를 서버에 보관하는 설계도 있기 때문에, “키가 서버에 존재하지 않는다”는 것만으로 판단하지 않고, 복호화할 수 있는 주체와 대상 데이터를 확인합니다.
10 앱: 방식보다 먼저, 범위와 설정을 비교
가로 스크롤하여 “조건”과 “별도로 확인하는 복사본”까지 확인할 수 있습니다. 표는 키보드에서도 가로로 이동할 수 있습니다.
| 앱 | 암호화 범위 | 활성화·확인 조건 | 별도 확인하는 복사·권한 | 근거 |
|---|---|---|---|---|
| Standard Notes | 단말 측에서 내용을 암호화하여 동기화합니다. 공개 사양은 XChaCha20-Poly1305입니다. | 계정을 사용할 때는 로컬 데이터도 암호화됩니다. 계정 없이 이용할 경우 패스코드 등의 보호를 별도로 설정합니다. | 내보낸 파일이나 다른 앱에 복사한 문장은 저장 대상 조건을 확인하십시오. | 암호화 범위 · 방식 |
| Obsidian Sync | 리모트 Vault을 E2EE로 암호화하는 설정이 기본값입니다. AES-256-GCM. | 표준 암호화를 선택한 원격 Vault에서는 Obsidian 측이 키를 관리합니다. 설정 및 암호화 비밀번호를 확인하십시오. | 로컬 Vault의 Markdown 파일은 Obsidian 자체에서 암호화되지 않습니다. 단말기의 디스크 암호화 및 백업은 별도입니다. | Sync 보안 |
| Notion | 통신은 TLS 1.2 이상이며, 저장 시에는 AES-256입니다. | 공식 자료가 설명하는 것은 서비스 측의 암호화입니다. 사용자만 복호키를 가진 노트 전체의 E2EE와는 구별됩니다. | 공개 페이지·게스트·연계 서비스에 전달할 권한도 확인했습니다. 암호화만으로는 공개 범위를 제한하지 않습니다. | 보안 방침 |
| Evernote | TLS 통신 및 Google 관리키에 의한 AES-256 저장. 선택한 텍스트에는 암호 구문 암호화도 있습니다. | 선택 텍스트의 공개 방식은 AES-128-CBC입니다. 노트 전체와 첨부 파일을 일괄적으로 E2EE화하는 기능과는 다릅니다. | 암호화된 범위 밖에 있는 본문, 제목, 첨부 파일은 동일한 암호 구문 보호로 취급되지 않습니다. | 저장 및 통신 · 텍스트 암호화 |
| Apple메모 / Apple Notes | 일반적인 iCloud 보호는 통신·저장 시 암호화됩니다. 고급 데이터 보호(ADP)에서 iCloud 메모가 E2EE의 대상이 됩니다. | ADP의 유효 상태와 복구 방법을 확인합니다. 공유 메모에서 ADP의 E2EE를 유지하려면 모든 참가자가 ADP가 필요합니다. | 일부 메타데이터는 표준 보호됩니다. 내보낸 PDF와 이메일 첨부 파일은 원본 iCloud 메모와는 다른 복사본입니다. | iCloud의 보호 범위 |
| Google Keep | 통신 중 및 저장 시 암호화. 검색 등 기능을 제공하기 위해 내용을 처리합니다. | 공식 자료의 보호를, 이용자만 열쇠를 가진 E2EE와 바꾸지 않습니다. | 공유 상대와 Google 계정 보호를 확인합니다. 광고에 내용을 사용하지 않는 방침과 내용을 처리하지 않는 설계는 별개입니다. | Keep의 프라이버시와 보호 |
| Bear | Bear Pro에서 개별 노트를 비밀번호로 암호화합니다. 2.4 이후에는 이미지·PDF 등의 첨부도 대상이 됩니다. | 대상 노트에 비밀번호를 추가하고, 동기화할 기기의 앱도 업데이트합니다. 앱 전체의 잠금과는 구별됩니다. | 제목은 노트 목록에 표시됩니다. iCloud의 ADP에도 제목·태그 등의 범위를 포함하여 확인합니다. | 노트 암호화 · 2.4의 첨부 대응 · 동기화 범위 |
| 조플린 | 활성화된 동기화로 E2EE. v3.2의 새로운 네이티브 방식은 AES-256-GCM입니다. | 한 대에서 암호화를 활성화하고, 동기화가 완료되는 것을 기다린 후 다른 단말기에 잠금을 설정하는 공식 절차를 사용합니다. | 로컬 데이터는 이 동기 암호화로 보호되지 않습니다. 단말기의 디스크 암호화도 확인합니다. | 설정 절차 · 새 방식 · 단말기 내 데이터 |
| 1일차 | 4.2 이후에 새로 만드는 저널은 기본적으로 E2EE입니다. 문서와 미디어가 대상입니다. | 오래된 저널은 개별적으로 상태를 확인합니다. 현재 공식 FAQ에서는 표준 암호화에서 직접 전환할 수 없으며, 새로운 E2EE 저널에 복사합니다. | 키의 보관처도 확인합니다. iCloud 키체인은 E2EE이지만, Day One 고유의 iCloud 키 백업은 ADP를 활성화해도 E2EE가 되지 않습니다. 작성한 일기도 별도의 사본입니다. | E2EE의 FAQ |
| SimpleMemo / Simple Memo | 단말기 내의 Outbox 전송 기록을 CryptoKit의 AES-GCM로 암호화합니다. 새 키는 256-bit로 Keychain에 저장됩니다. | 메일 전송은 E2EE가 아닙니다. 전송 API·외부 배포 플랫폼을 통과하여 수신함에 복사본이 남습니다. | 단말기 내 보호는 메일 서비스 및 연동된 Obsidian Vault의 보관 방법까지 보장하는 것이 아닙니다. | 기술 설명 |
자신의 받은 편지함에 짧은 메모를 남기는 용도라면, SimpleMemo도 선택 사항입니다. 기기 내 암호화와 수신 이메일의 보관·공유 설정을 각각 확인해 주세요.
사용하기 전에 설정과 복사를 5점 확인
- 기존 데이터 설정을 엽니다. 앱 이름만으로 판단하지 않고, 사용하는 Vault·저널·공유 노트에서 암호화가 유효한지 확인합니다. 신규 데이터의 기본값이 기존 데이터에도 적용된 것은 아닙니다.
- 복구 방법을 확보합니다. 동기화용 비밀번호, 암호화 키, 복구 연락처 등, 제품이 안내하는 방법을 확인합니다. 키를 분실한 상태에서 단말기를 삭제하고 시도하는 것은 피하십시오.
- 공개·공유·연계 범위를 확인합니다. 공개 링크 및 외부 서비스에 대한 전송은 저장 시 암호화와는 별개입니다. 업무 정보는 소속처가 인정하는 저장처·공유 범위에 맞춥니다.
- 더미의 1건으로 동기화와 첨부를 확인합니다. 내용에 기밀 정보를 사용하지 않고, 다른 기기에서 열 수 있는지, 첨부가 가능한지, 암호화된 상태가 어떻게 표시되는지 확인합니다. 이것만으로는 암호 구현의 안전성을 입증한 것이 아닙니다.
- 출고 대상과 백업을 확인합니다. Markdown, PDF, 메일, 다운로드 폴더에 만든 복사본이 원본 앱의 E2EE 외부에 표시될 수 있습니다. 이전 확인이 끝나기 전에 원본 데이터를 삭제하지 마십시오.
SimpleMemo가 보호하는 범위와 전송 후에 남는 것
SimpleMemo는 단말기 내의 전송 대기 메모(Outbox)와 전송 이력을 AES-GCM로 암호화합니다. 공개된 앱의 공통 암호기에서는 새로 만든 키를 256-bit으로 Keychain에 저장하고, CryptoKit으로 암호화·복호화하고 있습니다. 이는 단말기 내의 대상 데이터를 보호하는 구현입니다.
메일 경로 전체의 E2EE가 아닙니다. 앱에서 API로 HTTPS로 전송하고, 외부 메일 전송 플랫폼을 통해 수신함으로 도착합니다.「 '단말기 내 미전송 메모가 암호화되어 있다'는 것은 '전송 처리 과정에서 본문을 다루지 않는다' 혹은 '외부 서버를 통과하지 않는다'는 의미가 아닙니다.
전송이 완료되어 Outbox의 대상 항목이 제외되더라도, 전송 기록이나 수신 메일, 연동 대상 메모까지 사라지는 것은 아닙니다. 파일 삭제 작업을 저장 매체의 완전 삭제라고도 부르지 않습니다. 저장 대상 및 보유 기간은 개인정보 보호정책의 기술 설명와데이터 경로에서 확인할 수 있습니다.
Obsidian에 저장을 사용하는 경우에도 로컬 Vault과 동기화·백업 보호는 본인의 설정에 의존합니다. 본문을 사업자가 복호할 수 없는 것이 필수인 경우에는, 해당 조건에 맞는 E2EE의 저장처와 운용을 먼저 선택해 주시기 바랍니다.
자주 묻는 질문
AES-256이라면 E2EE인가요?
아니요. AES-256은 암호와 키 길이를 나타냅니다. E2EE 여부는 어디에서 암호화·복호화하고, 누가 키를 사용할 수 있는지에 따라 결정됩니다. 서버가 키를 관리하는 AES-256 저장과 사용자의 단말기만으로 복호하는 설계는 다릅니다.
AES-GCM와 AES-CBC는 무엇이 다릅니까?
GCM은 암호화와 인증을 결합합니다. CBC는 암호화만으로는 변조를 감지하지 않으므로 인증 메커니즘을 적절히 조합할 필요가 있습니다. 방식명만으로는 앱 전체의 안전성을 순위 매겨서는 것이 불가능합니다.
E2EE라면 단말기 내 파일도 암호화됩니까?
반드시 그렇지는 않습니다. Obsidian Sync와 Joplin의 동기 암호화는 단말기 내의 로컬 파일 및 데이터베이스를 동일하게 암호화하는 것이 아닙니다. 단말기의 디스크 암호화, 앱의 로컬 보호, 백업을 별도로 확인해 주세요.
Bear으로 이미지와 PDF를 포함한 노트도 암호화할 수 있습니까?
Bear 2.4 이후는 Bear Pro로 첨부 파일을 포함한 개별 노트를 암호화할 수 있습니다. 대상 노트에 비밀번호를 추가하고, 동기화 대상 앱도 지원 버전으로 업데이트합니다. 제목 표시와 암호화되지 않은 노트는 별도로 확인이 필요합니다.
Day One의 오래된 저널도 자동으로 E2EE가 되고 있습니까?
새로운 저널은 4.2 이후 E2EE가 기본이지만, 오래된 것은 개별적으로 확인이 필요합니다. 현재 공식 FAQ에서는 표준 암호화된 저널을 직접 전환하는 대신 새로운 E2EE 저널에 항목을 복사하는 방법을 안내하고 있습니다.
SimpleMemo에서 나에게 보내는 메일이 E2EE인가요?
아니요. Outbox와 전송 기록의 기기 내 암호화 및 이메일 전송은 별개입니다. 본문은 API와 외부 배포 플랫폼을 통해 전송되고, 메일 서비스 측에도 복사본이 남습니다. 받은 편지함과 연동 대상의 보호·공유 설정도 확인해 주세요.
관련 기사
