From nisse@lysator.liu.se Sat Mar 2 00:44:19 1996 From: "Niels Möller" Subject: Välkomna till ncash-list To: ncash-list@lysator.liu.se Date: Sat, 2 Mar 1996 00:21:35 +0100 (MET) X-From-Line: nisse@lysator.liu.se Sat Mar 2 00:21 MET 1996 Received: from tintin.lysator.liu.se (nisse@tintin.lysator.liu.se [130.236.253.26]) by lysander.lysator.liu.se (8.7.4/8.7.3) with ESMTP id AAA12091 for ; Sat, 2 Mar 1996 00:21:40 +0100 (MET) Received: (from nisse@localhost) by tintin.lysator.liu.se (8.7.4/8.7.3) id AAA19499; Sat, 2 Mar 1996 00:21:35 +0100 (MET) Message-Id: <199603012321.AAA19499@tintin.lysator.liu.se> MIME-Version: 1.0 Content-transfer-encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-Content-Length: 3476 Lines: 103 Xref: tintin.lysator.liu.se mail.archive:224 mail.ncash-list:2 X-Gnus-Article-Number: 2 Sat Mar 2 00:26:44 1996 Hej! Jag tänkte börja med att förklara avsikterna med dels ncash, dels denna postlista. MÅL ncash ska alltså i någon mening kunna ersätta vanliga kontanter. För att göra detta är designmålen: × Det ska vara elektroniska *kontanter*, dvs kontroll av att det finns täckning ska göras när pengarna tas ut, inte vid betalningstillfället. × Anonymitet: Banken ska inte kunna veta vilka som handlar med varandra. Dessutom ska köparen vid ett betalningstillfälle kunna vara anonym. × Säkerhet: Systemet ska vara minst lika säkert som traditionella papperspengar. Ingen part ska kunna fuska utan att det upptäcks tämligen omedelbart. Det vill säga, om man deltar i en transaktion, och övriga inblandade ser ut att följa protokollen, så ska man kunna vara säker på att allt gått rätt till. × Öppenhet. Säkerheten ska inte vara beroende av att algoritmer och protokoll hemlighålls; endast parternas privata nycklar behöver skyddas. Alla specifikationer och all källkod måste vara tillgänglig. × För att göra det hela praktiskt användbart, så måste det också finnas någon möjlighet att flytta pengar mellan den digitala banken och vanliga pengar. Därför tänkte jag koppla ihop systemet med något konto hos en traditionell bank eller betalningsförmedlare, antagligen postgirot. POSTLISTAN, OCH ANDRA CYBRIGA DETALJER Sysftet med den här postlistan är dels att jag ska informera om vad som händer. Dels för att jag ska få hjälp med era synpunkter och erfarenheter. Officiellt språk är tills vidare svenska. Jag tänker också arkivera listan, om jag bara kommer överrens med sendmail. Detta arkiv, tillsammans med övrig dokumentation och kod, kommer antagligen upp nånstans på www så småningom. Prenumerationsärenden: ncash-request@lysator.liu.se Inlägg: ncash-list@lysator.liu.se Än så länge är vi åtta personer. De som vill får gärna presentera sig själva. TIDSPLAN Tidsplanen är än så länge rätt diffus. Förhoppningsvis ska systemet kunna provköras till hösten. Jag hoppas att några av er är intresserade av att ställa upp som försökspersoner när det blir dags. För er som undrar vad jag gör av resten av tiden, så är en del av svaret att jag undervisar analys på halvtid, och kommer att fortsätta med det resten av våren. Dessutom har jag läst kursen "konkret matematik", som jag tentar om tre veckor. NAMN Projektet heter tills vidare "ncash". Fantasifullare namnförslag tas varmt emot. IMPLEMENTATION Jag har nästan bestämt mig för att skriva större delen av koden i språket Python, ett trevligt interpreterat programspråk utvecklat vid CWI i Amsterdam. Trevliga egenskaper med python är att det är lätt att koppla ihop med andra program, hantera filer, strängar, etc. Python brukar ibland beskrivas med orden "som perl, men läsbart". Dessutom finns det stora heltal inbyggda, och det finns en del färdiga paket för bland annat kryptering. AKTUELL STATUS Jag har ägnat hösten åt att läsa in mig på ämnet. Och så har jag hittills skrivit några klasser dels för att hantera de grupper som systemet kommer att bygga på, dels för att hantera postgirots antika hålkortsinspirerade system för elektronisk överföring av betalningsorder. REFERENSER En mycket bra introduktion till elektroniska pengar och relaterade saker ges av David Chaums artiklar http://www.digicash.com/publish/sciam.html http://www.digicash.com/publish/bigbro.html . ncash kommer att följa Stefan Brands ideér ganska nära, se http://www.cwi.nl/~brands /Niels Möller From nisse@lysator.liu.se Tue Mar 5 06:55:01 1996 From: "Niels Möller" Subject: Nätverk To: ncash-list@lysator.liu.se Date: Tue, 5 Mar 1996 06:46:05 +0100 (MET) X-From-Line: nisse@lysator.liu.se Tue Mar 5 06:46 MET 1996 Received: from tintin.lysator.liu.se (nisse@tintin.lysator.liu.se [130.236.253.26]) by lysander.lysator.liu.se (8.7.4/8.7.3) with ESMTP id GAA11015; Tue, 5 Mar 1996 06:46:08 +0100 (MET) Received: (from nisse@localhost) by tintin.lysator.liu.se (8.7.4/8.7.3) id GAA02893; Tue, 5 Mar 1996 06:46:05 +0100 (MET) Message-Id: <199603050546.GAA02893@tintin.lysator.liu.se> MIME-Version: 1.0 Content-transfer-encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-Content-Length: 914 Lines: 30 Xref: tintin.lysator.liu.se mail.archive:231 mail.ncash-list:3 X-Gnus-Article-Number: 3 Tue Mar 5 06:52:47 1996 Nu har jag lyckats skriva lite socketkod också. Exempel: på tintin: import Connection # Min modul server = Connection.Server(28849) # portnummer server.run(test_handler) # Ta emot uppkopplingar på annan dator, tingeling: import Connection, pickle client = Connection.Client('tintin', 28849) p = pickle.Pickler(client) p.dump({'key':47, 'data':'nåt meddelande' }) # Här skickar jag över # en "dictionary", men # det går bra med nästan # godtyckliga pythonobjekt. Och på tintin: Connection from tingeling.lysator.liu.se... {'key': 47, 'data': 'nåt meddelande'} Och så har jag tittat igenom manualen för krypteringspaketet till python. Nästa steg blir nog att lägga till autenticering, nyckelutbyte och kryptering till nätverksförbindelsen. Samt att äta frukost. /Nisse From nisse@lysator.liu.se Thu Mar 7 01:45:03 1996 Return-Path: nisse@lysator.liu.se Received: from tintin.lysator.liu.se (nisse@tintin.lysator.liu.se [130.236.253.26]) by lysander.lysator.liu.se (8.7.4/8.7.3) with ESMTP id BAA27655; Thu, 7 Mar 1996 01:45:02 +0100 (MET) Received: (from nisse@localhost) by tintin.lysator.liu.se (8.7.4/8.7.3) id BAA12678; Thu, 7 Mar 1996 01:44:59 +0100 (MET) Date: Thu, 7 Mar 1996 01:44:59 +0100 (MET) Message-Id: <199603070044.BAA12678@tintin.lysator.liu.se> From: "Niels Möller" To: ncash-list@lysator.liu.se Subject: Anonym autenticering MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Jag behöver ett protokoll för anonym autentisering och nyckelutbyte. Med det menar jag att skapa en säker, krypterad uppkoppling, där den ena parten vill vara säker på att hon pratar med rätt person, utan att behöva röja sin egen identitet. Utgångspunkt: Alice har Bobs publika nyckel, och är av någon anledning säker på att det är rätt (låt oss kalla kryptering med denna nyckel för E_b). Alice vill tala med bob, utan att uppge sin anonymitet. Eller så är hon beredd att uppge sin identitet, men bara för Bob. Detta borde inte vara så svårt. Två varianter: Alice Bob Skapa en slumpmässig nyckel k. Beräkna E_b(k), och skicka till Bob -------> Dekryptera, och använd k som sessionsnyckel. Skicka tillbaka "Jag är Bob" samt något Kontrollera att meddelandet <------- slumpmässigt tal, allt krypterat börjar med "Jag är Bob". med k. Alice Bob Skapa slumpmässigt tal k_1, och skicka g^{k_1} till Bob -------> Skapa slumpmässigt k_2, ta meddelandet ("Jag är Bob", g^{k_2}, slumpmässigt tal), kryptera med sessionsnyckeln g^{k_1 k_2}, signera både klar- och kryptotext med hjälp av den hemliga nyckeln, och skicka Verifiera signaturen, och <------- tillbaka till Alice. att meddelandet verkligen är krypterat med g^{k_1 k_2}. Det viktiga är att Alice kan upptäcka en "man-in-the-middle" attack. Är det nödvändigt att Bob skapar unika meddelanden genom att lägga till slumptal eller tidsstämplar, eller räcker det att Bob bara svarar med "Bob"? From nisse@lysator.liu.se Thu Mar 7 17:06:47 1996 Return-Path: nisse@lysator.liu.se Received: from tintin.lysator.liu.se (nisse@tintin.lysator.liu.se [130.236.253.26]) by lysander.lysator.liu.se (8.7.4/8.7.3) with ESMTP id RAA03895 for ; Thu, 7 Mar 1996 17:06:46 +0100 (MET) Received: (from nisse@localhost) by tintin.lysator.liu.se (8.7.4/8.7.3) id RAA14777; Thu, 7 Mar 1996 17:06:33 +0100 (MET) Date: Thu, 7 Mar 1996 17:06:33 +0100 (MET) Message-Id: <199603071606.RAA14777@tintin.lysator.liu.se> From: "Niels Möller" To: ncash-list@lysator.liu.se In-reply-to: viiveke@isy.liu.se's message of Thu, 7 Mar 1996 11:17:06 +0100 (MET) Subject: Re: Anonym autenticering MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit References: viiveke@isy.liu.se (Viiveke F?k (?= a letter UNIX can't handle)) writes: > >Jag behöver ett protokoll för anonym autentisering och nyckelutbyte. > >Med det menar jag att skapa en säker, krypterad uppkoppling, där den > >ena parten vill vara säker på att hon pratar med rätt person, utan att > >behöva röja sin egen identitet. > > För att vara säker på att vi talar om samma problem: > Alice kan skicka meddelanden som bara Bob kan läsa, och hon kan verifiera > att Bob sänt ett givet meddelande. Alice vill nu kunna ta emot meddelanden > som bara hon kan läsa och/eller ge Bob möjlighet att verifiera att > meddelanden hör ihop med vissa andra, utan att Bob därför vet vem mer än > han som kan läsa eller vem som är motparten i en sekvens av > meddelanden. Jo, så kan man beskriva det. Det är en dubbelriktad förbindelse (TCP) som man utbyter meddelandena över. Antagligen är Alice en kund till Bob. > >Alice Bob > > > >Skapa en slumpmässig nyckel k. > >Beräkna E_b(k), och skicka till > >Bob -------> Dekryptera, och använd k som > > sessionsnyckel. Skicka tillbaka > > "Jag är Bob" samt något > >Kontrollera att meddelandet <------- slumpmässigt tal, allt krypterat > >börjar med "Jag är Bob". med k. > Resultat:Alice vet att bara Bob kan skicka korrekta meddelanden krypterade > med hennes slumpnyckel k, eftersom bara Bob kan dekryptera Alice > meddelande. Bob vet att allt han tar emot krypterat med nyckeln k kommer > från den som ursprungligen skickade honom den. För båda gäller detta > förutsatt att meddelandet har ett format med tillräcklig redundans och att > man inte använder oåterkopplade blockkrypton eller övrlagringskryptering. > (Om man gör något av de två sist nämnda misstagen, kan Eve ändra > meddelanden i sekvensen på ett för henne förutsebart sätt.) Man behöver alltså använda nåt blockkrypto som idea eller 3des, i CBC mode. > Det slumpmässiga talet ger Bob möjlighet att kontrollera att han > inte spelar med i en upprepning av någon tidigare session, men då > måste det blandas in i nästa steg, som inte finns med här. Det hade jag inte tänkt så mycket på. Det borde väl räcka att Alice skickar tillbaka talet som det första meddelandet på den krypterade kanalen (?) > >Alice Bob > > > >Skapa slumpmässigt tal k_1, > >och skicka g^{k_1} till Bob -------> Skapa slumpmässigt k_2, tag > > meddelandet ("Jag är Bob", > > g^{k_2}, slumpmässigt tal), > > kryptera med sessionsnyckeln > > g^{k_1 k_2}, signera både klar- > > och kryptotext med hjälp av den > > hemliga nyckeln, och skicka > >Verifiera signaturen, och <------- tillbaka till Alice. > >att meddelandet verkligen > >är krypterat med g^{k_1 k_2}. > Här blir det "öppen nyckeldistribution" i stället för "kryptering av > sessionsnyckel med öppen nyckel". > Bob har redan lagt in en slump unik för denna meddelandesekvens då han > skapade k_2. Det borde räcka. I övrigt gäller även här att när nyckeln väl > skapats, så vet Alice att bara Bob har kunnat vara motpart, eftersom han > signerat parametern, som gjort det möjligt för henne att få fram > sessionsnyckeln. Bob vet att hans motpart måste vara den som skickade honom > det första värdet, förutsatt att meddelandena får korrekt struktur, då de > dekrypteras med den nyckel han räknat fram. Eftersom han varit med och > bestämt värdet på sessionsnyckeln, kan det inte vara en uppspelning av en > tidigare session. > > > >Det viktiga är att Alice kan upptäcka en "man-in-the-middle" attack. > >Är det nödvändigt att Bob skapar unika meddelanden genom att lägga > >till slumptal eller tidsstämplar, eller räcker det att Bob bara svarar > >med "Bob"? > Alltså: I fall ett måste Bob lägga till information, som är unik för > sessionen, i fall två har han automatiskt gjort det då nyckeln skapas. Helst skulle jag vilja att ingen klartext alls skickas över, dvs om nån råkar avlyssna den fysiska förbindelsen, så ska det inte gå att se vilka det är som kommunicerar (det räcker naturligtvis inte för att Alice ska vara helt omöjlig att spåra (det finns ju adresser i nätverkspaketen), men det vore ändå en trevlig egenskap. En variant är diffie-hellmanutbyte, där Bob skickar över en signatur över den *krypterade* kanalen: Alice Bob Generera slumpm k_1, skicka över g^{k_1} --> Generera slumpm k_2 , <-- skicka över g^{k_2} Från och med nu krypteras förbindelsen med sessionsnyckeln K = g^{k_1 + k_2}}. Den är naturligtvis än så länge sårbar för en man-in-the-middle attack. Skicka över en signatur för g^{k_2}, krypterad Kontrollera <-- med K. signaturen. Det borde kunna funka, med samma förbehåll om att man bör använda ett återkopplat blockkrypto. Kan det vara ett problem att det blir lättare att falskeligen skapa signaturen i sista steget, då det signerade meddelandet g^{k_2} inte innehåller någon redundans? Jag tror inte det: Om Eve till exempel kan generera ett signerat meddelande (g^{k_2}, sign) genom att välja signaturen först, och skapa meddelandet sen (som med naiv RSA-signering), så måste hon ändå räkna ut den diskreta logaritmen k_2 för att komma åt sessionsnyckeln. Ännu en variant är att Bob i sista steget istället signerar hela sessionsnyckeln g^{k_1 + k_2}, inte bara sin del av den, men det är nog ingen förbättring, möjligen tvärtom. /Niels From nisse@lysator.liu.se Thu Mar 7 18:10:59 1996 Return-Path: nisse@lysator.liu.se Received: from tintin.lysator.liu.se (nisse@tintin.lysator.liu.se [130.236.253.26]) by lysander.lysator.liu.se (8.7.4/8.7.3) with ESMTP id SAA10487 for ; Thu, 7 Mar 1996 18:10:58 +0100 (MET) Received: (from nisse@localhost) by tintin.lysator.liu.se (8.7.4/8.7.3) id SAA15132; Thu, 7 Mar 1996 18:10:55 +0100 (MET) Date: Thu, 7 Mar 1996 18:10:55 +0100 (MET) Message-Id: <199603071710.SAA15132@tintin.lysator.liu.se> From: "Niels Möller" To: ncash-list@lysator.liu.se Subject: [viiveke@isy.liu.se (Viiveke F?k (?= a letter UNIX can't handle))] Re: Anonym autenticering Message-Id: <199603071526.QAA14674@tintin.lysator.liu.se> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit BCC: nisse Jag vidare befordrar detta svar till listan. ------- Start of forwarded message ------- From: viiveke@isy.liu.se (Viiveke F?k (?= a letter UNIX can't handle)) Subject: Re: Anonym autenticering To: "Niels M\vller" Date: Thu, 7 Mar 1996 11:17:06 +0100 (MET) >Jag behöver ett protokoll för anonym autentisering och nyckelutbyte. >Med det menar jag att skapa en säker, krypterad uppkoppling, där den >ena parten vill vara säker på att hon pratar med rätt person, utan att >behöva röja sin egen identitet. För att vara säker på att vi talar om samma problem: Alice kan skicka meddelanden som bara Bob kan läsa, och hon kan verifiera att Bob sänt ett givet meddelande. Alice vill nu kunna ta emot meddelanden som bara hon kan läsa och/eller ge Bob möjlighet att verifiera att meddelanden hör ihop med vissa andra, utan att Bob därför vet vem mer än han som kan läsa eller vem som är motparten i en sekvens av meddelanden. Då har du följande förslag: >Detta borde inte vara så svårt. Två varianter: > >Alice Bob > >Skapa en slumpmässig nyckel k. >Beräkna E_b(k), och skicka till >Bob -------> >Dekryptera, och använd k som > >sessionsnyckel. Skicka tillbaka > >"Jag är Bob" samt något >Kontrollera att meddelandet <------- slumpmässigt tal, allt krypterat >börjar med "Jag är Bob". med k. Resultat:Alice vet att bara Bob kan skicka korrekta meddelanden krypterade med hennes slumpnyckel k, eftersom bara Bob kan dekryptera Alice meddelande. Bob vet att allt han tar emot krypterat med nyckeln k kommer från den som ursprungligen skickade honom den. För båda gäller detta förutsatt att meddelandet har ett format med tillräcklig redundans och att man inte använder oåterkopplade blockkrypton eller övrlagringskryptering. (Om man gör något av de två sist nämnda misstagen, kan Eve ändra meddelanden i sekvensen på ett för henne förutsebart sätt.) Det slumpmässiga talet ger Bob möjlighet att kontrollera att han inte spelar med i en upprepning av någon tidigare session, men då måste det blandas in i nästa steg, som inte finns med här. > >Alice Bob > >Skapa slumpmässigt tal k_1, >och skicka g^{k_1} till Bob -------> Skapa slumpmässigt k_2, ta > >meddelandet ("Jag är Bob", > >g^{k_2}, slumpmässigt tal), > >kryptera med sessionsnyckeln > >g^{k_1 k_2}, signera både klar- > >och kryptotext med hjälp av den > >hemliga nyckeln, och skicka >Verifiera signaturen, och <------- tillbaka till Alice. >att meddelandet verkligen >är krypterat med g^{k_1 k_2}. Här blir det "öppen nyckeldistribution" i stället för "kryptering av sessionsnyckel med öppen nyckel". Bob har redan lagt in en slump unik för denna meddelandesekvens då han skapade k_2. Det borde räcka. I övrigt gäller även här att när nyckeln väl skapats, så vet Alice att bara Bob har kunnat vara motpart, eftersom han signerat parametern, som gjort det möjligt för henne att få fram sessionsnyckeln. Bob vet att hans motpart måste vara den som skickade honom det första värdet, förutsatt att meddelandena får korrekt struktur, då de dekrypteras med den nyckel han räknat fram. Eftersom han varit med och bestämt värdet på sessionsnyckeln, kan det inte vara en uppspelning av en tidigare session. > >Det viktiga är att Alice kan upptäcka en "man-in-the-middle" attack. >Är det nödvändigt att Bob skapar unika meddelanden genom att lägga >till slumptal eller tidsstämplar, eller räcker det att Bob bara svarar >med "Bob"? Alltså: I fall ett måste Bob lägga till information, som är unik för sessionen, i fall två har han automatiskt gjort det då nyckeln skapas. Viiveke ---------------------------------------------------------------------------- ----------------------------------- Viiveke Fåk Department of Electrical Engineering Linköping University S-581 83 Linköping Sweden Tel: +46 13 281722 e-mail: Viiveke@isy.liu.se ------- End of forwarded message ------- From viiveke@isy.liu.se Mon Mar 11 09:35:39 1996 Return-Path: viiveke@isy.liu.se Received: from isy.liu.se (root@isy.liu.se [130.236.1.3]) by lysander.lysator.liu.se (8.7.4/8.7.3) with SMTP id JAA06877; Mon, 11 Mar 1996 09:35:38 +0100 (MET) Received: from jewel.isy.liu.se by isy.liu.se (5.65b/isy.minimaster-V1.0b2) id AA16824; Mon, 11 Mar 96 09:35:36 +0100 Received: from [130.236.26.53] (macvf [130.236.26.53]) by jewel.isy.liu.se (8.7/8.7) with SMTP id JAA28297; Mon, 11 Mar 1996 09:35:35 +0100 (MET) Date: Mon, 11 Mar 1996 09:35:35 +0100 (MET) X-Sender: viiveke@it.isy.liu.se Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: "Niels M\vller" From: viiveke@isy.liu.se (Viiveke F?k (?= a letter UNIX can't handle)) Subject: Re: Anonym autenticering Cc: ncash-list@lysator.liu.se > >Alice Bob >> > >> >Skapa slumpm=E4ssigt tal k_1, >> >och skicka g^{k_1} till Bob -------> Skapa slumpm=E4ssigt k_2, tag >> > meddelandet ("Jag =E4r Bob", >> > g^{k_2}, slumpm=E4ssigt tal), >> > kryptera med sessionsnyckeln >> > g^{k_1 k_2}, signera b=E5de klar= - >> > och kryptotext med hj=E4lp av de= n >> > hemliga nyckeln, och skicka >> >Verifiera signaturen, och <------- tillbaka till Alice. >> >att meddelandet verkligen >> >=E4r krypterat med g^{k_1 k_2}. > >> Diverse om slumptal och man-in-the-middle borttaget > >Helst skulle jag vilja att ingen klartext alls skickas =F6ver, dvs om >n=E5n r=E5kar avlyssna den fysiska f=F6rbindelsen, s=E5 ska det inte g=E5= att se >vilka det =E4r som kommunicerar (det r=E4cker naturligtvis inte f=F6r att >Alice ska vara helt om=F6jlig att sp=E5ra (det finns ju adresser i >n=E4tverkspaketen), men det vore =E4nd=E5 en trevlig egenskap. > >En variant =E4r diffie-hellmanutbyte, d=E4r Bob skickar =F6ver en signatur >=F6ver den *krypterade* kanalen: > >Alice Bob >Generera slumpm k_1, >skicka =F6ver g^{k_1} --> Generera slumpm k_2 , > <-- skicka =F6ver g^{k_2} > > Fr=E5n och med nu krypteras f=F6rbindelsen med > sessionsnyckeln K =3D g^{k_1 + k_2}}. Den =E4r > naturligtvis =E4n s=E5 l=E4nge s=E5rbar f=F6r en > man-in-the-middle attack. > > Skicka =F6ver en signatur > f=F6r g^{k_2}, krypterad >Kontrollera <-- med K. >signaturen. > >Det borde kunna funka, med samma f=F6rbeh=E5ll om att man b=F6r anv=E4nda e= tt >=E5terkopplat blockkrypto. Kan det vara ett problem att det blir l=E4ttare >att falskeligen skapa signaturen i sista steget, d=E5 det signerade >meddelandet g^{k_2} inte inneh=E5ller n=E5gon redundans? Jag tror inte >det: Om Eve till exempel kan generera ett signerat meddelande >(g^{k_2}, sign) genom att v=E4lja signaturen f=F6rst, och skapa >meddelandet sen (som med naiv RSA-signering), s=E5 m=E5ste hon =E4nd=E5 >r=E4kna ut den diskreta logaritmen k_2 f=F6r att komma =E5t sessionsnyckeln= . Detta funkar bra. Om man vill ha b=E5de h=E4ngslen och livrem (signaturen = =E4r ju mulitplikativt linj=E4r, och utan redundans i meddelandet kan det bli besv=E4rande i l=E4ngden) kan man l=E4tt l=E4gga till godtycklig redundans,= t ex signera (g^k_2,g^k_2). > >=C4nnu en variant =E4r att Bob i sista steget ist=E4llet signerar hela >sessionsnyckeln g^{k_1 + k_2}, inte bara sin del av den, men det =E4r >nog ingen f=F6rb=E4ttring, m=F6jligen tv=E4rtom. > >/Niels Nej, det vinner man inget p=E5. Viiveke ---------------------------------------------------------------------------- ----------------------------------- Viiveke F=E5k Department of Electrical Engineering Link=F6ping University S-581 83 Link=F6ping Sweden Tel: +46 13 281722 e-mail: Viiveke@isy.liu.se From nisse@lysator.liu.se Thu Mar 21 03:49:12 1996 Return-Path: nisse@lysator.liu.se Received: from tintin.lysator.liu.se (nisse@tintin.lysator.liu.se [130.236.253.26]) by lysander.lysator.liu.se (8.7.4/8.7.3) with ESMTP id DAA08092; Thu, 21 Mar 1996 03:49:11 +0100 (MET) Received: (from nisse@localhost) by tintin.lysator.liu.se (8.7.4/8.7.3) id DAA07482; Thu, 21 Mar 1996 03:49:08 +0100 (MET) Date: Thu, 21 Mar 1996 03:49:08 +0100 (MET) Message-Id: <199603210249.DAA07482@tintin.lysator.liu.se> From: "Niels Möller" To: ncash-list@lysator.liu.se, Stefan.Brands@cwi.nl, 4028@lyskom.lysator.liu.se Subject: NCash WWW-site MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit I have now put up some preliminary information on the web, at http://www.lysator.liu.se/~nisse/NCash . The README file says: This corner of the WWW is devoted to information, documentation and source for the NCash digital cash experiment. The files currently here are links right into my source tree, so don't be surprised if they are inconsistent or contain bugs. You can also find the archive for the NCash mailing list (mostly in Swedish). If you want to subscribe, send a message to ncash-request@lysator.liu.se . Some day, this information might transmute into a set of full-featured WWW pages in a zillion colors, but don't hold your breath. /Niels Möller From nisse@lysator.liu.se Tue Apr 16 09:55:21 1996 Return-Path: nisse@lysator.liu.se Received: from lysistrate.lysator.liu.se (nisse@lysistrate.lysator.liu.se [130.236.254.161]) by lysander.lysator.liu.se (8.7.4/8.7.3) with ESMTP id JAA10238; Tue, 16 Apr 1996 09:55:21 +0200 (MET DST) Received: (from nisse@localhost) by lysistrate.lysator.liu.se (8.7.3/8.7.3) id JAA01901; Tue, 16 Apr 1996 09:53:28 +0200 (MET DST) Date: Tue, 16 Apr 1996 09:53:28 +0200 (MET DST) Message-Id: <199604160753.JAA01901@lysistrate.lysator.liu.se> From: "Niels Möller" To: ncash-list@lysator.liu.se Subject: Datorproblemen lösta MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Matematiska institutionen har vänligen lånat mig en dator (!) Närmare bestämt en sprillans ny pentiumburk med 16 MB minne och 1 GB disk, körandes li(g)nux. Den finnns inte i DNS än, men den finns på nätet sedan i söndags kväll, 130.236.72.60. /Niels From nisse@lysator.liu.se Thu Apr 25 08:36:45 1996 Return-Path: nisse@lysator.liu.se Received: from tingeling.lysator.liu.se (nisse@tingeling.lysator.liu.se [130.236.253.25]) by lysander.lysator.liu.se (8.7.4/8.7.3) with ESMTP id IAA03432; Thu, 25 Apr 1996 08:36:44 +0200 (MET DST) Received: (from nisse@localhost) by tingeling.lysator.liu.se (8.7.4/8.7.3) id IAA19526; Thu, 25 Apr 1996 08:36:39 +0200 (MET DST) Date: Thu, 25 Apr 1996 08:36:39 +0200 (MET DST) Message-Id: <199604250636.IAA19526@tingeling.lysator.liu.se> From: "Niels Möller" To: ncash-list@lysator.liu.se, 4028@lyskom.lysator.liu.se Subject: Säkra nätverksförbindelser MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Nu har jag fått ihop lite kod för nätverksförbindelser med autenticering (av den ena parten) och kryptering. För att testa det har jag gjort en liten kalkylatorapplikation ovanpå. Uppkopplingen tar tyvärr en del tid, upp till nån minut, antagligen beroende på att de inbyggda heltalen i python inte är så snabba. Det finns en modul som använde gmp-biblioteket, vilket borde vara effektivare, men den verkar lite buggig så den använder jag inte för närvarande. Just nu körs en server på tingeling.lysator.liu.se, port 28857, som accepterar uppkopplingar, förhandlar fram en sessionsnyckel, och därefter förvandlas till en enkel RPN kalkylator, fast med krypterade in och utgångar. (Enda egenheten är att vid exponentieringar så reduceras resultatet till att ligga inom området ±N, där N=3^500. Det är nog inte särskilt användbart, men ska förhoppningsvis göra det lite svårare att hänga servern av misstag). Koden finns att titta på, http://www.lysator.liu.se/~nisse/NCash/source.html . Om nån vill provköra, så måste man först installera python och Python Cryptography Toolkit. Sen ser man till att befinna sig i biblioteket med koden i, och så startar man med % python >>> import CalcClient >>> CalcClient.calc('tingeling.lysator.liu.se') Connected to: Calculator (Tar en bra stund att komma hit) Calc> Kolla i CalcClient.py för att se vad den förstår för kommandon. På lysator kör man enklast ~nisse/bin/sun4/python-plain, (kryptomodulerna ligger i ~nisse/usr/local/bin/python/sun5, kan nån lista ut hur man installerar dem globalt, så ordna gärna det). /Niels Möller From nisse@lysator.liu.se Wed Jun 5 19:32:31 1996 Return-Path: nisse@lysator.liu.se Received: from tindra.lysator.liu.se (nisse@tindra.lysator.liu.se [130.236.253.27]) by lysander.lysator.liu.se (8.7.4/8.7.3) with ESMTP id TAA06977; Wed, 5 Jun 1996 19:32:28 +0200 (MET DST) Received: (from nisse@localhost) by tindra.lysator.liu.se (8.7.4/8.7.3) id TAA10741; Wed, 5 Jun 1996 19:33:51 +0200 (MET DST) Date: Wed, 5 Jun 1996 19:33:51 +0200 (MET DST) Message-Id: <199606051733.TAA10741@tindra.lysator.liu.se> From: "Niels Möller" To: Stefan.Brands@cwi.nl Cc: ncash-list@lysator.liu.se Subject: Parallell attack? MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit References: <9602271420.AA23881=brands@den.cwi.nl> Hello As you probably know, my experiment with digital cash (http://www.lysator.liu.se/~nisse/NCash) will be based on the system you published in 93. Now someone made me aware of a "parallell attack" on that and similar systems: two cooperating users executing the withdrawal protocol simultaneously can withdraw coins that they can doublespend without being identified. Do you have any paper that describes what this is about? For me, the easiest way to avoid this is probably to only allow one user at a time to withdraw money; this restrictions won't do much harm for an experimental system with at most 10-20 users. But of course, there may be other, better, solutions. Any advice? I know that several other systems have been published by you and others since 93, but so far I have stayed close to your original paper, because I want a rather minimalistic system: No observers, no magic or tamper-proof hardware, no trusted third parties, and no extra features like divisibility or transferability. Best regards, Niels Möller From nisse@lysator.liu.se Tue Jun 25 19:33:44 1996 Return-Path: nisse@lysator.liu.se Received: from lysistrate.lysator.liu.se (nisse@lysistrate.lysator.liu.se [130.236.254.161]) by lysander.lysator.liu.se (8.7.4/8.7.3) with ESMTP id TAA20584; Tue, 25 Jun 1996 19:33:43 +0200 (MET DST) Received: (from nisse@localhost) by lysistrate.lysator.liu.se (8.7.3/8.7.3) id TAA15648; Tue, 25 Jun 1996 19:33:40 +0200 (MET DST) Date: Tue, 25 Jun 1996 19:33:40 +0200 (MET DST) Message-Id: <199606251733.TAA15648@lysistrate.lysator.liu.se> From: "Niels Möller" To: ncash-list@lysator.liu.se Subject: [Stefan.Brands@cwi.nl] Re: Parallell attack? MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit ------- Start of forwarded message ------- From: Stefan.Brands@cwi.nl Subject: Re: Parallell attack? To: nisse@lysator.liu.se (Niels Mvller) Date: Tue, 11 Jun 1996 23:47:38 +0200 (MET DST) Hi Niels >As you probably know, my experiment with digital cash >(http://www.lysator.liu.se/~nisse/NCash) will be based on the system >you published in 93. Now someone made me aware of a "parallell attack" >on that and similar systems: two cooperating users executing the >withdrawal protocol simultaneously can withdraw coins that they can >doublespend without being identified. >Do you have any paper that describes what this is about? This attack only applies to the methods to improve on my Crypto 93 withdrawal protocol, which are based on what I call "secret-key certificates;" the Crypto 93 withdrawal protocol is fine as is. I actually discovered the attack myself, after I had worked on the withdrawal protocols based on secret-key certificates. They have the following advantages over the Crypto 93 protocol: faster, provable secure against a single user attack, more compact, and following a general construction principle. Take a look at the technical reports in http://www.cwi.nl/~brands/cash.html on secret-key certificates; They describe the improved method, give many proofs, describe the parallel attack, and provide two different measures to prevent them (I am curtrently combining the 5 reports into a single conference paper, by the way). >For me, the easiest way to avoid this is probably to only allow one >user at a time to withdraw money; this restrictions won't do much harm >for an experimental system with at most 10-20 users. So, no need to perform my Crypto 93 protocol sequentially, the parallel attack does not work here. By the way, you can find some more about the Crypto 93 scheme in my paper "Electronic Cash on the Internet" which is also in my home-page; the same scheme is used there for checks instead of coins, and the efficiency of the withdrawal protocol has been improved on a little. >But of course, there may be other, better, solutions. Any advice? >I know that several other systems have been published by you and >others since 93, but so far I have stayed close to your original >paper, because I want a rather minimalistic system: No observers, no >magic or tamper-proof hardware, no trusted third parties, and no extra >features like divisibility or transferability. >Best regards, > Niels Möller How is the project going at this stage? I'm interested in the outcome. In the mean time, you're welcome to ask any further questions that might come up. Good luck with your project, Stefan Brands, ------------------------------------------------------ CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands E-mail: brands@cwi.nl, URL: http://www.cwi.nl/~brands/ From nisse@lysator.liu.se Fri Sep 6 03:43:52 1996 Return-Path: nisse@lysator.liu.se Received: from tindra.lysator.liu.se (nisse@tindra.lysator.liu.se [130.236.254.62]) by lysander.lysator.liu.se (8.7.5/8.7.3) with ESMTP id DAA08434; Fri, 6 Sep 1996 03:43:51 +0200 (MET DST) Received: (from nisse@localhost) by tindra.lysator.liu.se (8.7.4/8.7.3) id DAA17965; Fri, 6 Sep 1996 03:43:22 +0200 (MET DST) Sender: nisse@lysator.liu.se To: ncash-list@lysator.liu.se Cc: 4028@lyskom.lysator.liu.se Subject: NCash --- statusrapport From: nisse@lysator.liu.se (Niels Möller) Date: 06 Sep 1996 03:43:19 +0200 Message-ID: Lines: 90 X-Mailer: Gnus v5.3/Emacs 19.32 Nu har jag kommit så långt att det finns lite att titta på i alla fall. Inofficiell ftpserver är bengt-arne.mai.liu.se/pub/NCash . www-sidorna är lite uppdaterade, och aktuell källkod finns uppackad i http://www.lysator.liu.se/~nisse/NCash/snapshot . Vad är det då som finns? * Generell socketkod, med och utan kryptering, Connection.py och SecureConnection.py . Vid uppkoppling så autenticerar sig servern med hjälp av RSA. * RSA.py implementerar RSA signaturer, inklusive paddning enligt PKCS. * gmpmodule.c, ett python interface till GNU:s bignumbibliotek gmp. Arkivet gmpmodule-0.95.tar.gz kan hämtas från bengt-arne eller ftp.python.org, och inkluderar en texinfo-manual. * BrandGroup.py implementerar den grupp (med ett primt antal element) som används genomgående i systemet. * NCash.py håller reda på alla parametrarna som beskriver systemet. * Randomness.py är förhoppningsvis vad namnet antyder. Använder enheten /dev/random, så om man inte har en sån så behöver kan man ändra koden att använda rc4 istället. * LockedFile.py, Account.py och UserData.py används för att bokföra kontona. Inte så klart än. * OpenAccount.py implementerar protokollet för att öppna nya konton. Just nu snurrar en server som klarar av att öppna nya konton. På bengt-arne.mai.liu.se, port 21952. * interface.py är ett lite primitivt användargränssnitt. Hittills är det enda man kan göra att öppna konton. Vad behöver man då för att testa? Man hämtar python-1.3.tar.gz, gmp-2.0.2.tar.gz och NCash-960906.tar.gz. Vill man ha ordentlig dokumentation till de pythonutvidgningar (skrivna i C) som används, så behöver man gmpmodule-0.95.tar.gz och pycrypt101.tgz också. Alltihop finns på bengt-arne. gmp ska gå att kompilera och installera med bara ./configure; make ; make install Python är lite krångligare. Innan man kompilerar, så behöver man kopiera gmpmodule.c, ideamodule.c, shamodule.c och arc4module.c till Python-1.3/Modules, och editera lite i Python-1.3/Modules/Setup . Manualen för gmpmodule ger lite ledning. Har man väl lyckats installera en pythoninterpretator med nödvändiga utvigningar, så ska man kunna ställa sig i biblioteket NCash och skriva bengt-arne[NCash]> python Python 1.3 (Jun 13 1996) [GCC 2.7.2] Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import interface >>> interface.new_account('bengt-arne.mai.liu.se') You should give each account you create a unique name. Name of this account: foobar You need a passphrase to protect your keys and money. Pass phrase: Type it again: Your name: (nimol) Niels Möller Account name: foobar Your name: Niels Möller Create account? [n] y Connecting to bengt-arne.mai.liu.se Welcome to open an account at NCash Created account. Saving... Done. Resultatet av detta är att det skapas en krypterad fil .ncash/foobar.$$$ i ens hembibliotek som innehåller de nycklar som man kommer att behöva för att använda kontot. Än så länga kan man naturligtvis inte ha dem till nånting ;-| Och hos servern så skapas samtidigt en fil som innehåller {'status': 1, 'balance': 0, 'type': '1', 'name': 'Niels Möller', 'id': '12465538581930581983378378254711055750121944935'} Så vad är kvar? En hel del... Det viktigaste är naturligtvis protokollen för uttag, betalning och insättning, med vidhängande servrar och klienter. Och så är det en hel del kvar att göra på administrationen av systemet. /niels From nisse@lysator.liu.se Fri Oct 4 14:10:57 1996 Return-Path: nisse@lysator.liu.se Received: from tintin.lysator.liu.se (nisse@tintin.lysator.liu.se [130.236.254.61]) by lysander.lysator.liu.se (8.7.5/8.7.3) with ESMTP id OAA17920; Fri, 4 Oct 1996 14:10:56 +0200 (MET DST) Received: (from nisse@localhost) by tintin.lysator.liu.se (8.7.4/8.7.3) id OAA07137; Fri, 4 Oct 1996 14:10:51 +0200 (MET DST) Sender: nisse@lysator.liu.se To: Stefan.Brands@cwi.nl, ncash-list@lysator.liu.se Subject: Suitable hashfunction for your cash system? From: nisse@lysator.liu.se (Niels Möller) Date: 04 Oct 1996 14:10:49 +0200 In-Reply-To: Stefan.Brands@cwi.nl's message of Tue, 27 Feb 1996 16:09:51 +0100 (MET) Message-ID: Lines: 28 X-Mailer: Gnus v5.3/Emacs 19.32 In your paper you mention that the hash function used in the cash system must satisfy some criterias in order to be suitable. Now I need to choose some particular hash function, and I'd like to hear any advice you may have. I need a hash function that hashes a tupel of group elements, as this is what the withdrawal protocol requires. For now, I have built a hash function on top of SHA. To do this, I first convert the group elements to strings of base 256 digits, then I catenate them. I also prepend a list of the of the strings' lengths, as I don't want to be surprised by easily found collisions in the catenation step. The result is fed to SHA, and the hash value is interpreted as a 160-bit number. def hash(self, list): strings = map(lambda x: bignum.group2string(x, 256), list) h = sha.new() for s in strings: h.update('%d:' % (len(s),) ) h.update(':') for s in strings: h.update(s) return bignum.string2number(h.digest(), 256) Do you think this is good enough? As far as I can see, it should be as secure as SHA, whatever that means. Regards, /Niels Möller From nisse@lysator.liu.se Wed Oct 23 06:29:47 1996 Return-Path: Received: from tindra.lysator.liu.se (nisse@tindra.lysator.liu.se [130.236.254.62]) by lysander.lysator.liu.se (8.8.2/8.8.2) with ESMTP id GAA20690 for ; Wed, 23 Oct 1996 06:29:46 +0200 (MET DST) Received: (from nisse@localhost) by tindra.lysator.liu.se (8.8.2/8.8.2) id GAA29073; Wed, 23 Oct 1996 06:29:41 +0200 (MET DST) Sender: nisse@lysator.liu.se To: ncash-list@lysator.liu.se Subject: Kontovillkor och -ansvar From: nisse@lysator.liu.se (Niels Möller) Date: 23 Oct 1996 06:29:40 +0200 Message-ID: Lines: 66 X-Mailer: Gnus v5.3/Emacs 19.32 Jag har funderat lite till på hur man ska göra med kontovillkor, kvittering av uttag, och sånt. Det är viktigt att villkoren är rimliga och inte förutsätter onödigt mycket tillit mellan bank och användare. Vad gäller öppnande av konton, så tänker jag mig att det går till så här: 1. Först genererar användaren en egen rsa-nyckel. Sen hämtar hon hem programvaran och kör programmet "skapa konto" mot bankens server. 2. När kontot skapas, så får användaren ett kontonummer, ett kontoid, och en hemlig representation av sin identitet. Hon skickar också över sin öppna rsanyckel till banken. 3. Därefter så måste användaren uppsöka banken i RL. Hon identifierar sig på traditionellt vis, och skriver under ett papper som innehåller hennes öppna rsa-nyckel, kontonummer och kontoid, en hash av programvaran (eller åtminstone av de delar av den som beskriver parametrar och protokoll), så att man vet att man är överrens om vilket system och vilka parametrar som gäller. När detta är gjort så öppnar banken kontot. Uttag sker i enheter av 2^n pengar, där n är mellan 0 och 7, exempelvis. De intressanta sakerna händer i följande ordning: 1. Använderen kopplar upp sig, autenticeras, och beordrar ett uttag. Banken signerar en peng, drar ifrån pengarna från kontot, markerar kontot som temporärt stängt, och skickar över pengen och en saldouppgift (tidpunkt och saldo efter uttaget). 2. Användaren kontrollerar att saldot stämmer, signerar den med sin rsa-nyckel, och skickar tillbaka signaturen till banken. 3. Banken kontrollerar att signaturen stämmer, och tar bort stängdhetsmarkeringen från kontot. Jag tror att den här proceduren ger en rimlig riskfördelning. Om banken tar bort pengar från kontot, så kan användaren klaga, och kan inte banken plocka fram en signatur för varje uttag, passande den nyckel som är angiven på kontraktet som skrevs under när kontot öppnades, så kommer användaren att få rätt. (Användaren måste förstås se till att ha en signatur motsvarande den senaste insättningen, men insättningar har jag inte tänkt så mycket på än). Användaren kan försöka lura banken genom att lägga på efter steg 1 ovan, men då kommer kontot automatiskt att stängas tills man har rett ut vad som hände, och banken kan förlora högst 2^7 pengar. Vill banken verkligen gardera sig, så kan den kräva att man alltid måste ha minst detta belopp innestående, som någon slags pant. Bankens risk är kanske lite större, jämfört med om användaren går till en vanlig bank och först lämnar in en underskriven uttagsorder, och därefter får pengarna i handen. Men användaren kan behöva en starkare ställning gentemot den digitala banken, eftersom det praktiskt taget aldrig finns några vittnen. I Storbrittannien (och kanske även i Sverige?) har det varit flera fall där bankkunder har fått sina bankkort debiterade utan att de använt dem. Och det är *svårt* att ta reda på vem som har rätt. Det system jag beskriver borde ha mindre förutsättningar till missbruk, och om banken slarvar så blir det i första hand banken som får ta förlusten, vilket är bra. /niels From nisse@lysator.liu.se Tue Dec 24 00:45:32 1996 Return-Path: Received: from tinner.lysator.liu.se (nisse@tinner.lysator.liu.se [130.236.254.46]) by lysander.lysator.liu.se (8.8.4/8.8.4) with ESMTP id AAA14539 for ; Tue, 24 Dec 1996 00:45:31 +0100 (MET) Received: (from nisse@localhost) by tinner.lysator.liu.se (8.8.4/8.8.4) id AAA00720; Tue, 24 Dec 1996 00:42:14 +0100 (MET) Sender: nisse@lysator.liu.se To: ncash-list@lysator.liu.se Subject: God jul From: nisse@lysator.liu.se (Niels Möller) Date: 24 Dec 1996 00:42:13 +0100 Message-ID: Lines: 15 X-Mailer: Gnus v5.3/Emacs 19.32 Jag tänkte berätta att jag sen några veckor tillbaka har blivit med jobb, hos Informationsvävarna i Linköping (http://www.infovav.se). Dessutom fortsätter jag att undervisa åt MAI på halvtid. Som ni kanske förstår, så leder detta till att mitt xjobb kommer att dra ut ännu längre på tiden än planerat. Som det ser ut nu, så kommer jag i början av våren att jobba bland annat med SSL-stöd för vår www-server Roxen, samt ett generellt kryptopaket till programmeringsspråket pike. När det är klart, så ska jag försöka få tid över att göra klart NCash-projektet. Min opponent, Robin von Post, blir lite ledsen om jag inte är klar till sommaren, så det är den tidsplan jag jobbar med. God jul, och gott nytt år /nisse From nisse@lysator.liu.se Sun May 18 05:20:01 1997 Return-Path: Received: from tindra.lysator.liu.se (nisse@tindra.lysator.liu.se [130.236.254.62]) by lysander.lysator.liu.se (8.8.5/8.8.5) with ESMTP id FAA03743 for ; Sun, 18 May 1997 05:20:01 +0200 (MET DST) Received: (from nisse@localhost) by tindra.lysator.liu.se (8.8.4/8.8.4) id FAA27294; Sun, 18 May 1997 05:19:57 +0200 (MET DST) To: ncash-list@lysator.liu.se Subject: Lägesrapport From: nisse@lysator.liu.se (Niels Möller) Date: 18 May 1997 05:19:56 +0200 Message-ID: Lines: 72 X-Mailer: Gnus v5.4.45/Emacs 19.34 Som ni märkt, så har mitt xjobb legat ganska mycket nere sedan november. Jag har ju jobbat ungefär halvtid hos Informationsvävarna, och dessutom undervisat en del, så det har inte blivit mycket tid över. Jobbet hos informationsvävarna har dock inte varit helt orelaterat till xjobbet. Vad jag har gjort där, är att jag har skrivit ett ganska generellt toolkit för kryptering, och sedan använt detta för att implementera serveränden av SSL-protokollet, alltså netscapes Secure Socket Layer. Den här SSL-implementationen kommer inom ett par veckor att användas både i Infovavs www-server Roxen Challenger, och i Signums brandvägg Fuego. Nu är SSL-projektet praktiskt taget klart, så sedan ett par veckor tillbaka har jag trappat ner på det arbetet, och i stället fortsatt att hacka på NCash. Jag har råkat byta implementationsspråk från Python till Pike (http://pike.infovav.se). Det den kryptokod jag har skrivit är i första hand tänkt att användas tillsammans med Pike, men i övrigt är det inga särskilt signifikanta skillnader. Jag är har precis fått igång protokollet för att ta ut pengar, och det verkar fungera: bengt-arne[src]> pike withdraw_coins.pike foo localhost Passphrase: Connecting to localhost... Connected: NCash withdrawal service Logging in... done. Current balance: 676 Currency [gürtner]: Available denominations: 2^x, 0 <= x <= 7 x [1 = 2^0] : 5 Number of coins to withdraw [1]: 3 About to withdraw 3 coins representing 32 gürtner each. Sum: 96 gürtner Continue [n]? y Current balance: 644 Current balance: 612 Current balance: 580 Finished [y] ? bengt-arne[src]> Kvar att göra är protokollen för betalningstransaktionerna, samt för insättning av emottagna pengar. Rapporten har jag inte skrivit nåt på sen jag skrev en inledning för ett antal månader sen. Fast ni som inte läste den då kan gärna kolla på aktuell version, http://www,lysator.liu.se/~nisse/NCash/NCash.{dvi|ps}. Dessutom upptäckte jag häromdan att NCash är omnämnt i GNU-bulletinen från i januari ;), men det är kanske att betrakta som ett misstag. Det är fortfarande inte *helt* omöjligt att det blir klart innan sommaren, förutsatt att man får ha framläggningen någon gång i slutet av tenta-p. Viiveke: Vad är det för regler och datum som gäller? Om det inte går så får det bli så snart som möjligt efter sommaruppehållet. Robin: Blir du hemskt ledsen om du får vänta till augusti-september? Ointressanta siffror: Kod: 3000 rader. Rapport: 450 rader. /Niels From nisse@lysator.liu.se Sun May 25 03:51:34 1997 Return-Path: Received: from tindra.lysator.liu.se (nisse@tindra.lysator.liu.se [130.236.254.62]) by lysander.lysator.liu.se (8.8.5/8.8.5) with ESMTP id DAA16069 for ; Sun, 25 May 1997 03:51:33 +0200 (MET DST) Received: (from nisse@localhost) by tindra.lysator.liu.se (8.8.4/8.8.4) id DAA02832; Sun, 25 May 1997 03:51:28 +0200 (MET DST) To: ncash-list@lysator.liu.se Subject: Mer dokumentation. MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels Möller) Date: 25 May 1997 03:51:26 +0200 Message-ID: Lines: 9 X-Mailer: Gnus v5.4.45/Emacs 19.34 Nu har jag uppdaterat www-sidorna en aning. Nu i ekonomrosa ;). Tyvärr finns ingen kod tillgänglig för närvarande (den attans Roxenservern envisas med att vilja exekvera mina .pike-filer, vilket inte är riktigt vad jag vill...). Och så har jag skrivit mer på rapporten. Alla protokoll finns beskrivna nu, och så finns det ett nytt avsnitt om dubbelspendering. /nisse From jjh@arch.etri.re.kr Sat Jun 7 01:04:07 1997 Return-Path: Received: from lysator.liu.se (root@lysator.liu.se [130.236.254.1]) by lysander.lysator.liu.se (8.8.5/8.8.5) with ESMTP id BAA21486 for ; Sat, 7 Jun 1997 01:04:06 +0200 (MET DST) Received: from arch. (arch.etri.re.kr [129.254.114.3]) by lysator.liu.se (8.8.4/8.8.4) with SMTP id BAA11765 for ; Sat, 7 Jun 1997 01:04:01 +0200 (MET DST) Received: from jpc.etri.re.kr (jangjh) by arch. (4.1/SMI-4.1) id AA29252; Sat, 7 Jun 97 08:04:02 KST Message-Id: <339897CA.2BC4@arch.etri.re.kr> Date: Sat, 07 Jun 1997 08:05:46 +0900 From: Jang Jong Hyun Reply-To: jjh@arch.etri.re.kr Organization: ETRI X-Mailer: Mozilla 3.01Gold [ko] (Win95; I) Mime-Version: 1.0 To: ncash-list@lysator.liu.se Subject: Can't find Source Code Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 7bit I am attract Your NCAsh digital cash system. I am novice for digital cash system. i can't find your source code. Thank you. mail address : jjh@arch.etri.re.kr From nisse@lysator.liu.se Mon Aug 11 23:26:34 1997 Return-Path: Received: from tintin.lysator.liu.se (nisse@tintin.lysator.liu.se [130.236.254.61]) by lysander.lysator.liu.se (8.8.5/8.8.5) with ESMTP id XAA29449 for ; Mon, 11 Aug 1997 23:26:30 +0200 (MET DST) Received: (from nisse@localhost) by tintin.lysator.liu.se (8.8.4/8.8.4) id XAA03779; Mon, 11 Aug 1997 23:26:23 +0200 (MET DST) To: ncash-list@lysator.liu.se Subject: Ny snapshot MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels Möller) Date: 11 Aug 1997 23:26:20 +0200 Message-ID: Lines: 36 X-Mailer: Gnus v5.4.59/Emacs 19.34 Under sommaren har jag till och från skrivit på rapporten, det mesta finns med i den nu (28 sidor). Finns som vanligt på http://www.lysator.liu.se/~nisse/NCash/NCash.ps . Jag är naturligtvis tacksam för kommentarer på innehållet. De senaste dagarna har jag fortsatt med hackandet också. För närvarande klarar ncashd och motsvarande klienter av att × öppna konton × ta ut pengar × hämta bankens lista över kända öppna nycklar Servern för att ta emot betalningar, charged, är skriven, om än inte debuggad. Klientprogrammet för att koppla upp sig mot en charged och betala är det jag jobbar på nu. Dessutom har jag kod för att hålla reda på listan över kända öppna nycklar hos användaren, och ett skript som banken kan använda för att manipulera med konton (som att titta på och ändra status och saldo, eller extrahera motsvarande öppna nyckel). Vad som är kvar är protokoll och program för att hantera insättning av betalade pengar (vilket är det enklaste av de inblandade protokollen), och som sagt resten av betalningsklienten. Drygt 4000 rader kod är skriven hittills, vilket väl inte är så extremt mycket. En snapshot finns på http://www.lysator.liu.se/~nisse/NCash/snapshot.tar.gz . Pike-0.5 som är den interpretator jag använder är inte officiellt släppt än, men väntas bli allmänt tillgänglig inom en vecka eller två. Under slutet av veckan och under nästa helg kommer jag att vara i Stockholm och Uppsala, så då kommer det inte att hända så mycket. /nisse From md2manda@mdstud.chalmers.se Tue Aug 12 10:21:16 1997 Return-Path: Received: from piggy.mdstud.chalmers.se (root@piggy.mdstud.chalmers.se [129.16.234.10]) by lysander.lysator.liu.se (8.8.5/8.8.5) with ESMTP id KAA19313; Tue, 12 Aug 1997 10:21:16 +0200 (MET DST) Received: from rizzo5.mdstud.chalmers.se (md2manda@rizzo5.mdstud.chalmers.se [129.16.235.146]) by piggy.mdstud.chalmers.se (8.8.5/8.7.3) with ESMTP id KAA23576; Tue, 12 Aug 1997 10:21:10 +0200 (MET DST) Received: from localhost (md2manda@localhost) by rizzo5.mdstud.chalmers.se (8.8.5/8.8.5) with ESMTP id KAA03756; Tue, 12 Aug 1997 10:21:07 +0200 (MET DST) X-Authentication-Warning: rizzo5.mdstud.chalmers.se: md2manda owned process doing -bs Date: Tue, 12 Aug 1997 10:21:07 +0200 (MET DST) From: Mandana Jahanian To: =?ISO-8859-1?Q?Niels_M=F6ller?= cc: ncash-list@lysator.liu.se Subject: Re: Ny snapshot In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hej Nisse, Jag undrar hur du hanterar skapandet av generator talen(g1, g2) i ditt program som skall vara känd för alla. Och dessutom generar du dem engång för alltid eller tänker du bytta dem efter ett tag? mvh Mandana On 11 Aug 1997, Niels Möller wrote: > Under sommaren har jag till och från skrivit på rapporten, det mesta > finns med i den nu (28 sidor). Finns som vanligt på > http://www.lysator.liu.se/~nisse/NCash/NCash.ps . Jag är naturligtvis > tacksam för kommentarer på innehållet. > > De senaste dagarna har jag fortsatt med hackandet också. För > närvarande klarar ncashd och motsvarande klienter av att > > × öppna konton > × ta ut pengar > × hämta bankens lista över kända öppna nycklar > > Servern för att ta emot betalningar, charged, är skriven, om än inte > debuggad. Klientprogrammet för att koppla upp sig mot en charged och > betala är det jag jobbar på nu. > > Dessutom har jag kod för att hålla reda på listan över kända öppna > nycklar hos användaren, och ett skript som banken kan använda för att > manipulera med konton (som att titta på och ändra status och saldo, > eller extrahera motsvarande öppna nyckel). > > Vad som är kvar är protokoll och program för att hantera insättning av > betalade pengar (vilket är det enklaste av de inblandade protokollen), > och som sagt resten av betalningsklienten. > > Drygt 4000 rader kod är skriven hittills, vilket väl inte är så > extremt mycket. En snapshot finns på > http://www.lysator.liu.se/~nisse/NCash/snapshot.tar.gz . > > Pike-0.5 som är den interpretator jag använder är inte officiellt > släppt än, men väntas bli allmänt tillgänglig inom en vecka eller två. > > Under slutet av veckan och under nästa helg kommer jag att vara i > Stockholm och Uppsala, så då kommer det inte att hända så mycket. > > /nisse > From nisse@lysator.liu.se Tue Aug 12 14:46:39 1997 Return-Path: Received: from tintin.lysator.liu.se (root@tintin.lysator.liu.se [130.236.254.61]) by lysander.lysator.liu.se (8.8.5/8.8.5) with ESMTP id OAA24198; Tue, 12 Aug 1997 14:46:38 +0200 (MET DST) Received: (from nisse@localhost) by tintin.lysator.liu.se (8.8.4/8.8.4) id LAA05895; Tue, 12 Aug 1997 11:47:26 +0200 (MET DST) To: Mandana Jahanian Cc: ncash-list@lysator.liu.se Subject: Re: Ny snapshot References: MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels Möller) Date: 12 Aug 1997 11:47:25 +0200 In-Reply-To: Mandana Jahanian's message of "Tue, 12 Aug 1997 10:21:07 +0200 (MET DST)" Message-ID: Lines: 29 X-Mailer: Gnus v5.4.59/Emacs 19.34 Mandana Jahanian writes: > Jag undrar hur du hanterar skapandet av generator talen(g1, g2) i ditt > program som skall vara känd för alla. Och dessutom generar du dem engång > för alltid eller tänker du bytta dem efter ett tag? De ska väljas slumpmässigt, liksom de övriga generatorer som används här och var i systemet. Det ska inte finnas några kända relationer av typen g_1 = k g_2. Jag har inte funderat så mycket på vad man ska använda för procedur för att välja parametrar, de jag använder nu när jag testar har jag valt mer eller mindre manuellt, genom att slumpa fram tal k_i och sen sätta g_i = k_i g, där g är den "urgenerator" som jag associerar med gruppen. Och eftersom det gjordes för över ett år sen, så har jag glömt bort k_i:na... Det är inte meningen att man ska behöva byta alla publika generatorer oftare än man byter till en större grupp. Däremot vill man antagligen ge uttagna mynt en begränsad giltighetstid, vilket man kan göra genom att byta ut de generatorer som associeras med olika valutor. Man byter helt enkelt ut någon av de generatorer som används för att ge ut mynt, och sedan accepterar man inlösen av mynt med de gamla generatorerna under en begränsad tid. /Niels From md2manda@mdstud.chalmers.se Tue Aug 12 15:07:26 1997 Return-Path: Received: from piggy.mdstud.chalmers.se (root@piggy.mdstud.chalmers.se [129.16.234.10]) by lysander.lysator.liu.se (8.8.5/8.8.5) with ESMTP id PAA25083; Tue, 12 Aug 1997 15:07:25 +0200 (MET DST) Received: from rizzo4.mdstud.chalmers.se (md2manda@rizzo4.mdstud.chalmers.se [129.16.235.145]) by piggy.mdstud.chalmers.se (8.8.5/8.7.3) with ESMTP id PAA27442; Tue, 12 Aug 1997 15:07:21 +0200 (MET DST) Received: from localhost (md2manda@localhost) by rizzo4.mdstud.chalmers.se (8.8.5/8.8.5) with ESMTP id PAA14054; Tue, 12 Aug 1997 15:07:18 +0200 (MET DST) X-Authentication-Warning: rizzo4.mdstud.chalmers.se: md2manda owned process doing -bs Date: Tue, 12 Aug 1997 15:07:17 +0200 (MET DST) From: Mandana Jahanian To: =?ISO-8859-1?Q?Niels_M=F6ller?= cc: ncash-list@lysator.liu.se Subject: Re: Ny snapshot In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On 12 Aug 1997, Niels Möller wrote: > De ska väljas slumpmässigt, liksom de övriga generatorer som används > här och var i systemet. Det ska inte finnas några kända relationer av > typen g_1 = k g_2. Det är jag helt övertyggad om, men däremot är det svårare att välja en typ av random generator, för att den måste först uppfylla säkerhets kraven men också vara billig att implementera för att vem vill betala för en dyrt system som kommer till nytta nara några gånger? Då problemet är hur ska man hitta en sån random generator. > > Jag har inte funderat så mycket på vad man ska använda för procedur > för att välja parametrar, de jag använder nu när jag testar har jag > valt mer eller mindre manuellt, genom att slumpa fram tal k_i och sen > sätta g_i = k_i g, där g är den "urgenerator" som jag associerar med > gruppen. Och eftersom det gjordes för över ett år sen, så har jag > glömt bort k_i:na... Väl, det är en tillfällig lösning, vilket jag själv har också funderat att använda än så länge. > > Det är inte meningen att man ska behöva byta alla publika generatorer > oftare än man byter till en större grupp. > Men jag funderar om det är rimlig? Finns det något bevis på att systemet skall vara säkert, efter 3 år? Har vi inte något liknande problem som när och hur bör vi bytta CA noden? > Däremot vill man antagligen ge uttagna mynt en begränsad > giltighetstid, vilket man kan göra genom att byta ut de generatorer > som associeras med olika valutor. Man byter helt enkelt ut någon av de > generatorer som används för att ge ut mynt, och sedan accepterar man > inlösen av mynt med de gamla generatorerna under en begränsad tid. > Men då måste man markera dem olika mynt gruppen, vilket kanske kan riskera användarens anonymity. Och vem skall stå för kostnader av att generera nya generatorer och be alla kunderna öppna om sina konton? Vad tycker du? > /Niels > mvh Mandana From nisse@lysator.liu.se Tue Aug 12 20:46:37 1997 Return-Path: Received: from tintin.lysator.liu.se (root@tintin.lysator.liu.se [130.236.254.61]) by lysander.lysator.liu.se (8.8.5/8.8.5) with ESMTP id UAA03901; Tue, 12 Aug 1997 20:46:29 +0200 (MET DST) Received: (from nisse@localhost) by tintin.lysator.liu.se (8.8.4/8.8.4) id UAA10115; Tue, 12 Aug 1997 20:40:25 +0200 (MET DST) To: Mandana Jahanian Cc: ncash-list@lysator.liu.se Subject: Re: Ny snapshot References: MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels Möller) Date: 12 Aug 1997 20:40:19 +0200 In-Reply-To: Mandana Jahanian's message of "Tue, 12 Aug 1997 15:07:17 +0200 (MET DST)" Message-ID: Lines: 36 X-Mailer: Gnus v5.4.59/Emacs 19.34 Mandana Jahanian writes: > > Det är inte meningen att man ska behöva byta alla publika generatorer > > oftare än man byter till en större grupp. > > Men jag funderar om det är rimlig? Finns det något bevis på att systemet > skall vara säkert, efter 3 år? Har vi inte något liknande problem som när > och hur bör vi bytta CA noden? Systemet är, enligt Brands, säkert förutsatt att ingen kan beräkna diskreta logaritmer (till exempel är ju bankens hemliga nyckel den diskreta logaritmen av ett gruppelement med avseende på ett annat). Det borde inte vara något problem att välja en tillräckligt stor grupp för att göra det praktiskt omöjligt att beräkna diskreta logaritmer även om man har ett par superdatorer och ett par år på sig. > > Däremot vill man antagligen ge uttagna mynt en begränsad > > giltighetstid, vilket man kan göra genom att byta ut de generatorer > > som associeras med olika valutor. Man byter helt enkelt ut någon av de > > generatorer som används för att ge ut mynt, och sedan accepterar man > > inlösen av mynt med de gamla generatorerna under en begränsad tid. > > > Men då måste man markera dem olika mynt gruppen, vilket kanske kan > riskera användarens anonymity. Och vem skall stå för kostnader av att > generera nya generatorer och be alla kunderna öppna om sina konton? Det är meningen att systemet ska kunna hantera flera valutor parallellt. Och tekniskt sett är det inte så annorlunda att skilja på mynt av valutorna "SEK" och "USD" jämfört med att ha mynt av valutorna "SEK, bäst före 1998-03", "SEK, bäst före 1998-11", ... Vad gäller anonymitet, så borde det inte vara något problem om man bara ser till att ha ett fåtal klasser och ger ut *många* mynt av varje klass. /Niels From nisse@lysator.liu.se Sat Aug 23 09:31:05 1997 Return-Path: Received: from tindra.lysator.liu.se (nisse@tindra.lysator.liu.se [130.236.254.62]) by lysander.lysator.liu.se (8.8.5/8.8.5) with ESMTP id JAA20384 for ; Sat, 23 Aug 1997 09:31:04 +0200 (MET DST) Received: (from nisse@localhost) by tindra.lysator.liu.se (8.8.4/8.8.4) id JAA20898; Sat, 23 Aug 1997 09:31:01 +0200 (MET DST) To: ncash-list@lysator.liu.se Subject: Betalningsklient MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels Möller) Date: 23 Aug 1997 09:30:59 +0200 Message-ID: Lines: 23 X-Mailer: Gnus v5.4.59/Emacs 19.34 Nu har jag hackat lite till... bengt-arne[src]> ./pay_coins.pike bar 3 nisse "Ett meddelande till betalningsmottagaren" localhost Passphrase: Sorted purse: ([ /* 2 elements */ 2:1, 1:6 ]) to_pay: ([ /* 2 elements */ 1:1, 2:1 ]) Connected: NCash payment server, accepting payments for: nisse Paying a coin denominated 1. Paying a coin denominated 2. New purse: ([ /* 1 elements */ 1:5 ]) Payed 3, successfully. bengt-arne[src]> /nisse From nisse@lysator.liu.se Tue Sep 16 05:53:51 1997 Return-Path: Received: from kairo.lysator.liu.se (nisse@kairo.lysator.liu.se [130.236.254.53]) by samantha.lysator.liu.se (8.8.7/8.8.7) with ESMTP id FAA21584 for ; Tue, 16 Sep 1997 05:53:51 +0200 (MET DST) Received: (from nisse@localhost) by kairo.lysator.liu.se (8.8.7/8.8.5) id FAA04345; Tue, 16 Sep 1997 05:51:46 +0200 (MET DST) To: ncash-list@lysator.liu.se Subject: Nu verkar det fungera... MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels Möller) Date: 16 Sep 1997 05:51:41 +0200 Message-ID: Lines: 155 X-Mailer: Gnus v5.4.59/Emacs 19.34 Nu har jag skrivit klart den del som var kvar: insättningsprotokollet. Totalt har NCash blivit ungefär 6500 rader kod, vilket nog är lite mer än jag hade räknat med. Det finns en hel del förbättringar på min TODO-lista, men de får nog vänta tills efter framläggning och sånt. Källkoden finns som vanligt på http://www.lysator.liu.se/~nisse/NCash/snapshot.tar.gz . /Nisse Nedan utdatat från mitt testscript... bengt-arne[src]> ./test.sh Created tmp/ncash-test-8945/.ncash Created tmp/ncash-test-8945/bank Killing old servers Starting ncashd... Starting ncashd service... Creating an account... tag = 'userfoo' interactive = 0 Account name: userfoo Your name: user An RSA key pair is needed for signing receipts and other messages from the bank. Generating 1024 bit key... done. Connecting to localhost... Connected: NCash account service new_account. Trying to lock file 'tmp/ncash-test-8945/bank/users/next_account' Account 1 created Saving account information in tmp/ncash-test-8945/.ncash/userfoo.$$$ Finished. In order to use your new account, you have to accept and sign an account contract with your bank. And don't forget your passphrase. Another one tag = 'shopfoo' interactive = 0 Account name: shopfoo Your name: shop An RSA key pair is needed for signing receipts and other messages from the bank. Generating 1024 bit key... done. Connecting to localhost... Connected: NCash account service new_account. Trying to lock file 'tmp/ncash-test-8945/bank/users/next_account' Account 2 created Saving account information in tmp/ncash-test-8945/.ncash/shopfoo.$$$ Finished. In order to use your new account, you have to accept and sign an account contract with your bank. And don't forget your passphrase. Enabling user's account Account number 1: owner: user, type: test status: 5 balance: 47 Authorizing shop's public key Account number 2: owner: shop, type: test status: 2 balance: 0 Fetching public keys... Connected: Public key service Finished! Starting charged... Withdrawing... Account number 2: owner: shop, type: test balance: 0 Starting charged service... Connecting to localhost... Connected: NCash withdrawal service Logging in... done. You and the bank disagree on the current balance of your account. 47 according to the bank, but 0 according to your notes Current balance: 47 About to withdraw 5 coins representing 2 gürtner each. Sum: 10 gürtner Current balance: 45 Current balance: 43 Current balance: 41 Current balance: 39 Current balance: 37 About to withdraw 2 coins representing 8 gürtner each. Sum: 16 gürtner Current balance: 29 Current balance: 21 Paying... Sorted purse: ([ /* 2 elements */ 8:2, 2:5 ]) to_pay: ([ /* 2 elements */ 2:1, 8:1 ]) Connecting to localhost:25002 Connected: NCash payment server, accepting payments for: shop Paying a coin denominated 2. Paying a coin denominated 8. New purse: ([ /* 2 elements */ 8:1, 2:4 ]) Payed 10, successfully. Depositing... Connecting to localhost... Connected: NCash deposit service Status of user's account Account number 1: owner: user, type: test status: 5 balance: 21 Status of shop's account Account number 2: owner: shop, type: test status: 2 balance: 10 Killing servers ncashd slayed. charged slayed. bengt-arne[src]> From nisse@lysator.liu.se Wed Oct 22 00:24:38 1997 Return-Path: Received: from svenolov.lysator.liu.se (davidk@svenolov.lysator.liu.se [130.236.254.48]) by samantha.lysator.liu.se (8.8.7/8.8.7) with ESMTP id AAA20590 for ; Wed, 22 Oct 1997 00:24:36 +0200 (MET DST) Received: (from nisse@localhost) by svenolov.lysator.liu.se (8.8.7/8.8.5) id UAA01536; Tue, 21 Oct 1997 20:12:32 +0200 (MET DST) To: ncash-list@lysator.liu.se Subject: Läget, oktober 1997 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels Möller) Date: 21 Oct 1997 20:12:31 +0200 Message-ID: Lines: 21 X-Mailer: Gnus v5.4.59/Emacs 19.34 En kort lägesrapport: Koden verkar fungera sedan ett par veckor tillbaka. Jag vill gärna ha ett par testpersoner. Instruktioner finns på http://www.lysator.liu.se/~nisse/NCash/trial.html . Jag kan antagligen smuggla ut en prerelease av pike-0.5 om det är nån som behöver. Sen råkade jag snubbla över en (. skoj .) lag häromdan. NCash ska inte beröras, men ganska mycket annan kryptoverksamhet. Om det är nån som fortfarande lever i illusionen att Sverige är en del av den fria världen, utan export- eller andra restriktioner vad gäller kryptering, så ta och titta på Lagen om strategiska produkter, SFS 1994:2060. Den är inget skoj. Alls. En kopia finns på http://www.lysator.liu.se/~nisse/doc/ondska/1994:2060.html. Min opponent (hej Robin!) verkar lite upptagen, men det ska väl bli en framläggning inom överskådlig framtid. Jag ska försöka annonsera det i rätt god tid, om det är nån som är intresserad av att komma förbi. /Niels From nisse@lysator.liu.se Tue Dec 16 15:20:30 1997 Return-Path: Received: from sandra.lysator.liu.se (nisse@sandra.lysator.liu.se [130.236.254.203]) by samantha.lysator.liu.se (8.8.7/8.8.7) with ESMTP id PAA07598 for ; Tue, 16 Dec 1997 15:20:29 +0100 (MET) Received: (from nisse@localhost) by sandra.lysator.liu.se (8.8.8/8.8.7) id PAA20028; Tue, 16 Dec 1997 15:20:27 +0100 (MET) To: ncash-list@lysator.liu.se Subject: Ny snapshot MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels Möller) Date: 16 Dec 1997 15:20:26 +0100 Message-ID: Lines: 17 X-Mailer: Gnus v5.4.59/Emacs 19.34 Nu finns en ny snapshot på http://www.lysator.liu.se/~nisse/NCash/ncash-19971216.tar.gz, och även ny version av rapporten på ungefär samma ställe. Dessutom har äntligen pike släppts, finns på ftp://pike.idonex.se/pub/pike/Pike-v0.5b1.tar.gz. Den versionen är tyvärr utan kryptostöd, eftersom myndigheterna fortfarande tuggar på frågan om man får exportera den. Däremot råkar det finnas en kopia av den behövliga kryptokoden på http://www.lysator.liu.se/~nisse/archive/.obscurity/pikecrypto.tar.gz, men det är tämligen inofficiellt. /nisse From nisse@lysator.liu.se Fri Jan 30 04:29:00 1998 Return-Path: Received: from sandra.lysator.liu.se (nisse@sandra.lysator.liu.se [130.236.254.203]) by samantha.lysator.liu.se (8.8.7/8.8.7) with ESMTP id EAA19113; Fri, 30 Jan 1998 04:28:58 +0100 (MET) Received: (from nisse@localhost) by sandra.lysator.liu.se (8.8.8/8.8.7) id EAA28597; Fri, 30 Jan 1998 04:28:56 +0100 (MET) To: ncash-list@lysator.liu.se Subject: NCash presentation next Friday MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels Möller) Date: 30 Jan 1998 04:28:55 +0100 Message-ID: Lines: 57 [ This announcement is sent to the ncash-list, and bcc:ed to the coderpunks list and to several persons who are not subscribed to either list. Thus, this message does not imply that you are subscribed to the ncash mailing list. ] Hello all. At last, the report on NCash is finished. It will be presented next Friday, February 6, at 13:15. The place is ISY's seminarierum, house B, at the Linköping institute of Technology. You are most welcome. In case any of you outside Linköping want to show up, contact me if you need directions or any other information. The report can be down-loaded at http://www.lysator.liu.se/~nisse/NCash/NCash.ps . The current status of the NCash software is that it is almost usable. There are a few known bugs that I will look at after the presentation and other procedures are over, and certainly some yet unknown problems as well. The latest snapshot can be found at http://www.lysator.liu.se/~nisse/NCash/snapshot.tar.gz To actually try it out, you also need a few other packages: The pike interpreter, found at ftp://ftp.idonex.se/pub/pike/Pike-v0.5b1.tar.gz, the GNU gmp bignum library, at ftp://ftp.lysator.liu.se/pub/gnu/gmp-2.0.2.tar.gz, and the pike cryptography toolkit, at http://www.lysator.liu.se/~nisse/archive/.obscurity/pikecrypto.tar.gz. If you need help installing any of this, please let me know. Best regards, /Niels Möller LEGALESE: Note that it is unclear whether or not exporting the NCash software and the pike cryptography toolkit is an illegal violation of the Wassenaar arrangements, concerned with export of "dual use" and mass destruction technology. I believe that exporting this software is indeed legal (and even if it's not, I don't care too much about that). The license and copying conditions for all these packages is the GNU General Public License, except for the GMP library which is distributed under the LGPL. Various patents might restrict use of the software; as NCash is primarily an academic project I haven't put much effort into investigating the patent status of the methods and algorithms that I use.