boho: 설계 배경과 기초 원리

boho는 개발자가 직접 관리하는 장치와 애플리케이션 사이에 암호화와 인증을 적용하기 위한 공유 키 기반 라이브러리입니다. 이름은 ‘보호’에서 왔습니다. Arduino용 C/C++ 구현과 Node.js·브라우저용 JavaScript 구현을 제공하므로, DIY 장치에서 웹앱까지 같은 방식으로 암호화 메시지를 주고받을 수 있습니다.

boho의 출발점은 다음 질문입니다.

통신할 양쪽의 코드를 직접 관리하고 비밀 키도 미리 설정할 수 있다면, 연결할 때마다 공개키 기반의 신뢰 체계를 구성해야 할까?

이런 환경에서는 사전 공유 키를 사용하는 대칭키 방식으로도 필요한 암호통신을 구성할 수 있습니다. boho는 이 전제를 바탕으로 SHA-256, XOR 연산, 공유 키 인증, 바이너리 메시지 형식을 하나의 작은 구성으로 묶습니다.

이 문서는 boho가 필요한 이유와 기초 원리를 소개합니다. IOSignal의 접속 인증 설정은 인증을, 실제 메서드 사용은 클라이언트 API를 참고하세요. 대칭키 방식이 적합한 환경이라는 판단과 현재 boho 구현의 보안 강도에 대한 평가는 별개입니다. boho는 표준 SHA-256을 사용하는 자체 프로토콜이며, 그 조합 전체가 표준 암호 방식으로 검증되었다는 뜻은 아닙니다.

1. 이미 많은 암호 기술이 있는데 왜 만들었을까?

암호 알고리즘이 존재하는 것과 작은 장치에서 실제 암호통신을 구현하는 것은 다른 문제입니다. 개발자는 암호화 외에도 상대 인증, 키 설정, 메시지 형식, 통신 라이브러리, 메모리 사용량, 배포 후 관리를 연결해야 합니다.

예를 들어 Arduino로 만든 센서와 직접 작성한 웹앱을 연결한다고 생각해 봅시다. 개발자는 양쪽 프로그램을 알고 있고, 장치에 키를 기록할 수 있으며, 웹앱에도 별도 절차로 같은 키를 설정할 수 있습니다. 이 경우 처음 만나는 불특정 상대와 신뢰 관계를 만드는 기능보다, 이미 정한 상대끼리 키를 확인하고 데이터를 보호하는 기능이 먼저 필요합니다.

boho는 이런 개발 환경에 초점을 맞춥니다.

• 장치와 애플리케이션이 미리 공유한 키로 상대를 인증합니다.
• SHA-256을 바탕으로 데이터 길이에 맞는 키스트림을 생성하고 XOR로 암호화합니다.
• Arduino, Node.js, 브라우저에서 서로 호환되는 메시지 형식을 사용합니다.
• 암호화 처리를 전송 수단과 분리하여 TCP, WebSocket, 직렬 통신, MQTT 페이로드 등에 적용할 수 있게 합니다.
• 연결 단위의 보호와 별도 데이터 키를 사용하는 종단간 암호화를 제공합니다.

차별점은 XOR나 공유 키라는 개념 자체의 새로움에 있지 않습니다. 직접 만든 임베디드 장치와 웹 환경을 같은 암호화·인증 방식으로 연결하는 구현과 사용 방식에 있습니다. 연결 관리와 메시지 전달까지 필요한 경우에는 boho를 사용하는 IOSignal을 함께 활용할 수 있습니다.

2. 공개키 교환 없이도 통신할 수 있는 환경

대칭키 암호화는 양쪽이 같은 비밀 키를 가지고 있다는 전제에서 출발합니다. 핵심 과제는 최초에 그 키를 어떻게 안전하게 전달하고, 이후 어떻게 보관·교체할 것인가입니다. 이 과제를 다른 경로로 해결할 수 있다면 모든 통신 연결에 공개키 교환을 넣을 필요는 없습니다.

환경	공유 키를 설정하는 방법의 예	대칭키 방식이 맞는 이유
직접 제작하는 임베디드 장치	제작·설치 시 USB, 직렬 연결, 신뢰할 수 있는 설정 도구로 장치별 키 주입	개발자가 장치와 접속 서버를 모두 관리함
직접 개발하는 웹앱과 개인 장치	사용자가 별도 경로로 받은 장치 키를 웹앱에 입력하거나 신뢰할 수 있는 페어링 절차로 등록	통신 대상이 정해져 있고 최초 키 공유를 직접 관리할 수 있음
관리 주체가 같은 서버 사이	SSH, 기존 TLS 연결, 비밀 관리 시스템 등으로 키 배포	이미 보호된 관리 경로가 존재함
제한된 장치·사용자 그룹	장치 또는 통신 상대별로 키를 발급하고 폐기·교체 절차를 운영	불특정 상대를 위한 공개 신뢰 체계가 필수 조건이 아님

이런 환경에서는 충분한 엔트로피를 가진 키와 적절한 인증·메시지 보호 방식을 사용하여, 사전 공유 대칭키만으로도 안전한 통신을 설계할 수 있습니다. 다만 키를 공유한 주체는 같은 자격을 갖습니다. 여러 장치에 하나의 키를 넣으면 어느 장치가 보낸 것인지 키만으로 구분할 수 없고, 한 장치의 키 유출이 다른 장치에도 영향을 줍니다.

‘신뢰하는 제3자가 필요 없다’는 말은 인증기관이 없어도 개발자가 직접 키를 배포하고 상대를 정할 수 있다는 뜻입니다. 신뢰가 사라지는 것이 아니라, 인증기관 대신 키를 설정하는 경로와 양쪽 프로그램을 신뢰하는 구조입니다.

웹앱에서는 코드를 직접 작성한다는 사실만으로 키가 비밀이 되지는 않습니다. 공개 JavaScript 번들에 공통 비밀 키를 넣으면 방문자가 그 키를 읽을 수 있습니다. 키 설정 방법과 함께 웹앱 코드 자체의 안전한 전달도 필요합니다.

3. XOR: 아주 단순한 연산으로 암호화와 복호화하기

XOR는 두 비트가 다르면 1, 같으면 0을 만드는 연산입니다. 같은 값으로 두 번 XOR하면 원래 값으로 돌아온다는 성질이 있습니다.

암호화: 암호문 = 평문 XOR 키스트림
복호화: 평문   = 암호문 XOR 키스트림

(평문 XOR 키스트림) XOR 키스트림 = 평문

1바이트 예제로 보면 다음과 같습니다.

평문       01000001    0x41, 문자 A
키스트림   10100110    0xA6
           --------
암호문     11100111    0xE7

암호문     11100111
키스트림   10100110
           --------
복호화     01000001    0x41, 문자 A

연산은 매우 단순하지만, 적절한 키스트림과 결합하면 강력한 암호화의 기반이 됩니다. 안전성을 결정하는 것은 XOR의 복잡도가 아니라 키스트림을 어떻게 만들고 사용하는가입니다.

진짜 OTP의 강점과 현실적인 부담

일회용 패드(One-Time Pad, OTP)는 평문과 독립적인 완전한 무작위 비트열을 키로 사용합니다. 키가 데이터만큼 길고, 비밀로 유지되며, 한 번만 사용된다는 조건을 만족하면 암호문만으로 평문을 판별할 수 없는 완전한 비밀성을 제공합니다. 여기서 OTP는 일회용 로그인 비밀번호가 아니라 ‘일회용 패드’를 뜻합니다.

문제는 키의 크기입니다. 1MB 데이터를 보내려면 양쪽이 1MB의 새 무작위 키를 안전하게 공유해야 합니다. 다음 1MB를 보낼 때는 또 다른 키가 필요합니다. 지속적으로 통신하는 작은 장치에서 이런 키를 미리 저장하고 공급하기는 어렵습니다.

같은 패드를 재사용하면 다음 관계가 드러납니다.

C1 = P1 XOR S
C2 = P2 XOR S

C1 XOR C2 = P1 XOR P2

키스트림 S가 없어지고 두 평문의 관계가 노출됩니다. 따라서 짧은 고정 키를 반복해서 XOR하는 방식과 OTP는 전혀 다른 안전성을 가집니다.

4. 해시 출력으로 ‘가상 OTP’를 만들기

SHA-256은 입력을 256비트, 즉 32바이트의 해시값으로 변환합니다. 동일한 입력은 동일한 결과를 만들며, 입력을 바꾸면 출력도 크게 달라집니다. SHA-256 자체는 데이터를 복호화할 수 있는 암호 알고리즘이 아니라 해시 알고리즘입니다. SHA-256의 표준 정의: NIST FIPS 180-4

충분히 예측하기 어려운 비밀 입력을 해시에 넣으면 그 출력을 키스트림의 재료로 사용하는 구성을 생각할 수 있습니다. 여기에 메시지마다 달라지는 값과 블록 번호를 결합하면 필요한 길이만큼 출력을 생성할 수 있습니다.

공유한 비밀 키 + 메시지별 값
              ↓
       해시 기반 생성 과정
              ↓
  블록 1 | 블록 2 | 블록 3 | …
              ↓
    데이터 길이만큼 키스트림 사용
              ↓
          평문과 XOR

송신자와 수신자가 같은 키와 메시지별 값을 사용하면 같은 키스트림을 재현할 수 있으므로, 데이터 전체 길이에 해당하는 패드를 따로 전송하거나 저장할 필요가 없습니다.

다만 공개된 랜덤 값만 해시해서는 암호화용 비밀 키스트림이 되지 않습니다. 누구나 같은 값을 계산할 수 있기 때문입니다. 랜덤 값이나 nonce는 메시지를 구분하는 재료이고, 키스트림을 비밀로 만드는 핵심 입력은 공유 비밀 키입니다. 해시는 부족한 비밀 정보나 약한 비밀번호에 새로운 엔트로피를 만들어 주지도 않습니다.

이 문서에서 ‘가상 OTP’ 또는 ‘유사 OTP’는 이렇게 생성한 의사난수 키스트림을 설명하기 위한 표현입니다. 짧은 비밀로 긴 출력을 생성하므로 진짜 OTP의 정보이론적 안전성을 갖지는 않습니다. 안전성은 키의 강도, 생성 방식, 입력의 재사용 여부와 전체 프로토콜에 의존합니다.

키스트림을 생성하여 XOR한다는 큰 구조는 스트림 암호에서도 사용됩니다. 예를 들어 ChaCha20도 키·nonce·카운터로 키스트림을 만들고 평문과 XOR합니다. 다만 boho의 SHA-256 조합과 ChaCha20은 서로 다른 구성입니다. RFC 8439 §2.4

5. boho는 이 원리를 어떻게 구현하는가?

아래 내용은 JavaScript boho 2.2.0과 Arduino boho 0.8.0의 구현을 기준으로 합니다. 기호 ||는 바이트열 연결을 뜻합니다.

5.1 공유 키와 메시지별 값으로 시작점 만들기

일반적인 set_key 경로에서는 입력 키를 SHA-256으로 해시하여 32바이트 내부 키를 만듭니다. 이 키에 12바이트 salt12를 붙여 다시 해시합니다.

K = SHA256(입력 키)              // set_key 경로
B = SHA256(K || salt12)          // 메시지의 키스트림 생성 기준값

salt12의 구성은 다음과 같습니다.

구성 요소	크기	역할
초 단위 시각	4바이트	메시지별 시간 정보
밀리초	2바이트	시간 정보의 세분화
카운터	2바이트	가까운 시각에 생성한 메시지 구분
nonce	4바이트	메시지 또는 연결에 관련된 구분 값

이 값들은 비밀 키가 아닙니다. 수신자가 같은 키스트림을 재현하기 위해 메시지 또는 인증 과정에서 얻는 정보입니다. 같은 내부 키 아래에서 전체 salt12가 반복되면 같은 키스트림이 만들어지므로, 메시지·방향·장치·재시작을 가로지르는 중복 여부가 중요합니다.

5.2 32바이트씩 생성하여 XOR하기

boho는 기준값 B에 1부터 시작하는 4바이트 블록 번호를 붙여 SHA-256을 계산합니다. JavaScript와 호환되는 바이트 순서는 little-endian입니다.

S1 = SHA256(B || LE32(1))
S2 = SHA256(B || LE32(2))
S3 = SHA256(B || LE32(3))
…

S = S1 || S2 || S3 || …          // 평문 길이만큼 사용
C = P XOR S
P = C XOR S

예를 들어 평문이 70바이트라면 32바이트 블록 두 개와 세 번째 블록의 앞 6바이트를 사용합니다. 복호화도 동일한 키스트림을 생성하여 XOR합니다. 해시를 역산하는 과정은 없습니다.

소스에서는 resetOTP, JavaScript의 getIndexOTP 또는 Arduino의 generateIndexOTP, 그리고 xotp가 이 흐름을 담당합니다. Arduino 구현은 키스트림을 32바이트씩 계산하므로, 전체 키스트림을 별도 버퍼로 보관할 필요가 없습니다. 입력·출력 패킷 버퍼 등 통신에 필요한 메모리는 별도로 필요합니다.

5.3 암호화와 메시지 검증

XOR만으로는 변조를 검출할 수 없습니다. 공격자가 암호문의 비트를 뒤집으면 복호화된 평문의 해당 비트도 뒤집힙니다. boho는 이를 확인하기 위한 태그를 패킷에 포함합니다.

현재 데이터 패킷의 태그 계산은 다음과 같습니다.

T = SHA256(K || salt12 || 평문)의 앞 8바이트

수신자는 복호화한 데이터로 태그를 다시 계산하여 비교합니다. 응용 프로그램은 검증에 성공한 데이터만 사용해야 합니다.

소스의 generateHMAC, getHMAC8, 패킷의 hmac이라는 이름은 기존 명칭입니다. 이 프로토콜 태그는 표준 HMAC이 아닙니다. 표준 HMAC은 별도의 내부·외부 패드를 사용하는 다른 구조입니다. 태그 길이가 8바이트라는 점도 SHA-256의 32바이트 출력 길이와 구분해야 합니다. 표준 HMAC 정의: RFC 2104 §2

5.4 공유 키를 확인하는 상호 인증

연결 인증에서는 서버와 클라이언트가 challenge와 nonce, 공유 키로 계산한 태그를 교환합니다.

서버         → 클라이언트 : SERVER_TIME_NONCE — 서버 시각과 challenge
클라이언트   → 서버       : AUTH_REQ — ID, 클라이언트 nonce, 인증 태그
서버         → 클라이언트 : AUTH_RES — 서버의 응답 인증 태그
클라이언트                : 응답 검증 후 인증 상태로 전환

서버는 해당 ID에 설정된 키로 요청을 검증하고, 클라이언트는 같은 공유 키에 기반한 서버 응답을 검증합니다. 이 과정에서 공유 키 자체를 전송하지는 않습니다. 인증 태그는 데이터 패킷과 달리 32바이트를 사용합니다.

여기서 인증하는 것은 미리 설정한 키를 알고 있는 상대입니다. 외부 인증기관이 보증한 도메인이나 실명 신원을 확인하는 방식은 아닙니다. 또한 새 공유 키를 공개키 방식으로 교환하는 절차도 아닙니다.

5.5 목적에 따라 나뉘는 메시지 형식

기능	API	용도	평문 외 추가 크기
독립 데이터 암호화	encryptPack / decryptPack	개별 메시지, 저장 데이터	25바이트
인증된 연결의 메시지	encrypt_488 / decrypt_488	인증 후 클라이언트–서버 통신	21바이트
별도 데이터 키 암호화	encrypt_e2e / decrypt_e2e	최종 송수신자 사이의 본문 보호	내부 ENC_PACK 기준 25바이트

ENC_PACK은 salt12 전체를 전송합니다. ENC_488은 인증에서 얻은 상대 nonce를 이용하므로 패킷에는 시간·카운터 8바이트만 담습니다. E2E를 IOSignal로 전달할 때에는 라우팅 정보와 전송 계층의 크기가 추가됩니다.

6. TLS의 편리함과 작은 시스템에서의 부담

TLS는 미리 비밀 키를 나누지 않은 상대와 보호된 연결을 만드는 문제를 해결합니다. 일반적인 인증서 기반 TLS에서는 인증서와 서명으로 상대를 확인하고 키 합의로 통신 키를 만듭니다. 실제 데이터는 대칭키 암호로 보호합니다. 따라서 TLS 전체를 ‘공개키로 데이터를 암호화하는 방식’이라고 설명하면 정확하지 않습니다. RFC 8446 §2, §5

웹에서는 이 구조 덕분에 개별 방문자에게 서버 비밀 키를 미리 배포하지 않아도 됩니다. 사용자가 서비스에 로그인하지 않은 상태에서도 서버를 인증하고 암호화 연결을 만들 수 있습니다. 이는 통신 상대가 익명이라는 뜻이나 네트워크 익명성을 제공한다는 뜻은 아닙니다.

작은 임베디드 프로젝트에서는 인증서 체인 처리, 신뢰할 루트 관리, 유효기간 확인에 필요한 시각, 갱신 절차, 핸드셰이크 연산과 버퍼 등이 부담이 될 수 있습니다. 특히 장치·서버·브라우저를 함께 구성해야 하는 개인 개발자는 암호 연산뿐 아니라 운영 요소까지 다뤄야 합니다. 여기서 비용은 인증서 구매비만이 아니라 메모리, 코드 크기, 전력, 설정과 유지보수 시간을 포함합니다.

다만 TLS 자체도 PSK 방식을 지원하며, 모든 TLS 구성이 제3자 인증서나 공개키 교환을 요구하는 것은 아닙니다. TLS 1.3에는 PSK-only와 PSK+(EC)DHE 방식이 있습니다. 사용할 수 있는 방식은 플랫폼과 TLS 구현에 따라 확인해야 합니다. RFC 8446 §2.2, §4.2.9

따라서 boho를 검토하는 이유는 ‘대칭키 통신은 boho만 가능해서’가 아닙니다. 이미 키를 안전하게 설정할 수 있는 작은 시스템에서, 필요한 메시지 보호와 인증을 Arduino·JavaScript 공통 API로 구성하기 위해서입니다.

비교 관점	일반적인 인증서 기반 TLS	boho
최초 신뢰 설정	인증서와 신뢰 루트, 상대 이름 검증	개발자가 별도 경로로 공유 키 설정
주된 보호 단위	전송 연결	응용 데이터 패킷과 연결 인증
불특정 웹 사용자 대응	사전 비밀 배포 없이 서버 인증 가능	먼저 공유 키를 설정할 절차 필요
개발·운영 요소	TLS 라이브러리, 인증서·신뢰 설정과 갱신 등	키 배포·보관·교체, 메시지 수신 정책 등
구현 기반	표준 프로토콜과 표준 암호 구성	SHA-256을 조합한 자체 프로토콜

boho의 ‘경량’ 목표는 공개키 연산과 인증서 처리를 boho 구성에서 제외하고, 필요한 암호 연산과 메시지 형식을 줄이는 데 있습니다. 이것만으로 모든 장치에서 TLS나 표준 대칭키 구현보다 빠르거나 메모리를 덜 쓴다고 단정할 수는 없습니다. 데이터마다 SHA-256 계산도 필요하며, 실제 차이는 하드웨어 가속, TLS 세션 재사용, 라이브러리와 메시지 크기에 따라 측정해야 합니다.

7. Arduino 장치에서 브라우저 웹앱까지

boho는 암호화 패킷과 인증을 담당하고, IOSignal은 이를 이용하는 연결·메시지 전달 구조를 제공합니다. 예를 들어 다음과 같은 구성이 가능합니다.

Arduino 장치           Node.js IOSignal 서버           브라우저 웹앱
     │                         │                           │
     ├── 장치의 키로 인증 ──────┤                           │
     │                         ├──── 웹앱의 키로 인증 ──────┤
     │                         │                           │
     └────── 메시지 전달 ───────┴────── 메시지 전달 ─────────┘

별도 E2E 데이터 키: Arduino 장치와 웹앱만 공유

연결 인증용 키와 E2E 데이터 키는 목적이 다릅니다. 연결 인증은 각 클라이언트가 서버에 접속할 자격을 확인하는 데 사용합니다. 서버를 거쳐 전달되는 본문을 최종 송수신자만 복호화하게 하려면, 서버에 제공하지 않은 별도의 데이터 키를 사용합니다.

IOSignal의 E2E 전달에서는 라우팅 정보와 암호화된 본문을 구분합니다. 서버는 메시지를 전달하기 위한 정보를 처리하고, 최종 수신자가 decrypt_e2e로 본문을 복호화·검증합니다. 연결 암호화만 사용하는 일반 메시지는 서버가 처리할 수 있으므로, 자동으로 종단간 암호화가 되는 것은 아닙니다. E2E도 수신 대상과 트래픽 크기 같은 메타데이터까지 모두 숨기지는 않습니다.

활용 예로는 개인 센서의 측정값 전달, 직접 만든 제어 장치와 웹 대시보드 연결, 기존 암호화 관리 경로로 키를 설정한 서버 사이의 응용 메시지 보호 등이 있습니다. 제어 명령에서는 복호화 성공뿐 아니라 재전송된 명령인지와 해당 사용자에게 실행 권한이 있는지도 확인해야 합니다.

웹앱에서는 HTTPS와 함께 사용할 수 있다

브라우저용 boho가 있다는 것은 웹앱의 HTTPS를 없애도 된다는 뜻이 아닙니다. 공격자가 웹앱 코드를 바꿀 수 있으면 사용자가 입력하는 키와 복호화된 데이터도 가져갈 수 있습니다. 서버로부터 본문을 보호하는 E2E 구성에서도 웹앱 코드 제공자를 신뢰해야 하는 문제는 남습니다.

일반적인 웹 배포에서는 HTTPS로 웹앱을 제공하고, 브라우저 연결에는 WSS를 사용하면서, 필요한 본문에 별도의 E2E 암호화를 적용할 수 있습니다. HTTPS 페이지의 비보안 연결은 브라우저의 mixed content 정책에도 영향을 받으며, boho는 이 정책을 우회하는 기능이 아닙니다. W3C Mixed Content

IOSignal의 일반 메시지 암호화 여부는 설정에 따라 달라집니다. 현재 JavaScript 구현의 AUTO 모드는 TLS를 사용하지 않고 boho 인증이 완료된 경우 boho 연결 암호화를 사용합니다. E2E 본문 암호화는 이 전송 연결의 보호 여부와 별도로 적용됩니다.

8. 현재 구현을 이해할 때 함께 알아둘 조건

boho의 단순한 구조를 실제 용도에 적용하려면, 다음 범위도 함께 이해해야 합니다.

키의 품질과 관리. set_key의 SHA-256 한 번은 짧은 비밀번호를 강한 키로 바꾸는 느린 비밀번호 KDF가 아닙니다. 충분히 무작위인 공유 키를 사용하고 장치별 발급, 유출 시 폐기, 교체 방법을 정해야 합니다. boho는 최초 키 배포나 E2E 키 배포를 대신하지 않습니다.

키스트림 재사용 방지. JS 구현은 crypto.getRandomValues()를 사용하지만, 현재 Arduino 구현은 독립 패킷의 nonce와 인증 요청의 클라이언트 nonce에 micros()를 사용합니다. micros()는 암호학적 난수가 아닙니다. 시각·카운터와 함께 사용된다는 사실만으로 재시작이나 여러 장치 사이의 중복 방지가 보장되지는 않습니다. 같은 키로 같은 salt12가 생기지 않도록 구성 전체를 검토해야 합니다.

재전송과 수신 정책. 태그 검증에 성공한 메시지도 과거에 받은 메시지일 수 있습니다. boho 자체는 중복 수신 캐시, challenge 만료, 메시지 순서·신선도 정책을 강제하지 않습니다. 이 부분은 IOSignal 등 호출 측과 응용 계층에서 실제 적용 여부를 확인하고 관리해야 합니다.

현재 프로토콜의 보안 범위. 표준 SHA-256을 사용한다는 사실만으로 자체 키스트림 구성과 태그가 표준 AEAD 또는 TLS와 같은 보장을 얻지는 않습니다. 또한 현재 boho에는 장기 공유 키가 나중에 유출되어도 과거 통신을 보호하는 순방향 비밀성이 없습니다. 보안 요구가 높은 적용에서는 키 관리뿐 아니라 구성 전체의 암호학적 검토가 필요합니다.

boho가 제안하는 사용 방향은 명확합니다. 양쪽 코드와 키 설정을 직접 관리할 수 있는 환경에서, 필요한 암호화와 인증을 작은 공통 구성으로 연결하는 것입니다. 이 조건과 구현의 범위를 이해하면, DIY 장치·서버·웹앱 사이에서 boho가 맡을 역할을 구체적으로 정할 수 있습니다.

구현과 참고 자료

이 문서의 구현 설명은 2026-10-02에 확인한 프로젝트 구현을 기준으로 작성했습니다. 일반 원리와 현재 구현의 차이를 구분했으며, 성능 비교 수치나 제3자 보안 검증 결과를 주장하지 않습니다.

프로젝트	확인한 주요 소스와 역할	공개 프로젝트
boho JavaScript 2.2.0	src/boho.js: 키 설정, 키스트림, 태그, 인증, 패킷 처리	remocons/boho
boho Arduino 0.8.0	src/Boho.cpp, src/Boho.h: C/C++ 구현, 시간·nonce 처리, 버퍼 구조	remocons/boho-arduino
IOSignal JavaScript	src/client/IOCore.js, src/server/RemoteCore.js, src/auth/BohoAuth.js: 연결 인증과 일반·E2E 전달	remocons/iosignal
IOSignal Arduino	src/IOSignal.cpp: 인증된 패킷 수신과 E2E 메시지 전달	remocons/iosignal-arduino

공개 저장소의 이후 변경에 따라 세부 동작은 달라질 수 있습니다. API 사용법과 설치 방법은 각 프로젝트의 README를 참고하세요.