http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?
topic=/apis/qc3calds.htm

Dat is ook nuttig, maar niet helemaal wat ik bedoelde...

Stel ik genereer een SSL certificaat waarmee ik hele
belangrijke dingen ga doen (mail onderteken en
ontsleutelen). Dit certificaat wordt opgeslagen op mijn
laptop waarvan de disken gecrypt zijn met LUKS.

Kan ik dan een lifetime van 2 jaar nemen (de tijd waarin ik
mijn laptop afschrijf) of moet ik uitgaan van 1 jaar of
korter omdat de kans dat mijn laptop gejat word redelijk
groot is (ik ben vaak op weg).

Dat, en dan vooral hoe dat te berekenen, wil ik graag te
weten komen. Zoals gezegd; een hoop wijze mannen hebben er
wat over gesuggereerd in hun white papers maar ik kan niets
concreets vinden.

Je disken zijn encrypted dus zelfs als je laptop gestolen zou worden kunnen ze niets met de data die er op staat (inclusief die certificaten).

Bedenk ook dat je je (gestolen) certificaten kunt revoken..

Een beetje slimme jongen probeert natuurlijk of er nog een
shadow van de masterkey in het geheugen rondhangt om daar
mee toegang te krijgen tot de gecrypte disken ::
http://citp.princeton.edu/pub/coldboot.pdf



ja natuurlijk kan dat - maar revocation lists zijn de zwakke
schakel in een PKI. Daarom kan je beter de lifetime van een
key aanpassen aan de mate van publieke (lees: evil haxors)
interesse in die key en de mate waarin die gecompromiteerd
zou kunnen worden. Wie (met een beetje verstand van zaken)
accepteert nou een verlopen key?

Er moet toch ergens een wegingsystem zijn om de life time te
kunnen bepalen?

Beetje jammer dat een serieuze vraag op deze manier
ondergesneeuwd raakt onder de futiliteiten van windows. Ik
had meer verwacht van de security.nl gebruikers.

Hoewel serieus is je vraag niet zo makkelijk te beantwoorden, in elk geval niet door mij.

Om, gegeven risico's, sterkte van encryptie e.d. de veilige levensduur van een certificaat (ik neem aan dat je dat bedoelt) te berekenen moet je een model hebben waarin al die factoren gewogen worden meegenomen. Zo'n model zou je dan in een programma (of een excel sheet) kunnen stoppen.

De vraag is wat de betrouwbaarheid is van dat soort modellen. Bijvoorbeeld wordt daarin meegenomen dat de software die de keys genereert wel eens een slechte random number generator zou kunnen gebruiken? En zo ja, op welke wijze? Door Debian's OpenSSL implementatie gegenereerde keys werden van de ene op de andere dag [url=http://www.security.nl/article/18880/1/Veel_SSL-certificaten_kwetsbaar_door_Debian_OpenSSL-lek.html]waardeloos[/url].

Anderszijds is de verwachte of zelfs vereiste bewaarduur van gesigneerde informatie van groot belang. Als jij wat naar een publieke maillijst stuurt, is het dan okay als de authenticiteit daarvan na het verlopen van jouw certificaat niet meer met zekerheid kan worden vastgesteld?

Anyway er is op internet wel wat te vinden over modellen. [url=http://gerck.com/]Ed Gerck[/url] heeft o.m. [url=http://nma.com/papers/certover.pdf]Overview of Certification Systems[/url] geschreven, de verwijzing daarin naar een post over een 'General Formula' op de PKIX maillijst klopt niet meer, maar is [url=http://www.imc.org/ietf-pkix/old-archive-99/msg00993.html]hier[/url] te vinden.

Verder heeft [url=http://csrc.nist.gov/groups/ST/toolkit/key_management.html]NIST[/url] altijd goede regels en richtlijnen. Vanuit die pagina wordt o.a. verwezen naar [url=http://csrc.nist.gov/groups/ST/toolkit/documents/SP800-57Part1_3-8-07.pdf]Recommendation for key management - part 1 (PDF)[/url]. Op pag. 45, onder 'Risk Factors Affecting Cryptoperiods', vind je 11 aspecten die een rol spelen bij het bepalen van de levensduur.

Stop, afhankelijk van de toepassing, geruime tijd vóór het verlopen van je certificaat met het gebruiken daarvan. Vergeet bij X.509 niet te kijken naar de levensduur van het root certificate (of de chain van certificates); jouw certificate kan niet langer geldig zijn dan elk van de root certs uit de chain.

Aanvulling 15:02: op blz 55 van bovengenoemde [url=[url=http://csrc.nist.gov/groups/ST/toolkit/documents/SP800-57Part1_3-8-07.pdf]NIST PDF[/url] vind je een tabel met aangeraden key lifetimes afhankelijk van de toepassing en soort key.

Dank u! Dank u! Dit waren precies de dingen waar ik naar op
zoek was.

Hulde!

Als je de lifetime wilt berekenen van een key waarmee je
heel belangrijke zaken wilt beveiligen zoals je stelt, dan
moet je rekenen met de zogenaamde unicity distance. Dit is
de hoeveelheid source data welke je kunt encrypten met
dezelfde key totdat, gegeven de encrypte data en het
gebruikte versleutelingsalgoritme, de key uniek te herleiden
valt. Als de source data bijvoorbeeld engelse text is, en
het versleutelingsalgoritme een block cipher (zoals vrijwel
alle hedendaagse encryptie algoritmes) dan is de unicity
distance ongeveel 1.5X de key lengte. Je ziet dus al dat de
huidige computational secure of public-key systemen
ongeschikt zijn om heel belangrijke zaken mee te beveiligen
zoals jij wilt.

Correct me if I'm wrong, maar asymmetrische encryptie wordt normaal gesproken niet gebruikt om (Engelse) tekst mee te versleutelen, daarvoor kost het veel te veel performance.

In plaats daarvan wordt een éénmalige random symmetrische encryption key gegenereerd welke wel gebruikt wordt voor het versleutelen van de tekst. Asymmetrische encryptie (de public key van de uiteindelijke ontvanger) wordt gebruikt voor het versleutelen van de symmetrische sleutel.

M.a.w. de sleutel die gebruikt wordt voor het encrypten van de tekst is eenmalig, daar heb je niets te maken met lifetime. Als de randomness van die symmetrische sleutel voldoende is (lees niet voorspelbaar c.q. niet beperkt tot een klein aantal waarden), dan is ook daarop brute forcing niet realistisch.

Daarnaast is het gebruikelijk om plaintext eerst te comprimeren alvorens deze te versleutelen, om twee redenen: na het versleutelen haalt comprimeren niet of nauwelijks iets uit, en belangrijker, brute force attacks door voorkennis van veelgebruikte (Engelse) woorden zijn nauwelijks mogelijk, tenzij een erg 'voorspelbaar ' compressie-algoritme is gebruikt (bij veel file-compressors worden bestandsnamen als plain text op bekende locaties in het bestand geschreven).

Kortom, hoewel er veel valt aan te merken op public key systemen, is wat jij noemt volgens mij geen issue.

De Unicity Distance van een Block-Cipher rekent met de
hoeveelheid
redundantie in de source data. Het gaat dus niet om engelse
tekst, dat is
alleen een voorbeeld. Dit geldt voor alle typen source data.
Als algemene regel
geldt dat hoe minder redundantie in de source data, hoe
groter de unicity
distance. Het is dus altijd verstandig om de source data
lossless te
comprimeren voordat je het beveiligd. Mijn punt is echter
meer dat van Public-
Key en Computational Security bewezen kan worden dat ze niet
bewijsbaar
veilig kunnen zijn. Bovendien zijn vrijwel alle security
systemem volledig
deterministisch. Met dit soort systemen is het nooit
verstandig belangrijke
gegevens te beveiligen. Op de link http://picasaweb.google.com/
freemovequantumexchange is een beschijving en presentatie te
vinden van
een operationeel (informatie-theoretisch) bewijsbaar veilig
systeem. Met dit
systeem ben je zeker dat de gegevens veilig zijn.

Klopt, daarom had ik in mijn vorige betoog 'Engelse' ook tussen ronde haken gezet, en het gaat natuurlijk ook niet alleen over tekst, maar over elk bestand waarin patronen te herkennen zijn. Eens, dat gaf ik zelf ook al aan. Vooropgesteld: ik vind het ontzettend goed dat er op dit gebied wetenschappelijk onderzoek wordt verricht. Maar ik heb sterk de indruk dat de technologie die jij beschrijft zich nog veel te veel in een onderzoeksstadium bevindt.

Zo vermoed ik dat niemand op dit forum erg onder de indruk is van [url=http://picasaweb.google.com/lh/viewPhoto?uname=freemovequantumexchange&aid=5216109337708676321&iid=5216119687922044226]1500 bit/sec bij een afstand van 25km[/url]. Opvallend vond ik dat het [url=http://picasaweb.google.com/lh/viewPhoto?uname=freemovequantumexchange&aid=5216109337708676321&iid=5216119939882595010]eerstvolgende plaatje[/url] waarschuwt: Klopt mijn veronderstelling dat voor een bewijsbaar veilige overdracht de sleutel even lang moet zijn als het te transferren bestand? Zo ja, dan zal het verzenden van de sleutel voor een bestand van zo'n 660KB over 25km ca. 1 uur duren. Dergelijke getallen associeer ik alleen met extreme staatsgeheimen e.d. en zeker niet met die van de OP (Hartog) die versleutelde emails e.d. vanaf zijn laptop wil versturen.

Overigens, je zou zelfs met conventionele crypto het door jou aangekaarte probleem kunnen oplossen met een extra slag: genereer een [url=http://picasaweb.google.com/lh/viewPhoto?uname=freemovequantumexchange&aid=5216109337708676321&iid=5216111708538214082]random key (OTP) die even lang is als het te verzenden bestand[/url] en XOR daarmee je bestand en verstuur het resultaat. Die OTP versleutel je zoals ik in mijn vorige bijdrage aangaf (met een symmetrische sleutel van vaste lengte, die op zijn beurt met een public key wordt versleuteld). Als je OTP absoluut random is (whatever that may be; goede PRNG's zijn, op z'n zachtst gezegd, een uitdaging) dan is je unicity distance oneindig. Of zie ik iets over het hoofd?

Tip: (ik neem aan dat jij Ronald bent): op de cryptography maillist vind je meer mensen van jouw niveau (ik zelf ben absoluut geen wetenschapper). Zie bijv. [url=http://www.mail-archive.com/cryptography@wasabisystems.com/msg03679.html]deze samenvatting over een unicity discussie[/url] - toevallig ook door de eerder genoemde Ed Gerck.

Ten slotte is al zo vaak in de praktijk bewezen dat, hoe goed de theorie van een (encryptie-) algoritme ook is, het bijna altijd de implementaties zijn die op hun neus gaan nadat ze in de praktijk worden uitgerold (en soms duurt het [url=http://www.security.nl/article/18880/1/Veel_SSL-certificaten_kwetsbaar_door_Debian_OpenSSL-lek.html]extreem lang[/url] voordat dergelijke fouten aan het licht komen). Ik zie niet in waarom dat bij quantumcrypto anders zou zijn.

Ik wil in de laatste reaktie graag even een aantal aspecten toelichten.

Quote: "Zo vermoed ik dat niemand op dit forum erg onder de indruk is
van
1500 bit/sec bij een afstand van 25km. "

Dit klopt. Dit geldt echter voor een research Key Exchange systeem dat met
quantum informatie werkt over optische verbindinen. Het gepresenteerde
FreeMove Quantum Exchange Research Systeem wat gebaseerd is op true
quantum randomness en niet quantum informatie ondersteund bewijsbare
veiligheid over alle netwerken, in combinatie met alle hardware en met alle
snelheden. Bovendien zijn de additionale (hardware) kosten van dit systeem
erg laag (in de orde van 1000 Euro).

Quote: "Klopt mijn veronderstelling dat voor een bewijsbaar veilige
overdracht
de sleutel even lang moet zijn als het te transferren bestand?"

Nee dit klopt niet. Bijvoorbeeld de Homophomic Coder wat een van de coders
is welke de FreeMove Quantum Exchange ondersteund is bewijsbaar veilig
met kleinere sleutels. Hoe dit werkt wordt uitgelegd in de presentatie welke te
vinden is op de opgegeven link.

Quote "Overigens, je zou zelfs met conventionele crypto het door jou
aangekaarte probleem kunnen oplossen met een extra slag".

Dit klopt, echter is de geschetste One-Time Pad in de praktijk wat onpraktisch.
Overigens heb je voor de One-Time-Pad ook een true random generator
nodig, moet je er voor zorgen dat de entropie van de Key >= entropie van de
Source. De additionele randvoorwaarde welke echter vrijwel altijd vergeten
wordt is dat alle Keys onafhankelijk moeten zijn, wat in praktische systemen
ook vrijwel nooit zo is. Echter in de FreeMove Quantum Exchange is een
innovatie dat we gebruik maken van een Informatie-Theoretisch bewijsbare
One-Way Hash function. Hiermee kunnen we garanderen dat gebruikte Keys
(voor elk gebruikt coderingsschema) onafhankelijk zijn.

Quote: "Ten slotte is al zo vaak in de praktijk bewezen dat, hoe goed de
theorie
van een (encryptie-) algoritme ook is, het bijna altijd de implementaties zijn die
op hun neus gaan nadat ze in de praktijk worden uitgerold (en soms duurt het
extreem lang voordat dergelijke fouten aan het licht komen). Ik zie niet in
waarom dat bij quantumcrypto anders zou zijn."

De correctheid van de implementatie van de FreeMove Quantum Exchange is
Informatie-Theoretisch bewezen (zie bijvoorbeeld de Information-Theoretic
inequality prover op de gegeven link) en de security van de beveiligde
informatie wordt in het systeem real-time gemeten. Het FreeMove Quantum
Exchange Systeem is een systeem dat in de praktijk al jaren wordt gebruikt en
i.t.t. tot jou suggestie is het erg gebruikersvriendelijk. Een van de andere
innovaties in het systeem is bijvoorbeeld ook de functiescheiding tussen de
Content Storage/Security functionaliteit enerzijds en de Content Commucatie
functionaliteit anderzijds. Daarmee hebben we in de FreeMove Quantum
Exchange naast de bewijsbare veiligheid ook bereikt dat het onmogelijk is dat
malware toegang kan krijgen tot de Source data. Ook dit concept is reeds
enkele jaren operationeel.

dit klopt helemaal sirdice. goed opgemerkt.