- 질문 게시판입니다.
| Date | 23/08/11 17:24:14 |
| Name | ㅢㅘㅞ |
| Subject | 짧은 길이 데이터에 대한 무결성 보장을 위한 문의 |
|
8~16 Bytes에 대한 무결성을 보장하려 합니다. 무결성 데이터를 가능하면 최소 길이와 최소 연산력으로 해결하려고 합니다. 이 부분에 대한 요건이나 가이드 같은 것이 있을까요? 환경이 구려서 bit flip이 2회이상 발생할 수도 있습니다 :( 1
이 게시판에 등록된 ㅢㅘㅞ님의 최근 게시물
|
|
이론적으로야 틀리기 시작하면 얼마가 되어도 답은 없겠지요.
확률의 문제이니 데이터의 크기가 작은 대신 반드시 올바른 값을 가져야 한다면
동일한 샘플을 여러 개 저장하는 것이 현실적일 것 같습니다.
전에 무선오디오 만들 때 무조건 7번씩 전송하던 걸 본 적이 있습니다.
확률의 문제이니 데이터의 크기가 작은 대신 반드시 올바른 값을 가져야 한다면
동일한 샘플을 여러 개 저장하는 것이 현실적일 것 같습니다.
전에 무선오디오 만들 때 무조건 7번씩 전송하던 걸 본 적이 있습니다.
좀 더 생각해 봤는데
통신 프로토콜이나 하드웨어에 따라 특정 번째 bit가 깨지거나 하는 경우가 있을 수 있으므로
data를 n bit shift한 것을 여러 번 보내어
받는 쪽에서 원상복귀한 후 비교하는 식으로 접근할 수 있겠습니다.
이때 n 값은 소수로 하면 중복하여 깨지는 bit가 겹치는 것을 피할 수 있습니다.
보통 ICV를 생성하는 방법은 특정 패턴에 따라 seed를 만들고 그걸 XOR하는 방식인데
그러면 0이나 1로 값이 고정되는 경향이 있을 때 검출이 용이해집니다.
따라서 bit shift, 다양한 패턴 ... 더 보기
통신 프로토콜이나 하드웨어에 따라 특정 번째 bit가 깨지거나 하는 경우가 있을 수 있으므로
data를 n bit shift한 것을 여러 번 보내어
받는 쪽에서 원상복귀한 후 비교하는 식으로 접근할 수 있겠습니다.
이때 n 값은 소수로 하면 중복하여 깨지는 bit가 겹치는 것을 피할 수 있습니다.
보통 ICV를 생성하는 방법은 특정 패턴에 따라 seed를 만들고 그걸 XOR하는 방식인데
그러면 0이나 1로 값이 고정되는 경향이 있을 때 검출이 용이해집니다.
따라서 bit shift, 다양한 패턴 ... 더 보기
좀 더 생각해 봤는데
통신 프로토콜이나 하드웨어에 따라 특정 번째 bit가 깨지거나 하는 경우가 있을 수 있으므로
data를 n bit shift한 것을 여러 번 보내어
받는 쪽에서 원상복귀한 후 비교하는 식으로 접근할 수 있겠습니다.
이때 n 값은 소수로 하면 중복하여 깨지는 bit가 겹치는 것을 피할 수 있습니다.
보통 ICV를 생성하는 방법은 특정 패턴에 따라 seed를 만들고 그걸 XOR하는 방식인데
그러면 0이나 1로 값이 고정되는 경향이 있을 때 검출이 용이해집니다.
따라서 bit shift, 다양한 패턴 XOR 등으로 여러 벌을 보내고
이를 받는 쪽에서 원복한 후
해당 여러 소스를 비교하여 높은 확률인 bit를 채택하는 등을 생각해 볼 수 있겠습니다.
통신 프로토콜이나 하드웨어에 따라 특정 번째 bit가 깨지거나 하는 경우가 있을 수 있으므로
data를 n bit shift한 것을 여러 번 보내어
받는 쪽에서 원상복귀한 후 비교하는 식으로 접근할 수 있겠습니다.
이때 n 값은 소수로 하면 중복하여 깨지는 bit가 겹치는 것을 피할 수 있습니다.
보통 ICV를 생성하는 방법은 특정 패턴에 따라 seed를 만들고 그걸 XOR하는 방식인데
그러면 0이나 1로 값이 고정되는 경향이 있을 때 검출이 용이해집니다.
따라서 bit shift, 다양한 패턴 XOR 등으로 여러 벌을 보내고
이를 받는 쪽에서 원복한 후
해당 여러 소스를 비교하여 높은 확률인 bit를 채택하는 등을 생각해 볼 수 있겠습니다.
고전적인 접근입니다만, CRC check를 고려해볼 수 있을 것 같습니다.
아니면, 32비트 FNV Hash를 데이터 뒤에 붙여서 확인해 보시면 어떨까 합니다.
http://www.isthe.com/chongo/tech/comp/fnv/index.html
딱히 측정은 안 해봤습니다만, 계산식의 복잡성만 따지고 보면 FNV hash가 CRC보다 더 가볍지 않을까...... 싶습니다.
아니면, 32비트 FNV Hash를 데이터 뒤에 붙여서 확인해 보시면 어떨까 합니다.
http://www.isthe.com/chongo/tech/comp/fnv/index.html
딱히 측정은 안 해봤습니다만, 계산식의 복잡성만 따지고 보면 FNV hash가 CRC보다 더 가볍지 않을까...... 싶습니다.
| 목록 |
|
