# 라바 램프의 무용성: 무작위가 실제로 의미하는 것 > Clean Markdown view of GeekNews topic #29593. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29593](https://news.hada.io/topic?id=29593) - GeekNews Markdown: [https://news.hada.io/topic/29593.md](https://news.hada.io/topic/29593.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-18T00:04:15+09:00 - Updated: 2026-05-18T00:04:15+09:00 - Original source: [loup-vaillant.fr](https://loup-vaillant.fr/articles/lava-lamps-and-randomness) - Points: 1 - Comments: 1 ## Topic Body - Cloudflare의 lava lamp 기반 난수 홍보는 인터넷 암호화에 큰 실질 기여를 하기보다 **마케팅과 보안 연극**에 가깝다 - 암호화에서 중요한 것은 값의 본질적 무작위성보다 **공격자가 그 값에 대해 얼마나 알고 있는지**이며, 이 지식 차이가 보안성을 좌우함 - **One-time pad**는 충분히 무작위인 키를 한 번만 쓰면 원문 정보를 숨기지만, 같은 키를 재사용하면 관찰된 정보와 결합돼 깨짐 - 현대 시스템은 일회용 패드 대신 **CSPRNG**와 스트림 암호를 쓰며, ChaCha20이나 AES-256-CTR은 256비트 키로 현실적 보안을 제공함 - 물리적 true RNG는 편향 제거가 어렵고 보안 증가도 작아, 서버가 직접 시드를 만들고 **fast key erasure**를 쓰는 단순한 설계가 더 안전함 --- ### 무작위성은 대상보다 관찰자의 지식에 달림 - Cloudflare는 [lava lamp](https://www.cloudflare.com/en-gb/learning/ssl/lava-lamp-encryption/)가 인터넷 암호화에 도움을 준다고 홍보하지만, 이 방식은 보안에 크게 기여하기보다 **마케팅과 보안 연극**에 가깝다 - Cloudflare는 lava lamp 외에도 [double pendulums](https://blog.cloudflare.com/harnessing-office-chaos/#londons-unpredictable-pendulums), [wave motion](https://blog.cloudflare.com/chaos-in-cloudflare-lisbon-office-securing-the-internet-with-wave-motion/), [mobiles](https://blog.cloudflare.com/harnessing-office-chaos/#austins-mesmerizing-mobiles) 같은 물리적 예측 불가능성 장치를 사용함 - `return 4`만 하는 [XKCD식 함수](https://xkcd.com/221/)는 항상 4를 반환하므로 대상 자체로는 무작위가 아니지만, 호출자가 “공정한 주사위로 고른 상수”라는 정보만 알고 한 번 호출했다면 관찰자의 확률 분포에서는 무작위로 다뤄질 수 있음 - 암호화에서 중요한 질문은 **결과가 본질적으로 무작위인지**가 아니라, 공격자가 그 결과에 대해 얼마나 알고 있는지임 - 같은 값이라도 누가 어떤 정보를 갖고 있는지에 따라 무작위성의 의미가 달라지고, 암호 시스템에서는 이 지식 차이가 보안성을 결정함 ### One-time pad가 작동하고 깨지는 방식 - 러시안 룰렛 비유에서 공범은 총알 위치를 알고 있고, 플레이어와 사전에 공유한 주사위 값을 총알 위치에 더한 결과만 외부에 말함 - 플레이어는 외친 값에서 주사위 값을 빼 총알 위치를 복원할 수 있지만, 상대는 주사위 값을 모르므로 외친 값만으로 총알 위치를 알 수 없음 - 공정한 주사위라면 상대가 가진 사전확률 `P(Ci)`와 특정 숫자 `S3`을 들은 뒤의 사후확률 `P(Ci|S3)`가 같아짐 - 베이즈 공식으로는 `P(Ci|S3) = P(Ci) × 1/6 ÷ 1/6 = P(Ci)`가 되어, 상대는 외친 값을 듣고도 **아무 정보도 배우지 못함** - 이 구조가 [One-time pad](https://en.wikipedia.org/wiki/One-time_pad)의 핵심이며, 충분히 무작위인 키를 메시지와 한 번만 결합하면 암호문이 원문 정보를 드러내지 않음 - 같은 키를 두 번째 게임에도 재사용하면 첫 게임에서 드러난 정보 때문에 상대가 주사위 값의 가능 범위를 좁힐 수 있음 - 첫 게임에서 총의 앞 네 칸이 비어 있음이 확인되면 상대는 주사위가 3이나 4였을 가능성만 남았다고 알 수 있고, 두 번째로 공범이 “Four”를 외치면 총알이 첫 번째 칸 또는 마지막 칸 중 하나라는 정보까지 얻게 됨 - **One-time pad**는 이름 그대로 한 번만 안전하며, 같은 키를 재사용하면 관찰된 암호문과 이전 정보가 결합되어 보안성이 무너짐 ### 키 길이와 현대 암호화의 현실적 보안 - 인터넷에서는 총알 위치 대신 비트와 바이트를 보내며, 한 비트의 “yes/no” 메시지는 동전 던지기 하나로 숨길 수 있음 - 앞면이면 메시지를 그대로 두고, 뒷면이면 “yes”와 “no”를 뒤집는 방식은 동전 결과를 모르는 관찰자에게 원문을 숨김 - 하지만 같은 동전 결과로 두 비트를 암호화하면 암호문은 네 가지 원문 가능성을 두 가지로 줄임 - “Yes yes”는 원문이 “yes yes” 또는 “no no”였음을 뜻함 - “No no”는 원문이 “no no” 또는 “yes yes”였음을 뜻함 - “Yes no”는 원문이 “yes no” 또는 “no yes”였음을 뜻함 - “No yes”는 원문이 “no yes” 또는 “yes no”였음을 뜻함 - 일반화하면 n비트를 단일 동전 던지기 하나로 암호화할 때 가능한 원문 공간은 `2^n`에서 2개로 줄어듦 - 완전한 정보이론적 의미에서 n비트를 제대로 암호화하려면 **n비트 키**가 필요하며, 그보다 긴 메시지는 일부가 복호화되고 관찰자가 이미 n비트 이상의 정보를 알고 있다면 대체로 전체가 복호화될 수 있음 - Cloudflare가 처리하는 트래픽 전체에 일회용 패드를 적용하려면 천문학적 양의 무작위 수가 필요해 보이지만, 현대 시스템은 일회용 패드를 쓰지 않음 - 인증 암호화와 스트림 암호를 올바르게 쓰면 256비트 키로 많은 데이터를 현실적으로 안전하게 암호화할 수 있음 - **ChaCha20**이나 **AES-256-CTR** 같은 적절한 스트림 암호를 쓰면 수동 관찰자는 원문을 찾기 위해 약 `2^255`개 조합을 시도해야 함 - 키를 아는 사람에게 스트림은 완전히 예측 가능하지만, 키를 모르는 지구 문명 수준의 관찰자에게는 완전히 예측 불가능한 “엔트로피”처럼 동작함 - 이 방식의 공식 이름은 **Cryptographically Secure Pseudo-Random Number Generator**, 줄여서 **CSPRNG**임 ### 실제 난수 생성과 fast key erasure - 256비트 마스터 키 하나에서 필요한 무작위 수를 파생하려면 마스터 서버나 하드웨어 보안 모듈에 마스터 키를 두고, 로컬 키 스트림을 생성해 회사 전체에 안전하게 배포할 수 있음 - 각 서버나 CPU 코어는 256비트 로컬 키와 카운터로 필요한 만큼 무작위 바이트를 생성할 수 있음 - 핵심 문제는 **안전한 배포**가 매우 어렵다는 데 있음 - 로컬 키가 유출되면 해당 머신이 과거에 암호화한 모든 메시지와 앞으로 암호화할 메시지가 위험해지고, 마스터 키가 유출되면 피해가 훨씬 커짐 - [fast key erasure](https://blog.cr.yp.to/20170723-random.html)는 키 유출 가능성과 유출 시 피해를 줄이기 위한 절차임 - 512바이트 버퍼 시작 부분에 32바이트 무작위 시드를 둠 - 그 시드로 512바이트를 생성해 버퍼를 덮어씀 - 첫 32바이트를 제외한 나머지를 요청에 따라 출력한 뒤 지움 - 버퍼를 다 쓰면 다시 생성 단계로 돌아감 - “erasure”는 생성 단계가 기존 키를 지워버리는 데서 나옴 - 버퍼가 유출되면 미래 메시지는 위험해질 수 있지만, 이미 출력되고 지워진 과거 값은 보호됨 - 더 중요한 주의점은 버퍼를 복제하지 않는 것임 - 같은 시드로 두 스트림을 만들지 않아야 함 - 프로세스를 포크할 때 스트림을 적절히 둘로 나눠야 함 - 같은 스트림이 둘 이상 생기면 동일한 무작위 바이트가 반복되어 치명적일 수 있음 - 이 때문에 사용자 공간 RNG는 권장되지 않으며, 커널 RNG는 쉽지는 않아도 감사해야 할 대상 수가 더 적음 ### 스트림 암호 선택과 보안 여유 - 기반 스트림 암호의 내부 블록 크기도 중요함 - **ChaCha20**의 512비트 블록은 걱정하지 않아도 될 만큼 크고, **AES**의 128비트 블록도 충분히 큼 - AES에는 단순 무차별 대입보다 성공 확률이 훨씬 나은 현실적 공격이 있으며, AES-128은 깨질 수 있지만 AES-256은 안전하다고 봄 - 더 작은 블록 크기는 이 용도에서는 깨진 것으로 봐야 함 - 권장 선택지는 ChaCha20 또는 AES-256이며, 선호는 ChaCha20 쪽임 - 현대 스트림 암호는 매우 안전하고, 학술 문헌과 여러 정부, 특히 미국의 사용 사례까지 고려하면 가까운 미래에 깨질 가능성은 매우 낮다고 봄 - CSPRNG와 암호화가 모두 암호에 의존하므로, 그중 하나가 깨지면 전체 시스템도 깨짐 - AES-256이나 ChaCha20이 가까운 미래에 깨질 가능성이 의미 있게 있다고 가정한다면 보안 여유를 늘리는 선택지는 있음 - CSPRNG와 암호화에 같은 암호를 쓰면 공격자가 AES와 ChaCha 중 하나만 깨면 되는 선택지를 없애고 특정 하나를 깨야 하게 만듦 - 라운드 수를 늘리면 무차별 대입 비용뿐 아니라 무차별 대입보다 나은 공격을 막는 데 도움이 됨 - AES-256은 14라운드, ChaCha20은 20라운드를 사용함 - ChaCha7에는 exhaustive search보다 나은 공격이 있지만, ChaCha8에는 현재 그런 공격이 없음 - ChaCha20은 20라운드를 사용해 갑자기 12라운드 공격이 발견되더라도 문제가 없도록 여유를 둠 - 여러 시스템을 병렬로 쓰는 방식은 전체 복잡도를 크게 높이고, 그 복잡도가 구성 요소 중 하나에 대한 수학적 공격보다 치명적 취약점을 만들 가능성이 더 큼 ### 물리적 true RNG와 초기 시드 - 물리적 true RNG가 이론적으로 깨질 수 있는 CSPRNG보다 더 안전하다는 생각은 조심해야 함 - 무작위 출력은 보안을 위해 탐지 가능한 편향이 없어야 하는 경우가 많으며, 이는 `2^64`개 샘플을 분석해도 편향을 감지할 수 없을 정도로 균일한 분포를 뜻함 - 물리 과정을 그런 수준으로 조정하기는 어렵기 때문에 실제로는 노이즈 소스 출력을 암호학적 해시로 통과시켜야 함 - fast key erasure를 쓰는 스트림 암호와 비교하면 보안 증가는 작고, 필요에 따라 성능 비용은 클 수 있음 - 임의의 양의 무작위 수를 만들려면 처음 몇 바이트의 시드는 필요함 - 예측 불가능한 소스를 충분히 오래 디지털 기록해 256비트 이상의 엔트로피를 얻고, 그 기록을 SHA-256이나 BLAKE2s 같은 256비트 해시로 해시하면 마스터 시드를 만들 수 있음 - 가능한 무작위 소스는 [hardware random number generator](https://en.wikipedia.org/wiki/Hardware_random_number_generator), CPU jitter, 임의의 나무 사진, beam splitter, 키 입력이나 마우스 이벤트, 주사위 등임 - 사이트 간 무작위 수 배포는 실용적이지 않고, 복잡할 뿐 아니라 침해 원인이 될 수 있음 - 무작위 수는 한 번만 필요한 것이 아니라 침해가 의심되거나 중요한 보안 업데이트를 할 때마다 필요함 - 번거로움과 위험을 줄이려면 외부에서 가져오기보다 해당 컴퓨터가 직접 사용할 무작위 시드를 생성하는 편이 대체로 더 좋음 - 일반적인 서버에는 CPU jitter, 주변장치 상호작용, 네트워크 이벤트가 있어 보통 용도에는 충분함 - 추가 보안을 원하면 서버 랙마다 하드웨어 RNG 동글 몇 개를 더할 수 있지만, 그보다 복잡한 방식은 불필요한 복잡성임 ### Lava lamp 벽이 불필요한 이유 - Cloudflare의 lava lamp 벽은 필요하지 않으며, 로컬 네트워크를 통해 서버에 연결하면 추가 복잡성과 공격 표면만 늘어남 - 제대로 구현하면 위험은 매우 낮을 수 있지만, 그래도 얻는 이익보다 위험이 큼 - Cloudflare가 보안에 진지하다면 lava lamp 사용을 중단하고, 장식과 마케팅 용도로만 남겨야 함 - 서버는 각자 직접 무작위 수를 생성하는 편이 더 단순하고 더 안전함 - Cloudflare가 이미 그렇게 하고 있을 가능성도 있음 ## Comments ### Comment 57643 - Author: neo - Created: 2026-05-18T00:04:16+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/obxoph/futility_lava_lamps_what_random_really) - 이 글은 잘못 알고 쓴 데다 약간 흥을 깨는 글처럼 보임. **현대 난수 생성**은 여러 독립적인 엔트로피원을 쓰고, 컴퓨터가 동작하는 동안 이를 계속 엔트로피 풀에 해시로 섞어 넣음 컴퓨터에 단 하나의 “무작위 시드”가 있는 게 아니라, 실행 중에 `seed = hash(seed, new_data)` 같은 방식으로 여러 소스의 엔트로피를 이용해 계속 다시 시드됨. 라바 램프를 촬영한 카메라 데이터를 추가한다고 해서 시스템 보안이 절대 낮아지지 않음. 엔트로피 풀에 들어간 데이터는 이미 들어간 다른 데이터와 함께 해시됨. 공격자가 모르는 정보가 아주 조금이라도 있으면 안전하도록 설계되어 있어서, 무작위성이 제각각인 데이터를 많이 섞어도 보안은 손상되지 않음 **라바 램프**는 시스템 보안을 해치지 않고, 개인적으로는 시스템의 일부를 이루는 즐겁고 기능적인 예술 작품이라고 봄. 난수 품질도 극히 미세하게 올려 주며, 무작위성과 엔트로피 개념을 시각적으로 보여 줌 - 맞지만, **커널 난수 생성기**들은 이미 30년 넘게 다양한 하드웨어 무작위성을 사용해 왔고, 얼마나 “계속” 또는 “끊임없이” 재시드되는지는 과장하지 않는 게 좋음 하드웨어에서 무작위성은 계속 수집되지만, Linux 난수 생성기는 주기적으로 재시드됨. 부팅 후 첫 1분 동안은 몇 초마다, 이후에는 1분에 한 번 정도로 느려짐 https://www.zx2c4.com/projects/linux-rng-5.17-5.18/inside-linux-kernel-rng-presentation-sept-13-2022.pdf - 기존 시스템이 그렇지 않다고 말하거나 암시했다는 인상을 어디서 줬는지 모르겠음. 여기서는 라바 램프 부분을 제외하면 기존 시스템을 설명하려던 게 아니라, 실제로 우리에게 필요한 것이 얼마나 적은지, 즉 **256비트**면 된다는 점을 강조하고 싶었음 라바 램프를 촬영한 카메라 데이터를 추가해도 보안이 줄지 않는다는 말에는 **공격 표면**이 떠오름. 임베디드 컴퓨터와 그 컴퓨터와 서버 사이의 네트워크 통신을 추가하는 셈임. 내게는 이렇게 더해지는 낮은 위험이, 실제로 라바 램프가 필요해질 말도 안 되게 낮은 위험보다 훨씬 커 보임 - 철학적 구분을 다르게 표현하면 이렇게 됨: 가능한 결과가 몇 개인가, 그리고 결과가 얼마나 예측 가능한가 암호학적 목적에서는 예측 가능성을 2^-256 수준으로 정착시켰지만, 흥미롭게도 가능한 결과 수가 훨씬 더 큰 흔한 과정들이 있고, 아무리 가능성이 낮아도 모든 가능한 결과를 낼 수 있기를 원할 때가 있음. 그런 상황에서는 **암호학적 무작위성**이 부족할 수도 있음 표준 카드 한 벌은 52!개의 섞임이 있고, 이는 약 2^226이라 암호학적으로 무작위인 시드로 모든 섞임을 만들 수 있음. 하지만 Uno를 하거나 여러 벌의 카드를 함께 섞으면 256비트 난수 생성기는 모든 섞임을 만들 만큼 상태가 충분하지 않음. 시스템의 사용자 공간 무작위성이 전부 커널에서 오고, 커널이 모든 하드웨어 무작위성을 256비트 CSPRNG로 흘려보낸다면, Las Vegas에서 카드를 섞기에는 충분하지 않을 수도 있음 :-) 글에서 빠진 것은 **재시드**인데, 빠른 키 삭제와 상호작용하는 방식, 그리고 초기 시드를 얻는 어려움을 보여 준다는 점에서 흥미로운 주제임. 글은 Linux가 CPU 지터만 쓰는 듯 암시하지만 이는 지나친 단순화임. Linux는 많은 무작위성 소스를 쓰고, 지터 춤은 최후의 수단으로만 사용함 - 그렇지 않음. 현실에서는 절대로 그런 식으로 하지 않음 실제 세계에서는 2^128개의 표본조차 얻을 수 없음. 사실 그보다 훨씬 적고, 그래서 AES-128도 여전히 많은 용도에 충분히 안전함. 가능한 결과 수가 2^256보다 클 때 “모든 가능한 결과를 실행”한다는 건 완전히 **불가능**함. 잊어버리는 게 좋음. 그런 건 존재하지 않음 블랙잭에서 카드 한 벌이 아니라 6벌을 쓸 때도, 실제로 모든 가능한 섞임에 확률을 균등하게 분포시키는 섞기 과정을 원하는 게 아님. 가능한 한 많이 표본을 뽑아 봐도 차이를 구분할 수 없을 만큼 좋은 분포면 됨. 섞임 수가 2^256, 심지어 2^128로 제한되어도 차이를 못 느낄 것임 글에서 재시드를 뺀 것은 의도적임. 의심되는 침해와 일부 보안 업데이트 같은 특정 시점에만 재시드가 필요함. 난수 생성기 상태를 비휘발성 메모리에 유지하는 것보다 더 단순하거나 안전하다면 재부팅 때도 해당됨. 그래서 “재시드”라고 하기보다는 새 초기 시드로 다시 시작한다고 보는 편을 선호함 정상 동작 중 재시드는 전혀 필요하지 않음. 구현해 봐야 복잡성만 늘어남 Linux가 CPU 지터만 쓴다는 암시는 확인했어야 했음. 내가 이해한 바로는 **부팅 시점**에는 그게 유일하다고 봤음. 특히 사용자 입력과 네트워크 입력이 있기 전에는 그렇다고 생각했음. 알고 있는 다른 소스가 있나? 하드웨어 난수 생성기 지원은 이미 있을 것 같음 - 가능성과 예측 가능성의 구분을 보니 [Shamir, Rivest, Adleman의 논문](https://people.csail.mit.edu/rivest/pubs/SRA81.pdf)이 떠오름. 이 논문은 두 사람이 전화로 가상 카드 덱을 이용해 안전한 포커를 치는 것이 수학적으로 불가능하다고 증명함 할 수 없음. 그런데 그 점은 제쳐 두고, 안전하게 하는 방법은 이렇다… - 흥미로움. 기억이 맞다면 진짜 무작위 소스를 읽는 것은 **블로킹 작업**이라, 커널에 무작위 바이트가 충분하지 않으면 충분한 무작위성을 읽을 때까지 시간이 꽤 오래 걸릴 수 있음 추측하자면, 난수 생성 하드웨어 카드는 비트 밀도뿐 아니라 단위 시간당 비트 수로도 측정되는 병렬 무작위성 소스를 얻기 위해 존재했을 것 같음 - 개별 주장 중 크게 동의하지 않는 부분은 많지 않지만, 전체 논지는 흐릿하게 느껴졌음. 글은 “현대 암호는 사람들이 생각하는 것보다 훨씬 적은 진짜 무작위성만 필요하다”를 중심으로 쌓아 올린 뒤, “따라서 라바 램프는 **공격 표면**을 넓히므로 더 나쁘다”로 착지함 두 주장 모두 참일 수 있지만, 결론으로 이어지는 흐름은 거칠게 느껴짐 - 솔직히 **서사 구조**가 별로 만족스럽지는 않음. 그래도 결론의 절반은 제목에 이미 써 두긴 했음 - **LavaRand**는 20년도 더 전에 이미 이런 일을 하고 있었음. 당시에는 귀여웠지만, 그 시절 카메라 센서는 훨씬 작았고 렌즈 등의 예측 가능한 특성 때문에 엔트로피 소스로는 좋지 않았음 [라바 램프를 좋아하긴 하지만](https://jmtd.net/log/lavalamps/more/), 수백 개짜리 벽의 전력 소모는 장난감 같은 장치치고는 꽤 크다고 봄 - 자기 홍보에 가까움. 링크를 거의 공유하지 않다가, 공유할 때는 자기 링크를 올림. 최근 5개 게시물 중 5개가 자기 자료를 가리킴 - “stories and comments”를 어떻게 해석하느냐에 달려 있음 “저자가 커뮤니티에 참여하는 것은 좋지만, 제품 발표나 자기 작업으로 트래픽을 몰기 위한 쓰기 전용 도구로 악용해서는 안 된다. 경험칙상 자기 홍보는 자신의 stories와 comments의 4분의 1 미만이어야 한다.” 게시글 15개에 댓글 1399개라면 분명 커뮤니티에 참여하고 있음. 자기 게시글마다 자기 댓글을 90개 넘게 달고 있는 게 아니라면 말임 - Cloudflare는 라바 램프에서 얻은 엔트로피를, University of Chile는 지진 데이터를, 기억이 맞다면 EPFL은 **방사성 붕괴** 측정값을, 그 밖의 여러 참여자는 다양한 자료를 drand 네트워크의 최초 키 생성식에 기여했음 CSPRNG를 쓸 수도 있었을까? 물론임. 하지만 그러면 재미가 어디 있나? - 재미는 괜찮음. 라바 램프는 예쁘고, 그들의 파동 벽은 정말 아름다움. 선을 넘는 지점은 그것이 실제로 **보안에 도움이 되는 척**할 때임