2012-09-06 5 views
1

웹 기반 파일 저장 서비스 (C#)를 구현 중입니다. 파일은 서버에 저장 될 때 암호화되지만 문제는 해독 기능을 구현하는 방법입니다.임의 액세스 암호화 된 파일

파일 크기는 수십 KB에서 수 GB까지 다양 할 수 있습니다. 데이터 전송은 청크로 이루어 지므로 사용자가 오프셋 50000, 75000 등에서 데이터를 다운로드 할 수 있습니다. 암호화되지 않은 파일은 제대로 작동하지만 암호화를 사용하면 오프셋에서 각 청크를 읽지 전에 전체 파일을 해독해야합니다 .

그래서이 문제를 해결할 방법을 찾고 있습니다. 지금까지의 연구에서 ECB와 CBC를 사용할 수 있음을 보여줍니다. ECB는 가장 기본적인 (그리고 가장 안전하지 않은) 블록으로 각각 암호화되어 있습니다. ECB가 작동하는 방식은 내가 찾고있는 것이지만 보안은 걱정이다. CBC도 비슷하지만 현재 블록의 암호를 해독하기 전에 이전 블록을 암호 해독해야합니다. 이것은 파일이 처음부터 끝까지 읽히고 파일을 서버에서 해독 할 때 데이터를 보관할 수 있지만 하루가 끝날 때 전송하기 전에 전체 파일 서버 쪽의 암호를 해독하는 것보다 훨씬 좋습니다.

다른 대안을 알고있는 사람이 있습니까? 나는 이론적 연구 만하고 있기 때문에이 시점에는 코드가 없습니다.

+0

임의의 읽기 액세스 및 순차 쓰기 액세스 만 필요합니까 (즉, 파일은 한번에 작성됩니다)? – CodesInChaos

+0

무결성 검사가 필요합니까? MAC를 사용하는 것이 강력하게 권장됩니다. 인증이 없을 때 할 수있는 많은 물건이 있습니다. – CodesInChaos

+0

"CBC도 비슷하지만 현재 블록을 해독하기 전에 이전 블록을 해독해야합니다." 잘못된. 이전 블록의 암호 텍스트가 있으면 충분합니다. 평문은 필요 없습니다. 위키 백과에서 CBC를 확인하십시오. 그들은 좋은 그래프를 가지고 있습니다. – CodesInChaos

답변

1

ECB (전자 코드 북)를 사용하지 마십시오. 평문의 패턴은 암호문에 패턴으로 나타납니다. CBC (Cipher Block Chaining)에는 임의의 읽기 액세스 권한이 있습니다 (호출 코드는 키를 알고 IV는 이전 블록의 결과 임). 그러나 블록을 쓰려면 모든 다음 블록을 다시 작성해야합니다.

더 나은 모드는 Counter (CTR)입니다. 실제로 각 블록은 동일한 키를 사용하고 각 블록에 대한 IV는 정의 된 시작 및 초기 IV에서 해당 블록의 오프셋의 합계입니다. 예를 들어, 블록 n에 대한 IV는 IV + n입니다. CTR 모드는 1538 페이지의 NIST SP800-38a에 자세히 설명되어 있습니다. 키 및 IV 유도에 대한 지침은 NIST SP800-108에서 찾을 수 있습니다.

(Galois Counter Mode) GCM과 같은 몇 가지 유사한 모드가 있습니다.

+0

파일을 수 킬로바이트 블록으로 나누고 암시 적 IV를 사용하여 GCM으로 각 블록을 암호화 할 수 있습니다. – CodesInChaos

+0

@akton : 그렇습니다, 나는 ECB 약점을 알고 있으며, 분명히 다른 제안을 확인하고 다시 돌아올 것입니다! – Andreas

+0

@CodesInChaos : 당신이 쓴 글에서 나는 수동으로 파일을 청크로 나누고 암시 적 IV를 사용하여 각 파일을 암호화 할 것을 제안했습니다. 이것은 효과가 있지만 고통스럽게 느립니다. 나는 또한 내가 "고정 크기"암호화 알고리즘을 사용하여 이것을 달성 할 수 있다고 믿는다. GCM 블록 암호 암호화를 사용하면 한 번에 전체 파일을 암호화 할 수 있으며 암호화 된 각 청크의 크기를 알면 오프셋을 계산하고 청크를 읽고 개별적으로 해독 할 수 있습니다. 지금까지이 접근법에 대한 코드 샘플을 찾지 못했습니다. – Andreas