저는 최근 신빙성이있는 것으로 보이는 IBE (Identity Based Encryption) 개념을 사용했습니다. 그러나 나는 그것을 해독 할 수있는 방법을 찾기 위해 시도한 많은 암호 학계에 주목하지 못했습니다. 내가 잘못?신원 기반 암호화 및 공개 소스
마찬가지로, 블랙 햇 군중이 공격 할 수있는 곳에서 오픈 소스 구현을 실제로 배포 할 수 없다면 장점이 없을 수도 있습니다.
이 접근 방식을 사용하는 커뮤니티 전체의 경험을 이해하고 응용 프로그램에 통합하고 배포하는 것이 얼마나 쉬운 지 알고 싶습니다.
(편집 :. 여기에 ID 기반 암호화에 Wikipedia article있어)
나는 당신이 묻고 자하는 것을 분명하지 않으므로, 나는 몇 가지를 만들어서 대답 할 것입니다. 내가 따뜻해지면 알려줘.
첫째, "신원 기반 암호화"는 키 관리 체계만큼이나 암호화 체계가 아니다. 공개/개인 또는 기술적으로 "비대칭"암호화에는 두 가지 키가 있습니다. 그 중 하나는 암호 해독, 하나는 암호 해독에 사용되며, 다른 하나를 구성하는 것이 여전히 기하 급수적으로 어렵다는 (또는 기하 급수적으로 어려운 것으로 생각되는) 특수 속성이 있습니다. 예를 들어, 개인 키를 사용하여 편지를 암호화 할 수 있습니다. 내 공개 키를 게시합니다. 공개 키를 사용하여 편지를 해독 할 수 있다면, 내가 진짜로 보낸 사람이라는 확신을 가질 수 있습니다. 이것이 디지털 서명 체계의 핵심 아이디어입니다.
문제는 키 생성 및 관리 방법이 있어야하며 개인 키에만 적용되는 보호 수준만큼 스키마가 우수하기 때문입니다. 이 작업을 수행하는 데는 여러 가지 방법이 있습니다.
ID 기반 암호화는 알려진 공개 정보 (예 : 전자 메일 주소)에서 개인 키를 구성하는 특수 알고리즘을 제안하여이 key management 문제를 단순화하려고 시도합니다. 여전히 개인적인 측면을 파악하는 것을 어렵게하는 방식으로 이것을 수행하려면 알고있는 다른 비밀을 기반으로 개인 키를 구성하는 신뢰할 수있는 엔터티가 필요합니다. 따라서 이메일 주소를 아는 사람과 의사 소통을하십시오. 신뢰할 수있는 공급자에게 가서 개인 키가 생성되도록 요청합니다. 통신하려는 사람은 사용하는 제공 업체를 알고 해당 공급자로부터마스터 공개 키를 가져옵니다.
이제, 보내려는 사람은 공급자의 일부 마스터 키 정보를 제외하고는 알지 못해도 ID에서 공개 측을 생성 할 수 있습니다. 열쇠는 절대 전달되지 않습니다.
즉, 다음과 같이 보입니다. Alice가 암호화 된 Bob에게 전자 메일을 보내려고합니다. 그들은 둘 다 공급자 인 Tom을 신뢰합니다.
이러한 구성표에 대한 중요한 점은 몇 가지 주요 관리 문제를 단순화한다는 것입니다. 당신은 여전히 열쇠를 생성 할 필요가 있습니다. 더 나쁜 것은, 그가 모든 것을 알고 있기 때문에 은 정말로입니다. Tom은 모든 것을 알고 있기 때문에 자신의 개인 키를 생성하고 암호화하여 모든 메시지를 본 것처럼 보입니다. 이것이 의미하는 바는 그것이 고유의 핵심 에스크로 계획을 생성한다는 것입니다. 귀하의 개인 키를 찾을 수 있습니다.
몇 가지 방법이 좋습니다. 그것은 잃어버린 열쇠의 문제를 처리합니다. 그러나 사람들이 암호화를 사용하려는 대부분의 이유로 그것은 나쁘다. 이제 누군가 톰을 소환하거나, 그를 때리고 개인 데이터를 얻을 수 있습니다.
결과적으로 ID 기반 암호화만으로는 멋진 생각이지만 많은 시장을 확보하지 못했습니다.
당신이 생각하고있는 특정 계획이 있습니까? "신원 기반 암호화"는 꽤 광범위한 용어입니다.
하지만 어쨌든 당신은 그 자체로 특별한 것이 아니므로 많은 주목을받지 못했을 것입니다. 암호화 키에 엔트로피가 몇 비트나 있는지와 같은 암호화의 일반 원칙은 여전히 적용됩니다. 본질적으로 무기한으로 동일한 키가 사용되면 평문/암호문을 대량으로 사용하여 충돌 공격 및 기타 공격의 위험이 무엇입니까?
찰리가 올바른 길 위에 있지만 다른 점을 강조하고 싶습니다. IBE는 암호화 접근 방식보다 핵심 관리 방식이며 핵심 관리에 대한 접근 방식은 양탄자 아래의 중요한 문제를 해결합니다. 정체성을 기초로 사용하는 것은 문제가 있습니다. 그 누구도 전자 응용 프로그램에서 그물에 있는지 또는 물리적 세계에 있는지에 관계없이 ID를 확인하는 정말 좋은 해결책이 없으므로 문제가 있습니다. 정체성에 대한 좋은 해결책이 없다면, 이들 IBE 계획은 그들이 의존하는 정체성을 강조하면 자신의 얼굴에 떨어집니다.
대부분의 IBE 시스템은 기술적 인 세부 사항을 실제로 보았습니다. 실제로 "신뢰할 수있는 공급자"로 바뀌 었습니다. 확장되지 않고 실제 보안을 보장하지 못합니다. 공급자는 네트워크를 통해 신원을 확인하기 위해 노력한 다음 모든 사람을 위해 암호화 키를 보유한 신뢰할 수있는 제 3 자로 활동합니다. 신뢰할 수있는 제 3 자에게 의지하는 것은 많은 알려진 취약점이 있습니다.
현대의 암호화는 모두 제 3 자에 의존 할 필요가없는 방법을 찾는 것입니다. 웹은 신뢰의 한 방법이며, 주요 단점은 최종 사용자에게 핵심 관리를 남겨두고 핵심 관리는 비용이 많이 든다는 것입니다. 인증서 발급자에게 의지하는 또 다른 접근법이지만 발급자가 신뢰할 수있는 제 3 자임이 분명합니다. 몇 년 전만해도 모든 브라우저가 신뢰하는 주요 쟁점 중 하나는 확실하게 신뢰할 수없는 플레이어가 파산하여 파산했기 때문에 해당 스키마의 약점이 인증서 체인의 근원임을 분명히했습니다 .
"전자 응용 프로그램에서 신원을 확인하는 데 정말 좋은 해결책이 없기 때문에 신원을 기초로 사용하려고하면 문제가 발생합니다." +1 –
슬프게도, 그래서 그것은 긴 대답을 요구할 때조차도, 진짜 빠른 답을 얻기 위해 여러 가지 결정을 내린 것처럼 보입니다. 해결책 (BY에 의해 제안 됨)은 짧은 대답을 저장하고 편집하는 것입니다. –
오픈 소스 프로젝트에서 신원 기반 암호화, 특히 자유처럼 자유롭지는 않지만 맥주처럼 무료입니다. 언급 한 바와 같이, 전체 시스템은 신뢰할 수있는 제 3 자에 의존하여 키를 발행합니다.하드 및 소프트웨어 모두 구매 및 유지 보수 비용이 많이 드는 인프라를 필요로합니다. 또한 키를 발행하는 당사자에게 많은 책임이 있습니다. 시스템을 사용하는 사람들은 사안이 잘못 될 경우 발급자가 책임을 져야한다고 기대할 것입니다. 이런 종류의 책임은 싸지 않고 오픈 소스 프로젝트가 수행하기에는 종종 불가능합니다.
이것은 모두 사실이며 중요합니다. 열린 프로젝트의 또 다른 어려움은 신뢰할 수있는 제 3자가 비밀을 지켜야한다는 것입니다. 모두에게서. – PanCrit
시도 it. 좋고 간단한 해결책.
질문을 읽는 사용자가 Google에서 직접 읽을 필요가 없도록 URL을 알려주시겠습니까? –