Warning: Missing argument 2 for wpdb::prepare(), called in /home/stromber/public_html/kryptoblog/wp-content/plugins/wp-super-edit/wp-super-edit.core.class.php on line 109 and defined in /home/stromber/public_html/kryptoblog/wp-includes/wp-db.php on line 1222
Verktyg » Kryptoblog

Posts Tagged ‘Verktyg’

Test av sphlib

March 18th, 2009

Jag testade i går kväll att kompilera upp sphlib, det nya bibliotek med hashfunktioner jag bloggade om i går.

På Mac var det inte svårare än att packa upp distributionen och köra det medföljande byggscriptet. Inga varningar eller problem dök upp under bygget och scriptet kör tom ett test av de olika hashfunktionerna efter att de byggts.

Jag upptäckte att det sphlib inkluderade ett benchmark-program, vilket jag naturligtvis kört med följande resultat:


Speed test: MD2
message length = 16 -> 2.32 MBytes/s
message length = 64 -> 4.63 MBytes/s
message length = 256 -> 6.26 MBytes/s
message length = 1024 -> 6.79 MBytes/s
message length = 8192 -> 6.93 MBytes/s
long messages -> 6.92 MBytes/s

Speed test: MD4
message length = 16 -> 75.60 MBytes/s
message length = 64 -> 171.02 MBytes/s
message length = 256 -> 321.05 MBytes/s
message length = 1024 -> 406.36 MBytes/s
message length = 8192 -> 417.39 MBytes/s
long messages -> 425.46 MBytes/s

Speed test: MD5
message length = 16 -> 56.83 MBytes/s
message length = 64 -> 124.44 MBytes/s
message length = 256 -> 221.65 MBytes/s
message length = 1024 -> 271.13 MBytes/s
message length = 8192 -> 290.17 MBytes/s
long messages -> 294.69 MBytes/s

Speed test: SHA-0
message length = 16 -> 37.82 MBytes/s
message length = 64 -> 80.94 MBytes/s
message length = 256 -> 148.31 MBytes/s
message length = 1024 -> 177.09 MBytes/s
message length = 8192 -> 188.11 MBytes/s
long messages -> 187.60 MBytes/s

Speed test: SHA-1
message length = 16 -> 36.36 MBytes/s
message length = 64 -> 79.28 MBytes/s
message length = 256 -> 135.82 MBytes/s
message length = 1024 -> 163.81 MBytes/s
message length = 8192 -> 177.21 MBytes/s
long messages -> 177.21 MBytes/s

Speed test: SHA-224
message length = 16 -> 20.78 MBytes/s
message length = 64 -> 43.04 MBytes/s
message length = 256 -> 73.02 MBytes/s
message length = 1024 -> 85.98 MBytes/s
message length = 8192 -> 90.83 MBytes/s
long messages -> 91.31 MBytes/s

Speed test: SHA-256
message length = 16 -> 20.43 MBytes/s
message length = 64 -> 42.73 MBytes/s
message length = 256 -> 71.50 MBytes/s
message length = 1024 -> 88.58 MBytes/s
message length = 8192 -> 92.52 MBytes/s
long messages -> 91.48 MBytes/s

Speed test: SHA-384
message length = 16 -> 3.51 MBytes/s
message length = 64 -> 14.18 MBytes/s
message length = 256 -> 19.26 MBytes/s
message length = 1024 -> 25.63 MBytes/s
message length = 8192 -> 28.88 MBytes/s
long messages -> 29.02 MBytes/s

Speed test: SHA-512
message length = 16 -> 3.52 MBytes/s
message length = 64 -> 14.04 MBytes/s
message length = 256 -> 19.16 MBytes/s
message length = 1024 -> 25.92 MBytes/s
message length = 8192 -> 31.41 MBytes/s
long messages -> 30.98 MBytes/s

Speed test: RIPEMD
message length = 16 -> 51.34 MBytes/s
message length = 64 -> 111.15 MBytes/s
message length = 256 -> 195.46 MBytes/s
message length = 1024 -> 235.09 MBytes/s
message length = 8192 -> 250.24 MBytes/s
long messages -> 247.85 MBytes/s

Speed test: RIPEMD-128
message length = 16 -> 41.58 MBytes/s
message length = 64 -> 90.01 MBytes/s
message length = 256 -> 154.04 MBytes/s
message length = 1024 -> 185.11 MBytes/s
message length = 8192 -> 197.71 MBytes/s
long messages -> 194.94 MBytes/s

Speed test: RIPEMD-160
message length = 16 -> 28.73 MBytes/s
message length = 64 -> 59.71 MBytes/s
message length = 256 -> 102.10 MBytes/s
message length = 1024 -> 121.77 MBytes/s
message length = 8192 -> 127.55 MBytes/s
long messages -> 130.20 MBytes/s

Speed test: Tiger
message length = 16 -> 23.31 MBytes/s
message length = 64 -> 47.86 MBytes/s
message length = 256 -> 79.82 MBytes/s
message length = 1024 -> 95.64 MBytes/s
message length = 8192 -> 100.71 MBytes/s
long messages -> 101.67 MBytes/s

Speed test: Tiger2
message length = 16 -> 23.24 MBytes/s
message length = 64 -> 47.90 MBytes/s
message length = 256 -> 80.09 MBytes/s
message length = 1024 -> 95.35 MBytes/s
message length = 8192 -> 100.81 MBytes/s
long messages -> 101.47 MBytes/s

Speed test: PANAMA
message length = 16 -> 4.98 MBytes/s
message length = 64 -> 18.87 MBytes/s
message length = 256 -> 65.16 MBytes/s
message length = 1024 -> 170.89 MBytes/s
message length = 8192 -> 323.63 MBytes/s
long messages -> 370.26 MBytes/s

Speed test: HAVAL[3 passes]
message length = 16 -> 28.10 MBytes/s
message length = 64 -> 110.82 MBytes/s
message length = 256 -> 165.24 MBytes/s
message length = 1024 -> 233.50 MBytes/s
message length = 8192 -> 262.07 MBytes/s
long messages -> 266.82 MBytes/s

Speed test: HAVAL[4 passes]
message length = 16 -> 20.69 MBytes/s
message length = 64 -> 82.65 MBytes/s
message length = 256 -> 119.51 MBytes/s
message length = 1024 -> 163.86 MBytes/s
message length = 8192 -> 183.72 MBytes/s
long messages -> 187.14 MBytes/s

Speed test: HAVAL[5 passes]
message length = 16 -> 16.85 MBytes/s
message length = 64 -> 66.94 MBytes/s
message length = 256 -> 90.74 MBytes/s
message length = 1024 -> 127.20 MBytes/s
message length = 8192 -> 144.84 MBytes/s
long messages -> 148.33 MBytes/s

Speed test: WHIRLPOOL
message length = 16 -> 5.09 MBytes/s
message length = 64 -> 10.32 MBytes/s
message length = 256 -> 16.66 MBytes/s
message length = 1024 -> 19.62 MBytes/s
message length = 8192 -> 20.68 MBytes/s
long messages -> 20.90 MBytes/s

Speed test: SHABAL-224
message length = 16 -> 6.65 MBytes/s
message length = 64 -> 20.41 MBytes/s
message length = 256 -> 50.08 MBytes/s
message length = 1024 -> 78.70 MBytes/s
message length = 8192 -> 93.75 MBytes/s
long messages -> 96.67 MBytes/s

Speed test: SHABAL-256
message length = 16 -> 6.73 MBytes/s
message length = 64 -> 20.27 MBytes/s
message length = 256 -> 50.27 MBytes/s
message length = 1024 -> 78.07 MBytes/s
message length = 8192 -> 93.57 MBytes/s
long messages -> 97.57 MBytes/s

Speed test: SHABAL-384
message length = 16 -> 6.67 MBytes/s
message length = 64 -> 20.38 MBytes/s
message length = 256 -> 50.12 MBytes/s
message length = 1024 -> 78.22 MBytes/s
message length = 8192 -> 93.54 MBytes/s
long messages -> 96.53 MBytes/s

Speed test: SHABAL-512
message length = 16 -> 6.60 MBytes/s
message length = 64 -> 20.36 MBytes/s
message length = 256 -> 50.09 MBytes/s
message length = 1024 -> 78.29 MBytes/s
message length = 8192 -> 92.96 MBytes/s
long messages -> 95.80 MBytes/s

Speed test: RadioGatun[32]
message length = 16 -> 8.17 MBytes/s
message length = 64 -> 28.01 MBytes/s
message length = 256 -> 41.35 MBytes/s
message length = 1024 -> 139.11 MBytes/s
message length = 8192 -> 182.84 MBytes/s
long messages -> 190.25 MBytes/s

Speed test: RadioGatun[64]
message length = 16 -> 2.08 MBytes/s
message length = 64 -> 7.99 MBytes/s
message length = 256 -> 20.33 MBytes/s
message length = 1024 -> 41.67 MBytes/s
message length = 8192 -> 56.12 MBytes/s
long messages -> 58.12 MBytes/s

Tittar man på prestandasiffrorna ser man tydligt varför SHA-2-funktionerna har problem att ersätta SHA-1 i verkliga applikationer. Eftersom det även finns benchmark-funktionalitet i OpenSSL kan det vara intressant att jämföra prestandan i sphlib med OpenSSLs implementation:


js@stajlis>openssl speed sha1
To get the most accurate results, try to run this
program when this computer is idle.

Doing sha1 for 3s on 16 size blocks: 2584309 sha1’s in 2.90s
Doing sha1 for 3s on 64 size blocks: 1855209 sha1’s in 2.87s
Doing sha1 for 3s on 256 size blocks: 1016274 sha1’s in 2.86s
Doing sha1 for 3s on 1024 size blocks: 362232 sha1’s in 2.86s
Doing sha1 for 3s on 8192 size blocks: 51519 sha1’s in 2.83s
OpenSSL 0.9.7l 28 Sep 2006
built on: Sat Jul 12 01:44:36 PDT 2008
options:bn(64,32) md2(int) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: cc -arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe -arch ppc -arch ppc64 -arch i386 -arch x86_64 -pipe -DOPENSSL_NO_IDEA -DFAR=
available timing options: TIMEB USE_TOD HZ=100 [sysconf value]
timing function used: getrusage

The ‘numbers’ are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha1 14251.15k 41376.71k 90860.85k 129683.24k 149025.34k

Räknar jag om till MByte får jag 13 MByte/s för 16 Byte data och 145 MByte för 8192 Byte data, vilket är långsammare än sphlib som ger 36 MByte/s respektive 177 MByte. Men vad det sedan beror på (slump?) vågar jag inte ens gissa på. Det här är inte precis någon väl planerad jämförelse. sphlib verkar iaf inte vara brutalt mycket långsammare än OpenSSL.

Eftersom jag har en Dual Core-processor och OpenSSl stödjer att köra på multipla processorer kan det vara intressant att testa vad det ger:


js@stajlis.springfield.se:/Users/js/tmp/untar/sphlib-1.1/c>openssl speed sha1 -multi 2
Forked child 0
Forked child 1
+DT:sha1:3:16
+DT:sha1:3:16
...
...
Got: +H:16:64:256:1024:8192 from 0
Got: +F:5:sha1:12663250.54:35445082.87:81488482.11:115173498.84:133125038.17 from 0
Got: +H:16:64:256:1024:8192 from 1
Got: +F:5:sha1:12774171.87:38159683.91:83045579.61:118426319.78:135401122.10 from 1

timing function used:
sha1 25437.42k 73604.77k 164534.06k 233599.82k 268526.16k

En ganska rejäl prestandaökning, i stort sett 100%. Testade även att köra med än fler processer och fick inga större förändringar. Det verkar alltså som att OpenSSL verkligen lyckas använda båda kärnorna ordentligt.

(Ok, gissar att jag nu kommer att bli dränkt med kommentarer om var jag gick snett och gjort fel. Kom igen bara!)

sphlib ett nytt bibliotek med hashfunktioner

March 17th, 2009

Som en del av Projet RNRT SAPHIR (japp, det heter så, och webbplatsen är på franska) har Franska myndigheter släppt sphlib, ett nytt bibliotek med implementationer av olika hashfunktioner.

Sphlib innehåller implementationer i C och i Java av följande hashfunktioner:


haval128_3 HAVAL, 128-bit output, 3 passes
haval128_4 HAVAL, 128-bit output, 4 passes
haval128_5 HAVAL, 128-bit output, 5 passes
haval160_3 HAVAL, 160-bit output, 3 passes
haval160_4 HAVAL, 160-bit output, 4 passes
haval160_5 HAVAL, 160-bit output, 5 passes
haval192_3 HAVAL, 192-bit output, 3 passes
haval192_4 HAVAL, 192-bit output, 4 passes
haval192_5 HAVAL, 192-bit output, 5 passes
haval224_3 HAVAL, 224-bit output, 3 passes
haval224_4 HAVAL, 224-bit output, 4 passes
haval224_5 HAVAL, 224-bit output, 5 passes
haval256_3 HAVAL, 256-bit output, 3 passes
haval256_4 HAVAL, 256-bit output, 4 passes
haval256_5 HAVAL, 256-bit output, 5 passes
md2 MD2
md4 MD4
md5 MD5
panama Panama
radiogatun32 RadioGatun[32]
radiogatun64 RadioGatun[64]
ripemd RIPEMD (original function)
ripemd128 RIPEMD-128 (revised function, 128-bit output)
ripemd160 RIPEMD-160 (revised function, 160-bit output)

rmd RIPEMD (original function)
rmd128 RIPEMD-128 (revised function, 128-bit output)
rmd160 RIPEMD-160 (revised function, 160-bit output)

sha0 SHA-0 (original SHA, withdrawn)
sha1 SHA-1
sha224 SHA-224
sha256 SHA-256
sha384 SHA-384
sha512 SHA-512

shabal192 SHABAL-192
shabal224 SHABAL-224
shabal256 SHABAL-256
shabal384 SHABAL-384
shabal512 SHABAL-512

tiger Tiger
tiger2 Tiger2 (Tiger with a modified padding)

whirlpool Whirlpool (2003, current version)
whirlpool0 Whirlpool-0 (2000)
whirlpool1 Whirlpool-1 (2001)


(funktionsnamnet i biblioteket är det som står längst till vänster.)

Det går även att köra sphsum för att köra de olika funktionerna för att beräkna en hash av givet indata.

Enligt webbplatsen är licensen för biblioteket MIT-lik och BSD-lik. Verkar det förvirrat? Författarna förklarar licensen så här:


Licensing is specified in the LICENSE.txt file. This is an MIT-like, BSD-like open-source license. Basically, we will get the fame but not the blame. If you reuse our code in your own projects, and distribute the result, then you should state that you used our code and that we always disclaimed any kind of warranty, and will continue to do so in the foreseeable future, and beyond. You have no other obligation such as disclosing your own source code. See the LICENSE.txt file for the details in a lawyer-compatible language.

Jag har inte testat att bygga sphlib på min maskin än. Återkommer när jag gjort det.

CUDA på Mac

March 16th, 2009

Jag har nyligen blivit med en ny laptop, en Apple MacBook Unibody:

MacBook

Förutom mer minne och större hårddisk, vilket gör det lättare att köra de virtuella system jag använder vid hårdvaruutveckling kommer maskinen med praktiska funktioner som bakgrundsbelyst tangentbord (iaf praktiskt om man sitter uppe på nätterna.)

En annan bra sak med den nya laptopen är att den kommer med en grafikprocessor (GPU) från Nvidia kapabel att stödja Nvidias programmeringsmiljö CUDA. Compute Unified Device Architecture (CUDA) gör det möligt att relativt enkelt accelerera applikationer med dataparallellism genom att exekvera beräkningar parallellt på grafikprocessorn.

Jag testade att installera CUDA 2.0 på laptopen förra veckan. Installationen gick i stort sett utan några problem alls, speciellt efter att ha hittat den här utmärkta bloggpostningen om att installera CUDA 2.0 på Mac. Följer man instruktionerna kan man snart testa CUDA på sin maskin:


js@stajlis.springfield.se:/Developer/CUDA/bin/darwin/release>./deviceQuery
There is 1 device supporting CUDA

Device 0: “GeForce 9400M”

Major revision number: 1 Minor revision number: 1 Total amount of global memory: 266010624 bytes Number of multiprocessors: 2 Number of cores: 16 Total amount of constant memory: 65536 bytes Total amount of shared memory per block: 16384 bytes Total number of registers available per block: 8192 Warp size: 32 Maximum number of threads per block: 512 Maximum sizes of each dimension of a block: 512×512 x 64 Maximum sizes of each dimension of a grid: 65535×65535 x 1 Maximum memory pitch: 262144 bytes Texture alignment: 256 bytes Clock rate: 0.80 GHz Concurrent copy and execution: No

16 beräkningsenheter är inte precis enormt många, iaf inte i jämförelse med Nvidias Tesla. Nåja, det går dock att köra CUDA utan problem och Nvidias exempelapplikationer uppvisar en tydlig acceleration jämfört med en entrådars CPU-implementation. Jag upptäckte även att en totalt överspecad CUDA-applikation (ex nbody-applikationrn med 65535 kroppar att beräkna) totalt sänker Mac:en.

Slumptalsgeneratorn Mersenne Twister i CUDA-variant ger på min maskin följande prestanda:


js@stajlis.springfield.se:/Developer/CUDA/bin/darwin/release>./MersenneTwister
Using device 0: GeForce 9400M
Initializing data for 24000000 samples…
Loading CPU and GPU twisters configurations…
Generating random numbers on GPU
Generated samples : 24002560
RandomGPU() time : 77.352997
Samples per second: 3.102990E+08
Applying Box-Muller transformation on GPU
Transformed samples : 24002560
BoxMullerGPU() time : 35.231998
Samples per second : 6.812716E+08
Reading back the results…
Checking GPU results…
...generating random numbers on CPU using reference generator
...applying Box-Muller transformation on CPU
...comparing the results
Max absolute error: 2.264977E-06
L1 norm: 1.783765E-07

Jag har inte hunnit att hacka några egna CUDA-program. Förra året testade jag (min vana trogen) att koda strömkryptot RC4 i CUDA. Inte speciellt förvånande nog gav det dock ingen prestandaökning. Det var dock mer ett test av att jag fattat hur man kodar för CUDA. Skall försöka hinna koda lite CUDA under våren och då pröva med mer parallella algoritmer och applikationer.

Senare i år kommer (om tidplanen stämmer) Mac OS X 10.6 – Snow Leopard. I och med det borde det även finnas SDK på Mac för att koda för OpenCL, vilket verkar vara mindre yxigt och primitivt än CUDA. Återstår dock att se om det är så, när 10.6 väl dyker upp.

För den som vill testa CUDA har Raymond Tay som postade beskrivningen av installationen även postat en bra lista med CUDA-resurser. Om du testar CUDA och hackar några spännande algoritmer får du väldigt gärna posta kommentarer.

PS: En sak jag inte gillar med min nya Mac är att tangenterna skramlar. Speciellt mellanslagstangenten låter klonk modell en gammal Apple II. Men annars är den riktigt stajlish.

Artikel om att scripta SSH med Paramiko

March 1st, 2009

Jesse Noller har publicerat en artikel om hur man kan använda Pythonmodulen Paramiko för att scripta körningar med SSH. Artikeln har tidigare publicerats in Python Magazine. Artikelns sammanfattning förklarar närmare vad den handlar om:


OpenSSH is the ubiquitous method of remote access for secure remote-machine login and file transfers. Many people — systems administrators, test automation engineers, web developers and others have to use and interact with it daily. Scripting SSH access and file transfers with Python can be frustrating — but the Paramiko module solves that in a powerful way.

Paramiko är en modul med en ren Pythonimplementation (dvs inget anrop till C-bibliotek, exempelvis libssl) av SSH2. Modulen är LPGL-licensierad.

Kör beräkningar på din PS3:a

March 1st, 2009

(Har haft dom här länkarna liggande på tok för länge i min lista med intressanta saker…)

Enligt en artikel på Physorg har några forskare på Dartmouth-universitetet släppt ett system + instruktioner för att köra parallella beräkningar på en Sony PlayStation 3 (PS3).

Jag har inte testat på min egen maskin (än), men att döma av webbsidan för systemet är det ganska rätt fram att installera och köra. Är det någon som testat och har några åsikter skulle jag uppskatta en kommentar.

Svagheter i SHA-3-implementationer

February 22nd, 2009

Fortify har postat på sin blogg om en undersökning av säkerheten i referensimplementationerna av SHA-3-kandidaterna.

Fortify har använt sitt verktyg Fortify SCA, en linter speciellt utvecklad för att hitta kodmässiga svagheter som buffertöverskrivningar etc. (Det hade antagligen gått bra att använda splint eller liknande säkerhetsinriktade lintverktyg för att hitta svagheterna.)

Vad Fortify upptäckt är att ett antal av SHA-3-kandidaterna har mer eller mindre allvarliga svagheter i sin implementation, mer specifikt i Blender, Crunch, FSB, MD6, Vortex. Några typiska fel är att koden tillåter buffertöverskrivningar, att den läser utanför gränserna i en buffert (indexeringsfel) och minnesläckage. Som ett exempel tar Fortify upp MD6:


One of the projects with buffer issues was MD6, the implementation provided Professor Ron Rivest and his team. All of the problems came back to the hashval field of the md6_state struct:

unsigned char hashval[ (md6_c/2)*(md6_w/8) ];

The buffer size is determined by two constants:

#define w md6_w /* # bits in a word (64) */ #define c md6_c /* # words in compression output (16) */

At several points, this buffer is read or written to using a different bound:

if (z==1) /* save final chaining value in st->hashval */ { memcpy( st->hashval, C, md6_c*(w/8) ); return MD6_SUCCESS; }

Further analysis showed that ANSI standard layout rules would make incorrect behavior unlikely, but other compilers may have allowed it to be exploited. The MD6 team has doubled the size of the vulnerable buffer, which eliminated the risk. In this case, Fortify SCA found an issue that would have been difficult to catch otherwise.

The other buffer overflow was found in the Blender implementation, from Dr. Colin Bradbury. This issue was a classic typo:

DataLength sourceDataLength2[3];// high order parts of data length ... if (ss.sourceDataLength < (bcount | databitlen)) // overflow if (++ss.sourceDataLength2[0] 0) // increment higher order count if (++ss.sourceDataLength2[1] 0) // and the next higher order ++ss.sourceDataLength2[3]; // and the next one, etc.

The developer simply mistyped, using 3 instead of 2 for the array access. This issue was probably not caught because it would not be exposed without a very large input. The other issues we found were memory leaks and null dereferences from memory allocation.

Att den här typen av programmeringsfel kan få betydelse för SHA-3-tävlingen är uppenbart, och illustreras tydligt med MD6. Dess internbuffert behövde dubbleras i storlek. Detta gör att implementationer av MD6 för inbyggda system kommer att kräva mer minnesresurser än vad tidigare angetts. En av styrkorna med MD6 enligt dess skapare är att den skalar extremt bra ner till mycket små implementationer, och det argumentet fick sig nu nog en liten törn.

Ett annat skäl till varför jag tycker att Fortifys undersökning är bra är att referensimplementationer ofta används i applikationer. Antingen direkt eller som bas (funktionell referens) för en ny implementation. Därmed riskerar svagheter i referensimplementationen att sprida sig. Fortify tar själva upp ett exempel från en svaghet i referensimplementationen av RSA som lett till buggar i olika SSL-implementationer.

I fallet SHA-3, med dess fokus på prestanda, vilket gjort att skaparna av kandidater slitit och sliter med att optimera ut varenda cykel de kan ur sin kod, tror jag att referensimplementationer kommer att få stor användning i applikationskod.

OpenPGP SDK 0.9 släppt

January 18th, 2009

Ben Laurie och Rachel Williams har öppnat upp en Tracwebb för deras gemensamma projet SDK, en BSD-licensierad implementation av RFC 2440.

Enligt OpenPGP SDKs webbplats bygger SDK:n på Ubuntu och Fedora samt FreeBSD och Mac OS X.

Lite om OAuth

December 7th, 2008

Via Googles säkerhetsblogg sprang jag på ett projekt kallat OAuth. Vad är nu OAuth? Google ger en bra förklaring:


This standard is designed to provide a secure and privacy-preserving technique for enabling specific private data on one site to be accessed by another site. One popular reason for that type of cross-site access is data portability in areas such as personal health records (such as Google Health or Microsoft Healthvault), as well as social networks (such as OpenSocial enabled sites).

Eller som OAuth-projektet skriver på sin webbplats:


If you’re building…

* desktop applications * dashboard widgets or gadgets * Javascript or browser-based apps * webpage widgets

OAuth is a simple way to publish and interact with protected data. It’s also a safer and more secure way for people to give you access. We’ve kept it simple to save you time.

If you’re supporting…

* web applications * server-side APIs * mashups

If you’re storing protected data on your users’ behalf, they shouldn’t be spreading their passwords around the web to get access to it. Use OAuth to give your users access to their data while protecting their account credentials.

Googles Gadget-plattform har stöd för OAuth, version 1.0 av specen är spikad och det finns bibliotek för bland annat PHP, Rails, Python, .NET, C, och Perl.

Tor VM, en virtuell Tor-proxy

December 4th, 2008

För några veckor sedan dök det upp en blänkare på Cryptography om ett nytt verktyg – Tor VM.

Tor VM logo.

Tor VM är en transparent proxy för att köra DNS och TCP-trafik genom anonymiseringsnätverket. Men i stället för att ansluta direkt till Tor körs trafiken via proxyn som snurrar i en virtiuell maskin. Vitsen med detta förfarande är enligt Tor VM:s sida:


The major advantage of running Tor VM is the protection you get from IP disclosure attacks that could leak your true IP address.

Du kan bygga Tor VM från källkoden, och det finns färdiga paket för att köra Tor VM fristående. Det finns dessutom färdiga ISO-filer som går att köra i VMware Player.

Tor VM påpekar dock att Tor är en anonymiserat nätverk, men att trafiken i sig inte är skyddad:


Tor VM will not protect you from leaking personal information while in use; please take caution in protecting your personal identity and information by not sending it across the Tor network. The use of encryption (HTTPS) whenever possible is highly recommended.

Problem med arc4random i FreeBSD

December 3rd, 2008

Enligt en säkerhetsrapport från FreeBSD-projektet finns det ett problem med slumptalsgeneratorn arc4random.

FreeBSD-logo

Säkerhetsrapporten FreeBSD-SA-08.11.arc4random beskriver problemet så här:


I. Background
arc4random(9) is a generic-purpose random number generator based on the key stream generator of the RC4 cipher. It is expected to be cryptographically strong, and used throughout the FreeBSD kernel for a variety of purposes, some of which rely on its cryptographic strength.

arc4random(9) is periodically reseeded with entropy from the FreeBSD kernel’s Yarrow random number generator, which gathers entropy from a variety of sources including hardware interrupts. During the boot process, additional entropy is provided to the Yarrow random number generator from userland, helping to ensure that adequate entropy is present for cryptographic purposes.

II. Problem Description
When the arc4random(9) random number generator is initialized, there may be inadequate entropy to meet the needs of kernel systems which rely on arc4random(9); and it may take up to 5 minutes before arc4random(9) is reseeded with secure entropy from the Yarrow random number generator.

III. Impact
All security-related kernel subsystems that rely on a quality random number generator are subject to a wide range of possible attacks for the 300 seconds after boot or until 64k of random data is consumed. The list includes:

  • GEOM ELI providers with onetime keys. When a provider is configured in a way so that it gets attached at the same time during boot (e.g. it uses the rc subsystem to initialize) it might be possible for an attacker to recover the encrypted data.
  • GEOM shsec providers. The GEOM shsec subsytem is used to split a shared secret between two providers so that it can be recovered when both of them are present. This is done by writing the random sequence to one of providers while appending the result of the random sequence on the other host to the original data. If the provider was created within the first 300 seconds after booting, it might be possible for an attacker to extract the original data with access to only one of the two providers between which the secret data is split.
  • System processes started early after boot may receive predictable IDs.
  • The 802.11 network stack uses arc4random(9) to generate initial vectors (IV) for WEP encryption when operating in client mode and WEP authentication challenges when operating in hostap mode, which may be insecure.
  • The IPv4, IPv6 and TCP/UDP protocol implementations rely on a quality random number generator to produce unpredictable IP packet identifiers, initial TCP sequence numbers and outgoing port numbers. During the first 300 seconds after booting, it may be easier for an attacker to execute IP session hijacking, OS fingerprinting, idle scanning, or in some cases DNS cache poisoning and blind TCP data injection attacks.
  • The kernel RPC code uses arc4random(9) to retrieve transaction identifiers, which might make RPC clients vulnerable to hijacking

IV. Workaround
No workaround is available for affected systems.

V. Solution
NOTE WELL: Any GEOM shsec providers which were created or written to
during the first 300 seconds after booting should be re-created after
applying this security update.

Perform one of the following:
1) Upgrade your vulnerable system to 6-STABLE, or 7-STABLE, or to the RELENG_7_0, or RELENG_6_3 security branch dated after the correction date.

2) To patch your present system:
The following patches have been verified to apply to FreeBSD 6.3 and 7.0 systems.

a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility.

[FreeBSD 7.x]

  1. fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random.patch
  2. fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random.patch.asc

[FreeBSD 6.x]

  1. fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random6x.patch
  2. fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random6x.patch.asc

b) Apply the patch.

  1. cd /usr/src
  2. patch < /path/to/patch

c) Recompile your kernel as described in
and reboot the system.

Kör du FreeBSD, och speciellt om du använder GEOM och GBDE bör du patcha eller uppgradera ditt system (om du inte redan gjort det).