| garoeda | (log note: start translation) |
|---|
| garoeda | ok, ik wil iedereen welkom heten op de laatste presentatie van deze dag, james morris van intercode |
|---|
| garoeda | jamesm: hallo, bedankt om hier te zijn |
|---|
| garoeda | sarnold: zijn presentatie zal gaan over de nieuwe cryptografische infrastructuur die hij heeft helpen introduceren in de 2.5 linux kernel |
|---|
| garoeda | hij heeft ook meegewerkt in het LSM project |
|---|
| garoeda | vragen en opmerkingen gaan naar #qc |
|---|
| garoeda | jamesm: |
|---|
| garoeda | een nieuwe crypto api is recentelijk aan de 2.5 kernel toegevoegd |
|---|
| garoeda | die deel gaat uimaken van de komende stabiele kernel reeks (2.6) |
|---|
| garoeda | deze api was oorsprongkelijk ontwikkeld om de ipsec implementatie te ondersteunen |
|---|
| garoeda | die geschreven is door David Miller en en Alexy Kuznetsov (die ook in de 2.5 kernel gemerged is) |
|---|
| garoeda | het is ook bedoelt als een generische api voor andere kernel componenten |
|---|
| garoeda | die crypto nodig hebben, zoals CIFS, cryptoloop en de /dev/random driver |
|---|
| garoeda | momenteel is het een simpele software API, met een pluggable interface |
|---|
| garoeda | voor algoritme modules |
|---|
| garoeda | algoritmen die tot dusver geimplementeerd zijn: |
|---|
| garoeda | Digests: SHA1, SHA256, MD4, MD5. |
|---|
| garoeda | deze worden gebruikt om data integriteit te controleren en digitale handtekeningen te maken en boodschap authenticatie codes voor netwerk |
|---|
| garoeda | Ciphers: Blowfish, DES, 3DES, Twofish, Serpent. (AES is in development). |
|---|
| garoeda | dit zijn symmetrische encrypto algoritmen waar je (gebruikelijk) dezelfde key gebruikt om te coderen en decoderen, de key moet geheim gehouden worden |
|---|
| garoeda | de meeste encryptie applicaties gebruiken een combinatie van data integriteit en encryptie |
|---|
| garoeda | opmerking: sarnold: het zou mijn leven eenvoudiger maken als jullie assymmetrische algoritmen ook zouden implementeren |
|---|
| garoeda | assymmetrische ondersteuning wordt bekeken, het zou handig zijn voor code signing en multicast ipsec |
|---|
| garoeda | en we willen zeker userspace toelaten om voordeel te halen uit de beschikbare assymetrische crypto hardware |
|---|
| garoeda | daar het zeer traag is in software |
|---|
| garoeda | vraag: kan deze crypto API gebruikt worden voor SSH/SSL of moeten we nog altijd gebruik maken van software level crypto |
|---|
| garoeda | nog niet, en het zou alleen maar zin hebben als de api toegang tot hardware acceleratie toelaat |
|---|
| garoeda | de api stelt het HMAC algoritme beschikbaar voor digests (gebruikt door ipsec) en CBC |
|---|
| garoeda | mode voor ciphers (deze concateneert het resultaat van de laatste encryptie aan de volgende) |
|---|
| garoeda | (om de veiligheid te verhogen en is vaak gebruikt) |
|---|
| garoeda | momenteel is de api alleen getest met ipsec |
|---|
| garoeda | er is verder werk nodig om het goed te doen werken met cryptoloop |
|---|
| garoeda | een specifieke eigenschap van de api is dat het werkt met een array van page vectors |
|---|
| *** MJesus is now known as MJn |
| garoeda | (scatterlists) ipv normale geheugen buffers |
|---|
| garoeda | (pages zijn de fundamentele blokken geheugen waar de kernel mee werkt) |
|---|
| garoeda | dit laat een verregaande integratie toe met andere kernel componenten |
|---|
| *** luli (vHotBoyz24@1Cust208.tnt39.dfw9.da.uu.net) has joined #taee |
| garoeda | zoals de netwerk stack en biedt een scatter/gather interface |
|---|
| *** luli (vHotBoyz24@1Cust208.tnt39.dfw9.da.uu.net) Quit (Signed off) |
| garoeda | (in userspace, een bekende scatter/gather interface is de readv()/writev(), de crypto api gebruikt een gelijkaardig concept op pages ipv normale buffers) |
|---|
| garoeda | vraag: ik denk dat cryptoloop ECB mode kan nodig hebben voor random toegang tot 'blocks' ... is dit correct? |
|---|
| garoeda | voor zover ik weet gebruikt cryptoloop CBC mode en het zet de IV tot iets dat afgeleidt is van het disk block |
|---|
| garoeda | het primaire idee van te werken op pages en scatter/gather is efficientie |
|---|
| garoeda | pages zijn fundamenteel in de kernel, en scatter/gather laat toe om data te transporteren zonder het allemaal in een buffer te copieren |
|---|
| garoeda | dit kan naar het hardware niveau gebracht worden en scatter/gather DMA operaties gebruiken |
|---|
| garoeda | Dave Miller heeft aan dit design deelgenomen en het doel is hoge performantie |
|---|
| garoeda | het zou goed zijn onze performantie te vergelijken met openbsd daar zijn ook geintegreerde crypto hebben |
|---|
| garoeda | in het geval van ipsec, het design van de crypto api laat crypto transformaties toe |
|---|
| garoeda | zodat ze direct op de discontinue pages van het geheugen geassocieerd met |
|---|
| garoeda | netwerk pakketten (bv IP fragment lijsten, zero-copy pages die getransfereerdd worden met sendfile() ) kunnen toegepast worden |
|---|
| garoeda | voorlopig schijnt dit prima te werken maar we hebben nog geen performantie optimisaties gedaan of hardware acceleratie getest |
|---|
| garoeda | vraag: weet je waarom linux dit nog niet eerder geintegreerd heeft? |
|---|
| garoeda | er is een kernel crypto patch geweest voor enige tijd (door de mensen van kerneli.org) maar ik denk dat wettelijke problemen ervoor zorgden dat crypto niet volledig in de kernel geintegreerd kon worden tot nu toe |
|---|
| garoeda | openbsd heeft een crypto geintegreerd daar het ontwikkelt wordt buiten de VS |
|---|
| garoeda | de api werk momenteel in-place op data maar dit kan binnenkort veranderen |
|---|
| garoeda | om verschillende input/output scatterlists toe te laten voor cryptoloop |
|---|
| garoeda | toekomstig en huidig werk: |
|---|
| garoeda | geoptimiseerde assembler versies van de algoritmen werden nog niet geimplementeerd |
|---|
| garoeda | het zijn momenteel allemaal generische C versies |
|---|
| garoeda | we zijn begonnen met ondersteuning voor crypto hardware devices wat nuttig kan zijn om |
|---|
| garoeda | performantie en stabiliteit te verbeteren |
|---|
| garoeda | (merk op dat sommige mensen, zoals Linux, twijfels hebben over de nuttigheid van zulke hardware cards, sinds het ook het copieren van data over de pcibus inhoudt terwijl de huidige cpu's heel snel zijn. er dient hier nog veel onderzocht te worden |
|---|
| garoeda | vraag: met de nieuwe crypto, is al het geheugen dan beschermt tijdens gebruikt? |
|---|
| garoeda | kernel geheugen kan nooit naar de disk gepaged worden |
|---|
| garoeda | wanneer men de userspace api gaat ontwikkelen kan dit wel een probleem owrden |
|---|
| garoeda | vraag: ben je op zoek naar een hardware crypto ozals prowercrypt? |
|---|
| garoeda | ja, ik heb een oude powercrypt kaart (hifn7751) en enkele soekris kaarten (die vrij goedkoop zijn) |
|---|
| garoeda | bijzonder interessant zijn netwerk kaarten met een crypto chip erop |
|---|
| garoeda | zulke kaarten laten toe om pakketten te kopieren over de pci bus naar de kaard |
|---|
| garoeda | waar de packetten geencrypteerd worden en over het netwerk gezonden worden |
|---|
| garoeda | zonder verder kopies te maken over de bus |
|---|
| garoeda | spijtig genoeg hebben we nog geen documentatie van deze kaarten kunnen krijgen |
|---|
| garoeda | een userspace API wordt gedesigned om applicaties (bv SSL, IKE) |
|---|
| garoeda | voordeel te laten nemen van de beschikbare hardware |
|---|
| garoeda | de userspace API zal waarschijnlijk een pseudo bestandssysteem worden (cryptoapifs misscien) en character devices gaan gebruikt worden om toegang te verkrijgen tot de crypto eigenschappen van de kernel en hardware |
|---|
| garoeda | aangezien de api werkt op pages kunnen we interessante dingen doen door de devices te mmappen |
|---|
| garoeda | de userspace api zal ons ook toelaten om een nettere en uitgebreidere testsuite te ontwikkelen |
|---|
| garoeda | de huidige test code is een lelijke kernelmodule |
|---|
| garoeda | vraag: is er discussie geweest om de openbsd /dev/crypto api te gebruiken |
|---|
| garoeda | ja, he zou tof zijn een compatibiliteitslaag te hebben maar dit is nog niet verregaand bekeken |
|---|
| garoeda | de eerste stappen naar hardware support zijn het verkrijgen van kaarten en documentatie en |
|---|
| garoeda | het schrijven van nette GPL drivers (veel werk dus) |
|---|
| garoeda | we proberen zoveel mogelijk kaarten te krijgen zodat we de |
|---|
| garoeda | generische vereisten verstaan |
|---|
| garoeda | dit is waar ondersteuning voor assymmetrische crypto zal beken worden aangezien veel kaarten dit aanbieden en het sneller in hardware is |
|---|
| garoeda | bronnen: |
|---|
| garoeda | http://samba.org/~jamesm/crypto/ (updates, status, patches etc.) |
|---|
| garoeda | > http://www.kerneli.org/pipermail/cryptoapi-devel/ ontwikkelings discussie) |
|---|
| garoeda | kernel source code in de crypto directory op recente 2.5 kernels |
|---|
| garoeda | documentatie in de Documentation/crypto directory (inclusief gedetailleerde credits) |
|---|
| garoeda | de maart 2003 editie van Linux Journal zal een artikel over de api hebben |
|---|
| garoeda | dat is alles wat ik voorbereid heb, zijn er nog vragen, of punten van discussie |
|---|
| garoeda | opmerking: misschien handig om volgende url ook mee te geven: : http://www.openbsd.org/crypto.html |
|---|
| garoeda | vraag: welke suggesties zou je iemand willen geven die bv RSA voor de plugin api wil ontwikkelen |
|---|
| garoeda | dat weet ik nog niet, maar Jean-Luc Cooke heeft daaraan gewerkt |
|---|
| garoeda | zie ook http://jlcooke.ca/cryptoapi/pk/ voor een discussie over de cryptoapi-devel |
|---|
| garoeda | het is geen gebied waar ik al dieper op heb kunnen ingaan totnutoe |
|---|
| garoeda | vraag: heb je al naar mijn idee gekeken over "random ipsec" zonder authenticatie? lijkt het nuttig of heeft ipsec echt authenticatie nodig om nuttig te zijn? |
|---|
| garoeda | ik kan me hier iets van herinneren, ik heb daar gisteren nog van gelezen maar ik kan me de details niet herinneren |
|---|
| garoeda | maar ik denk dat ipsec in het algemeen authenticatie nodig heeft om vielig te zijn |
|---|
| garoeda | opmerking: |
|---|
| garoeda | het idee was eigenlijk ok een "default' ipsec implementatie te hebben die de crypto onderhandelt met onbekende hosts |
|---|
| garoeda | dus een groot deel van het internet verkeer wordt geencrypteerd |
|---|
| garoeda | en passief sniffen of grote hoeveelheden verkeer worden duur |
|---|
| garoeda | ik ken de volledige cryptografische implicaties niet, het moet verder onderzocht worden |
|---|
| garoeda | het kan eigenlijk een nieuw soort aanvallen mogelijk maken |
|---|
| garoeda | (bv .. je vertrouwt niet geauthenticeerde data) |
|---|
| garoeda | opmerking: ah, maar het gaat niet om echte trust, het maakt het passief sniffen van verkeer extreem 'duur' |
|---|
| garoeda | interessante idee |
|---|
| garoeda | zijn er verdere vragen over de api |
|---|
| garoeda | ok, dit was het einde van mijn presentatie, ik denk dat er een interesse is in een meer algemene crypto discussie |
|---|
| garoeda | (even discussie uitbreiden naar #linux) |
|---|
| garoeda | wat met het idee om op SMP systemen een cpu te reserveren voor crypto taken |
|---|
| garoeda | niet direct het beste idee, aangezien netwerkverkeer van de ene cpu cache naar ram en dan indere andere cpu cache moet verhuizen |
|---|
| garoeda | vraag: hoe kan een gewone gebruiker hier voordeel van ondervinden (de crypto api) |
|---|
| garoeda | het belangrijkste voor gebruikers is dat dingen zoals ipsec en disk encryptie deel gaan uitmaken van de standaard kernel |
|---|
| garoeda | (einde presentatie) |
|---|
| garoeda | (log note: end of presentation) |
|---|