Miten olette WebSocket serverillä toteuttaneet asiakkaan autentikoinnin? Oma serverini on 8th:lla toteutettu ja asiakkaat olisivat 8th:lla toteutettuja ohjelmia.
Käykö tuohon "HTTP basic authentication" siinä vaiheessa kun asiakas ottaa HTTP-yhteyden ennen päivitystä WebSocket yhteydeksi?
Vai olisiko parempi toteuttaa "kättely" asiakkaan ja serverin välillä siten, että kaikilla asiakkailla olisi ed25519 julkinen/yksityinen avainpari ja asiakkaiden julkiset avaimet olisi tallennettu serverille asiakkaan todentamista varten?
WebSocket ei muuta autentikoinnin vaatimuksia verrattuna muihin HTTP-pyyntöihin. Siihen nähden nuo esittämäsi vaihtoehdot ovat aika erikoiset.
HTTP basic authentication on selainpuolella pitkälti historiaa teknisten rajoitusten takia: lomaketta ei voi tehdä itse, uloskirjautumista ei ole ollenkaan, ja tunnus ja salasana säilyvät selaimen välimuistissa ainakin istunnon ajan. Pitäisi testata, lähteekö kyseinen otsikko edes WS-pyynnön mukana (ja siinähän sen pitäisi olla, jotta sitä voisi käyttää). Tietysti jos teet itse koko HTTP-toteutuksen, pystyt kiertämään nämä puutteet. Toisaalta silloin voi miettiä, mikä hyöty on standardoidun WS:n käytöstä, jos mukaan tarvitsee kuitenkin jotain epästandardeja virityksiä. Muistathan käyttää HTTPS:ää, jotta salasana kulkisi verkossa salattuna.
Kryptografinen avainpari on aika yliampuva vaihtoehto, mutta tietysti näinkin saa tehdä, jos haluaa. Muista silloin myös tallentaa yksityinen avain käyttäjän omalla salasanalla salattuna, ettei varas saa kaikkia kirjautumistietoja suoraan levyltä luettua. Toisaalta monimutkaiseen ratkaisuun liittyy isompi virheen mahdollisuus.
Jos WebSocketin avaamisesta ei ole suurta vaivaa, voisit yksinkertaisesti hoitaa kirjautumisen tunnuksella ja salasanalla vasta WS-yhteyden sisällä.
Jos taas toiveena on varmistaa ensin kelvollinen käyttäjä, yleensä tehtäisiin ihan tavallinen kirjautumissivu. Käyttäjä syöttäisi siis tunnuksen ja salasanan, ja palvelin antaisi näistä vastineeksi jonkinlainen istunnon tunnisteen. WebSocketin avaukseen tämä tunniste saataisiin esimerkiksi evästeenä tai ensimmäisenä WebSocket-viestinä. (Tietysti silloinkin on mahdollista, että joku yrittää WebSocket-yhteyttä ilman kelvollisat istuntoa.)
Serverissä on minimaalinen HTTP ja HTTPS toteutus mikä tällä hetkellä lähinnä päivittää yhteyden WebSocket yhteyteen. Koska meinasin tukea vain mobiilisovellus asiakasta selaimen sijaan niin ajattelin, että "HTTP basic authentication" olisi ihan toimiva vaihtoehto kirjautumistietojen välittämiseen serverille suoraan HTTP "Authorization" headerissa.
Kyseessä olisi siis pilvipalvelimella pyörivä serveri mikä toimisi "reitittimenä" älykotiohjaimien ja järjestelmien hallintaan käytettävien mobiilisovelluksien välillä. Tietysti älykotiohjain myös tallentaisi mittaustuloksia pilveen myöhempää tarkastelua varten.
Kryptografisen avainparin käyttö houkuttaisi, koska olisi 8th:lla myös helppo sekä suoraviivainen toteuttaa ja voisin tarvittaessa halutessani välittää kaiken liikenteen mobiilisovelluksen ja älykotiohjaimen välillä salattuna ja allekirjoitettuna.
Okei, sain vähän apuja kehittäjältä 8th foorumilla ja päädyin tälläiseen:
Asiakas lähettää serverille julkisen avaimen. Serveri muodostaa jaetun salaisuuden (serverin yksityinen avain, asiakkaan julkinen avain), jota se käyttää salaamaan satunnaisesti luodun istunnon avaimen asiakkaalle.
Jos asiakas lähettää väärän julkisen avaimen, niin kommunikointi ei ole mahdollista ja serveri katkaisee yhteyden.
Jos asiakas lähettää oikean julkisen avaimen, niin silloin se myös tietää jaetun salaisuuden (asiakkaan yksityinen avain, serverin julkinen avain) ja käyttää sitä purkamaan serveriltä saadun istunnon avaimen.
Nyt istunnon avainta voi käyttää salaamaan liikenne serverin ja asiakkaan välillä.
Kokeilin ideaa simuloituna ja tuntui toimivan odotetusti:
var server-public var server-private var client-public var client-private : generate-session-key \ -- s 12 cr:randbuf b:>base64 ; : app:main \ Luo julkinen ja yksityinen avain serverille ja asiakkaalle cr:ed25519 server-public ! server-private ! cr:ed25519 client-public ! client-private ! \ Luo ja salaa istuntoavain käyttäen jaettua salaisuutta \ avaimena serverin päässä. generate-session-key server-private @ client-public @ cr:ed25519-secret cr:>cp \ Pura istuntoavain käyttäen jaettua salaisuutta \ avaimena asiakkaan päässä. client-private @ server-public @ cr:ed25519-secret cr:cp> \ Salaa viesti Chacha20Poly1305 salaus algoritmilla käyttäen \ istuntoavainta avaimena. "Hello World!" over cr:>cp \ Pura viesti käyttäen istuntoavainta avaimena ja tulosta sisältö swap cr:cp> >s . cr ;
Tulostaa odotetusti:
Hello World!
Miksi tekisit itse salauksen, kun HTTPS hoitaa liikenteen salauksen (mukaan lukien otsikkotiedot, joita oma salaus ei tavoita)? HTTPS tulisi joka tapauksessa olla käytössä nykyään, jolloin omasta kaksisuuntaisesta salauksesta on lähinnä turhaa vaivaa.
Minusta fiksuin selitys, miksi HTTPS:n sisään voisi tehdä oman salauksen, olisi sellainen nykytermeillä ”end-to-end encryption”, jossa data olisi salattu käyttäjän omalla avaimella, jota ei ole edes palvelimella, jolloin siis vain käyttäjä itse pystyisi avaamaan datan.
Käyttäjän voi toki tunnistaa avaimella, jos huvittaa. Toisaalta pitää miettiä ohjelman käyttötapoja: olisiko hyödyllisempää olla perinteinen tunnus ja salasana, jotta käyttäjä voisi helpommin katsoa tietoja netistä eri laitteilla tai ylipäänsä pystyisi vaihtamaan uuteen kännykkään hukkaamatta tietoja.
Metabolix kirjoitti:
(14.08.2022 22:36:58): Miksi tekisit itse salauksen, kun HTTPS hoitaa...
Oma salaus ei tietenkään ole pakollinen HTTPS-yhteydellä. Pidän vielä avoimena vaihtoehtona perinteisen tunnistautumisen toteuttamisen käyttäjänimellä ja salasanalla.
Alla vielä yksi mahdollisuus tunnistautua avaimella, jos viestien salausta ei tarvita. Teksti on englanniksi kirjoittamani toiselle foorumille ja en nyt jaksanut suomeksi uudestaan kirjoitella, kun tuon kaikki varmaan kuitenkin ymmärtävät:
Client sends it's public key to server.
Server checks that public key exist inside the user database, responds with a challenge message and computes hash based on this message.
Client independently computes the message hash, passes private key and hash for "cr:ed25519-sign" and sends the result back to server.
Server uses public key, hash and signature buffer from the client to authenticate the user with "cr:ed25519-verify".
Yllä olevassa kuvauksessa hash vaikuttaa turhalta välivaiheelta ja on epäselvää, millä algoritmilla ja minkä takia se laskettaisiin. Muutenhan tuo on ihan tyypillinen challenge–response authentication: Palvelin antaa ”haasteen” (esimerkiksi 256-bittinen satunnaisdata, nonce). Asiakas soveltaa tähän yksityistä avainta ja palvelin tarkistaa tuloksen julkisella avaimella.
Metabolix kirjoitti:
(15.08.2022 08:31:02): Yllä olevassa kuvauksessa hash vaikuttaa...
Olet oikeassa, että voisi olla suoraan viestikin, mutta on tyypillisesti hash.
8th:lla on monipuolinen Crypto tuki mukana. Sanalistasta voi hakea "Crypto" hakusanalla.
jalski kirjoitti:
Olet oikeassa, että voisi olla suoraan viestikin, mutta on tyypillisesti hash.
Miten niin tyypillisesti? Ai siten tyypillisesti, että perinteisesti tietoturvan puutteita on paikattu arpomalla väliin pari ylimääräistä operaatiota ilman mitään ymmärrystä niiden merkityksestä?
Minusta tietoturvan paras lähtökohta on se, että tehdään vain perusteltuja toimenpiteitä. Jos jostain lasketaan tiiviste (hash), pitää pystyä perustelemaan, miksi se tehdään eli mitä lisäarvoa siitä tulee.
Metabolix kirjoitti:
Miten niin tyypillisesti? Ai siten tyypillisesti, että perinteisesti tietoturvan puutteita on paikattu arpomalla väliin pari ylimääräistä operaatiota ilman mitään ymmärrystä niiden merkityksestä?
Minusta tietoturvan paras lähtökohta on se, että tehdään vain perusteltuja toimenpiteitä. Jos jostain lasketaan tiiviste (hash), pitää pystyä perustelemaan, miksi se tehdään eli mitä lisäarvoa siitä tulee.
Tuo on varmasti aina hyvä lähtökohta. Luin tuon dokumentaatiosta ja olen myös nähnyt palvelimen kirjautumisohjeissa kyseisen "kättely" tavan.
Metabolix kirjoitti:
Minusta fiksuin selitys, miksi HTTPS:n sisään voisi tehdä oman salauksen, olisi sellainen nykytermeillä ”end-to-end encryption”, jossa data olisi salattu käyttäjän omalla avaimella, jota ei ole edes palvelimella, jolloin siis vain käyttäjä itse pystyisi avaamaan datan.
Annoit idean harjoituksena toteuttaa turvallisen chatti serverin:
Käyttäjän todentaminen:
Asiakas lähettää serverille julkisen avaimen. Serveri muodostaa jaetun salaisuuden (serverin yksityinen avain, asiakkaan julkinen avain), jota se käyttää salaamaan satunnaisesti luodun istunnon avaimen asiakkaalle.
Jos asiakas lähettää väärän julkisen avaimen, niin kommunikointi ei ole mahdollista ja serveri katkaisee yhteyden.
Jos asiakas lähettää oikean julkisen avaimen, niin silloin se myös tietää jaetun salaisuuden (asiakkaan yksityinen avain, serverin julkinen avain) ja käyttää sitä purkamaan serveriltä saadun istunnon avaimen.
Serveri todentaa vielä asiakkaan lähettämällä asiakkaalle random dataa salattuna istunnon avaimella. Asiakas purkaa datan istunnon avaimella ja lähettää takaisin serverille puretun datan hashin salattuna istunnon avaimella.
Nyt käyttäjien on mahdollista lähettää toisilleen yksityisviestejä salattuna, käyttäen jaettua salaisuutta avaimena siten, että serverikään ei pysty viestejä lukemaan.
jalski kirjoitti:
Tuo on varmasti aina hyvä lähtökohta. Luin tuon dokumentaatiosta ja olen myös nähnyt palvelimen kirjautumisohjeissa kyseisen "kättely" tavan.
Yleisesti ottaen jos uuteen ratkaisuun soveltaa pohjana aiemmin johonkin toiseen tarpeeseen tehtyä ratkaisua, niin olisi hyvä tietää MIKSI siihen alkuperäiseen ratkaisuun on päädytty.
Jos vaan kopioi mitä muut tekee ilman että on mitää käryä miksi niin tehdään, niin puhutaan lastikulttiohjelmoinnista.
Grez kirjoitti:
(15.08.2022 15:55:07): ”– –” Yleisesti ottaen jos uuteen ratkaisuun soveltaa...
Totta, mutta yleensä myöskään dokumentaation mukaan toimimista ei voi pitää virheellisenä menettelytapana.
Ja ehkä yleisessä tapauksessa syykin on niin yksinkertainen, että on turha lähettää serverille takaisin pitkää viestiä, kun lyhyempi tiivistekin ajaa saman asian?
jalski kirjoitti:
Ja ehkä yleisessä tapauksessa syykin on niin yksinkertainen, että on turha lähettää serverille takaisin pitkää viestiä, kun lyhyempi tiivistekin ajaa saman asian?
Eihän sitä tiivistettä tai viestiä tuossa lähetetäkään palvelimelle, vaan ainoastaan allekirjoitus (joka itsessään tyypillisesti on lyhyt)
Jos allekirjoitusalgoritmi haluaa lyhyen syötteen niin silloin tietenkin syöte ensin tiivistetään, mutta tässä on silloin selkeä syy joka johtuu valitusta algoritmista. Valittu allekirjoitusalgoritmi voi myös itse sisältää tiivistevaiheen, jolloin tiivisteen tekeminen ennen allekirjoitusta olisi tuplatyötä.
Grez kirjoitti:
(15.08.2022 16:21:05): ”– –” Eihän sitä tiivistettä tai viestiä tuossa...
Totta, mutta silti ainakaan serverin päässä ei tarvitse pitkää viestiä pitää muistissa sen aikaa kun odotellaan vastausta.
En kyllä ymmärrä miksi sen challenge-viestin pitäisi olla pitkä, mutta antaa olla.
Grez kirjoitti:
En kyllä ymmärrä miksi sen challenge-viestin pitäisi olla pitkä, mutta antaa olla.
Edelleen, dokumentaatiossa luki:
Given a buffer containing an ED25519 Diffie-Hellman private key (of the sender), and another buffer hash containing a hash (could be a full message, but typically a hash), signs the hash using DH algorithms and returns an signature buffer in sig or null if there was an error.
Olisin ehkä halunnut aiheesta muutakin keskustelua kuin väittelyä siitä, miksi joku asia on toteutettu väärin vaikka se on kuitenkin tehty ohjeen mukaan...
Ei kukaan ole sanonut, että se olisi toteutettu väärin, vaikka tiivisteen laskisitkin. Sanottiin että vaikuttaa turhalta välivaiheelta ja minusta edelleen vaikuttaa turhalta tehdä hash vain sen takia että dokumentissa sanotaan että niin yleensä tehdään (ja samassa että ei välttämättä tarvitse).
Jos tiivisteen laskemiselle on jokin selkeä syy (esim. käytettäisiin protokollaa, joka on määritelty käyttämään tiettyä tiivistettä, tai allekirjoitettava dokumentti olisi suurikokoinen, tai allekirjoitusalgoritmilla olisi vaatimus syötteelle jonka tiiviste täyttää mutta alkuperäinen dokumentti ei) niin sitten se ei vaikuttaisi turhalta välivaiheelta.
Eli nythän ei keskusteltu siitä saatko käyttää sitä tiivistettä vai ei. Tottakai saat. Mielestäni olet lähinnä itse lähtenyt vääntämään siitä että se tiiviste muka ei vaikuttaisi turhalta välivaiheelta, mutta minusta et kuitenkaan ole tuonut yhtään sellaista argumenttia, jonka perusteella se oikeasti olisi välttämätön.
Ja kyllähän se voi olla nopeampaa kopioida vaan joku aikaisempi toteutus, joka toimii, kuin löytää mahdollisesti kantapään kautta miksi jokin turhalta näyttävä välivaihe onkin välttämätön.
Jos itse toteutan jonkin jutun (eli en käytä sen tekemiseen valmista kirjastoa tai toteutusta tai standardia) niin sitten yleensä haluan myös tietää miksi teen minkäkin asian.
Ehkä tuossa dokumentaatiossa tarkoitetaan sitä, miten viesti todennetaan avaimella. Siinä on mahdollista käyttää tiivistettä juuri mainitsemasi koon takia. Toisaalta tähän perustuvat myös tietyt todelliset tietoturvahyökkäykset kuten paljon puhuttu md5-algoritmin heikkous: tietyssä tilanteessa on mahdollista aiheuttaa törmäys tiivisteeseen siten, että toinen osapuoli allekirjoittaa yhdenlaisen viestin mutta allekirjoitus pätee sitten myös toiseen viestiin, koska allekirjoitettuna on tiiviste eikä viesti.
Kuitenkin nyt kirjautumisessa ei ole kyse viestin allekirjoittamisesta vaan käyttäjän todentamisesta, jolloin sopivin ratkaisu on nimenomaan satunnainen "viesti", ei tiiviste. Eli tiivistäminen olisi käypä ratkaisu eri tilanteessa (oikean viestin kohdalla) mutta on sinun tilanteessasi lähinnä outoa.
Kielen tai kirjaston dokumentaatio ei ole yleensä mikään kattava kryptografisten funktioiden järkevän käytön opas vaan yksinkertainen listaus funktioista ja niiden parametreista. Perustiedot pitää hankkia muualta, ja kirjaston dokumentaatio on vain ohje, miten juuri kyseisessä kielessä ja kirjastossa saa palaset sovitettua yhteen.
Kokeilen nyt harjoituksena tehdä tietoturvallisen viestinvälitys serveri ohjelman, mikä välittää viestejä rekisteröityneiden käyttäjien välillä allekirjoitettuna ja salattuna siten, että vain viestin lähettäjä ja vastaanottaja pystyvät viestin purkamaan ja näkemään.
8th:lla on näppärä ominaisuus, että mihin tahansa tietotyyppiin voi tallentaa extrana mukaan mitä haluaa:
1 net: 00000000045b00f0 2 SOCKET:792:1
extra: n: 0000000003014be0 2 0Käytän tätä ominaisuutta hyödyksi siten, että serverin toiminta on callback-tyyppinen ja callback saa aina asiakkaan "net" UDT:n. Nyt toiminta on helppo toteuttaa tilakoneen avulla ja tallentaa tila mukaan extrana. Muut asiakkaan palvelemisessa tarvittavat tiedot voi kätevästi tallentaa "net" UDT:n opts map tietorakenteeseen.
"recv" callback:issä voi sitten tilan mukaan palvella asiakasta periaatteella:
extra@ [ ' tila1 , ' tila2 , ' tila3 , ' tila4 ] case
End-to-end on kuitenkin vain niin luotettava kuin avaimia välittävä taho. Eli turva tulee siitä, että teet käyttäjien avaimilla jaetun salaisuuden ja palvelin välittää vain salattua dataa. Ongelma tulee siitä, että palvelin voi huijata käyttäjiä (man in the middle), jos edes julkisia avaimia kuljetetaan palvelimen kautta.
Metabolix kirjoitti:
(16.08.2022 19:27:21): End-to-end on kuitenkin vain niin luotettava...
Julkisen avaimen ideahan on, että sen saa jakaa? En näe mahdollisuutta "man in the middle" huijaukseen ilman yksityistä avainta, jos käyttäjät on varmennettu ja ulkopuolisia käyttäjiä ei hyväksytä kirjautumaan serverille.
Toimintamalli olisi siis tämä:
Käyttäjän todentaminen:
Asiakas lähettää serverille julkisen avaimen. Serveri muodostaa jaetun salaisuuden (serverin yksityinen avain, asiakkaan julkinen avain), jota se käyttää salaamaan satunnaisesti luodun istunnon avaimen asiakkaalle.
Jos asiakas lähettää väärän julkisen avaimen, niin kommunikointi ei ole mahdollista ja serveri katkaisee yhteyden.
Jos asiakas lähettää oikean julkisen avaimen, niin silloin se myös tietää jaetun salaisuuden (asiakkaan yksityinen avain, serverin julkinen avain) ja käyttää sitä purkamaan serveriltä saadun istunnon avaimen.
Serveri todentaa vielä asiakkaan lähettämällä asiakkaalle random dataa salattuna istunnon avaimella. Asiakas purkaa datan istunnon avaimella ja lähettää takaisin serverille puretun datan hashin salattuna istunnon avaimella.
Serverin ja asiakkaan välinen viestiliikenne kulkee allekirjoitettuna yksityisellä avaimella ja salattuna istunnon avaimella.
Miten serverin päässä voisi päästä kiinni asiakkaan viestiin, jos asiakas allekirjoittaa viestin omalla yksityisella avaimellaan ja salaa viestin käyttämällä jaettua salaisuutta viestin vastaanottajan kanssa (oma yksityinen avain, vastapuolen julkinen avain). Vastapuoli varmistaa allekirjoituksen lähettäjän julkisella avaimella ja purkaa viestin käyttämällä jaettua salaisuutta (oma yksityinen avain, lähettäjän julkinen avain). Yksityiset avaimethan ovat vain käyttäjien tiedossa ja serverin kautta kulkevat pelkästään julkiset avaimet.
Eli 8th koodilla viestin allekirjoitus ja salaus sekä allekirjoituksen varmennus ja viestin purkaminen onnistuisi:
var client1-public var client1-private var client2-public var client2-private : app:main \ Create public and private keys for two clients for testing purposes cr:ed25519 client1-public ! client1-private ! cr:ed25519 client2-public ! client2-private ! \ Sign message using private key and encrypt message using shared secret "Hello World!" client1-private @ client2-public @ cr:ed25519-secret client1-private @ cr:>cpe \ Verify signature using senders public key, decrypt message using shared \ secret and print result client2-private @ client1-public @ cr:ed25519-secret client1-public @ cr:cpe> >s . cr ;
Hyökkäyksistä,,,
Jo asiakkaan ja palvelimen välinen yhteys on altis MITM-hyökkäykselle, jos ei palvelimen avainta ole ulkopuolelta varmennettu (tai jaettu ennakkoon jotain muuta, luotettavaa reittiä). Tämän takia nettipalvelimilla käytetään ulkopuolisten, luotettaviksi sovittujen tahojen allekirjoittamia sertifikaatteja, jotta käyttäjä tietää olevansa oikealla palvelimella. Edelleen kannustan luopumaan omista viritelmistä tässä kohdassa, kun HTTPS hoitaa palvelimen tunnistamisen ja liikenteen salauksen. Voit sitten tunnistaa käyttäjän julkisella avaimella ja yhdellä koeviestillä ilman mitään tiivisteitä ja jaettuja salaisuuksia ja istunnon tunnisteita.
Asiakkaiden välinen yhteys on altis palvelimen osalta MITM-hyökkäykselle, jos asiakkaat eivät pysty vaihtamaan avaimia suoraan vaan siinä luotetaan palvelimen rehellisyyteen. Eli kun palvelin välittää julkiset avaimet, niin mikä takaa, ettei se välitä omatekoisia avaimia, joilla sitten purkaa kaiken liikenteen välissä? No tietysti tämä ongelma on jo omaa luokkaansa, mutta vähintäänkin pitää tiedostaa, että edellä kuvatussa ratkaisussa liikenne on oikeasti asiakkaiden välillä salattua vain, jos palvelin niin haluaa. Asiakas voi tunnistaa tämän vain vertaamalla julkisia avaimia jonkin muun viestintäkanavan kautta.
Asiakkaiden välisiä viestejä voi lähettää kätevästi niin, että jokaisen viestin mukana tulee uusi symmetrinen salausavain salattuna vastaanottajan julkisella avaimella. Näin ainostaan vastaanottaja saa oikean avaimen ja saa sitten purettua itse viestin. Etuna on, että viestejä voi lähettää salattuna ilman etukäteistä yhteyden muodostamista ja saman viestin voi myös halvalla jakaa usealle käyttäjälle tai laitteelle, kun vain salattu versio salausavaimesta tarvitsee vaihtaa. (Vertaa esim. WhatsApp, ison videon jako usean käyttäjän usealle linkitetylle laitteelle.) Viestin mukaan voi liittää oman julkisen avaimen, ja viestin voi allekirjoittaa yksityisellä avaimella. Ratkaistavaksi luottamuskysymykseksi jää, mitä kautta ensimmäiseen lähetykseen tarvittava julkinen avain välitetään riittävän luotettavasti.
Nuo koodiesimerkkisi ovat siitä kummallisia, että olet laittanut kaikkien osapuolten toiminnan yhteen pötköön. Jos on pakko demonstroida asiaa näin yhdessä ohjelmassa, voisit vaikka edes muuttujien nimillä ilmaista, milloin jokin tieto siirtyy eri osapuolelle. Siis vaikka tiedonsiirron merkiksi client1.peer_public_key = client2.public_key ja jokaiselle funktiolle parametriksi vain saman osapuolen hallussa olevia tietoja.
:)
Metabolix kirjoitti:
Nuo koodiesimerkkisi ovat siitä kummallisia, että olet laittanut kaikkien osapuolten toiminnan yhteen pötköön. Jos on pakko demonstroida asiaa näin yhdessä ohjelmassa, voisit vaikka edes muuttujien nimillä ilmaista, milloin jokin tieto siirtyy eri osapuolelle. Siis vaikka tiedonsiirron merkiksi client1.peer_public_key = client2.public_key ja jokaiselle funktiolle parametriksi vain saman osapuolen hallussa olevia tietoja.
Tuossa oli vaan tarkoituksena demota 8th:llä allekirjoitus, viestin salaus, allekirjoituksen varmennus ja viestin purku. Oleellista on vain huomioida avaimien käyttö.
Olet kyllä oikeassa, että oikeastihan asiakkaat generoisivat omat avaimensa erillisellä työkalulla, ilmoittaisivat toisilleen julkiset avaimet ja pitäisivät yksityisen avaimen visusti itsellään.
jalski kirjoitti:
Oleellista on vain huomioida avaimien käyttö.
Kaikkein oleellisinta on huomioida se, kenellä ne avaimet ja eri tiedot ovat missäkin vaiheessa ja millaista kanavaa pitkin ne siirretään. Siis varsinainen suunnitelma. Siksi on minusta hassua, että juuri tämä asia puuttuu demostasi. Muutaman funktion kutsuminen taas on sitä perusjuttua, jonka voi kopioida mistä tahansa dokumentaatiosta.
Aihe on jo aika vanha, joten et voi enää vastata siihen.