WEBVTT

00:00:00.000 --> 00:00:04.870
[Translated by Timo Broström 
(KYBS2004 course assignment at JYU.FI)]

00:00:04.870 --> 00:00:06.569
<i>musiikkia</i>

00:00:10.806 --> 00:00:14.546
Tervetuloa kaikki tähän kaaoottiseen
vuoteen sekä tapahtumaan

00:00:14.546 --> 00:00:17.326
olen Karra ja tulen olemaan teidän tiedottaja

00:00:17.326 --> 00:00:20.490
on ilo pystyä kuuluttamaan puhe

00:00:20.490 --> 00:00:23.607
kvantti-jälkeinen kryptografia:
kiertotiet, viivästykset ja katastrofit

00:00:23.607 --> 00:00:26.320
jonka pitävät Tanja Lange 
ja D.J. Bernstein

00:00:26.450 --> 00:00:32.809
Tanja Lange on kryptograafikko ja matemaatikko
joka erikoistuu kantti-jälkeiseen krytografiaan

00:00:32.809 --> 00:00:35.445
joka on korvaamassa kryptografiaa 
jota käytämme nykypäivänä

00:00:35.445 --> 00:00:39.180
sellaisilla versiolla jotka ovat turvassa
kvanttitietokoneilla toteutetuilta hyökkäyksiltä

00:00:39.180 --> 00:00:43.325
hän on professori Einhovenin 
teknillisessä yliopistossa

00:00:43.325 --> 00:00:46.558
ja hänellä on ylpeilee useilla 
eri julkaisuilla ja erityksillä

00:00:46.558 --> 00:00:50.953
hän oli myös PQ crypton koordinaattori

00:00:50.953 --> 00:00:52.683
joka on yleiseurooppalainen liitto

00:00:52.683 --> 00:00:55.168
kvantti-jälkeisen kryptografian 
käyttöönottamiseksi

00:00:55.168 --> 00:01:01.201
D. J. B. on professori Illinoisin 
yliopistossa Chicagossa

00:01:01.201 --> 00:01:06.793
sekä professori Bochumin yliopistossa.
hän työskentelee kryptografian parissa ja

00:01:06.793 --> 00:01:09.000
hän on kehittänyt 
salakirjoitusjärjestelmiä joita käytetään

00:01:09.000 --> 00:01:12.032
avoimen lähdekoodin kryptografiassa, 
mahdollisesti käytät jotain

00:01:12.032 --> 00:01:15.652
sellaista salakirjoitusjärjestelmää 
katsoessasi tätä puhetta juuri nyt

00:01:15.652 --> 00:01:18.990
yhdessä he kehittivät vaikuttavan 
määrän projekteja

00:01:18.990 --> 00:01:23.751
aina turvallisen kryptografian 
käyttöönoton yksinkertaistamisesta

00:01:23.751 --> 00:01:26.990
turvallisien kvantti-jälkeisten 
tietotyyppien rakentamiseen

00:01:26.990 --> 00:01:29.924
molemmat heistä ovat 
aktivisteja jotka taistelevat

00:01:29.924 --> 00:01:33.261
läpinäkyvämmän kryptografian 
standardisointiprosessin puolesta

00:01:33.261 --> 00:01:39.986
nyt kaikki laittakaa räpylänne yhteen

00:01:39.986 --> 00:01:42.800
laittakaa kätenne yhteen
Tanja Longelle ja D.J.B:lle!

00:01:42.800 --> 00:01:50.872
selvä, kiitos kivasta esipuheesta

00:01:50.872 --> 00:01:54.740
sukelletaan heti asiaan
aloitetaan HTTPS:llä

00:01:54.740 --> 00:01:57.952
kun menet HTTPS-sivulle 
tai suojatulle sivulle

00:01:57.952 --> 00:02:02.994
käytät TLS:ä, kuljetuskerroksen turvaa
turvataksesi kommunikaatiosi

00:02:02.994 --> 00:02:07.428
TLS käyttää kahdenlaista 
kryptografiaa muutamista eri syistä

00:02:07.428 --> 00:02:10.288
ensinnäkin, se turvautuu 
julkisen avaimen kryptografiaan

00:02:10.288 --> 00:02:14.341
se tekee kahta asiaa
ensiksi, se tarjoaa allekirjoituksia

00:02:14.341 --> 00:02:18.406
julkisen avaimen allekirjoituksia
se varmistaa että hyökkääjä ei pysty

00:02:18.406 --> 00:02:21.825
korvaamaan palvelimen 
dataa hyökkääjän datalla

00:02:21.825 --> 00:02:23.831
ja teeskennellä olevansa palvelin

00:02:23.831 --> 00:02:26.392
lisäksi TLS käyttää 
julkisen avaimen salausta

00:02:26.392 --> 00:02:30.999
esimerkiksi NIST P-256,
RSA-4096 on allekirjoittajajärjestelmä

00:02:30.999 --> 00:02:36.860
NIST P-256:ta voidaan käyttää salaukseen
ja tämä salaa datasi niin ettei hyökkääjä

00:02:36.860 --> 00:02:39.142
voi ymmärtää sitä

00:02:39.142 --> 00:02:44.219
suoritustehoon liityvistä syistä
kryptografia on monimutkaisempi kuin

00:02:44.219 --> 00:02:48.293
vain tämä julkisen avaimen kryptografia
se sisältää myös symmetrisen kryptografian

00:02:48.293 --> 00:02:50.608
joskus sitä nimitetään 
salaisen avaimen kryptografiaksi

00:02:50.608 --> 00:02:55.466
kun kokoat kaiken yhteen TLS:n
saat kolme peruspalikkaa

00:02:55.466 --> 00:02:56.816
on julkisen avaimen salaus

00:02:56.816 --> 00:02:59.995
joka sen sijaan että 
se salaisi datasi niin

00:02:59.995 --> 00:03:04.928
etteivät hyökkääjät voi ymmärtää sitä
se salaa vain avaimen

00:03:04.928 --> 00:03:07.868
se lähettää avaimen 
turvallisesti ja salassa

00:03:07.868 --> 00:03:09.371
päästä toiseen

00:03:09.371 --> 00:03:12.198
ja julkisen avaimen allekirjoituksia
käytetään sen varmistamiseksi

00:03:12.198 --> 00:03:14.352
ettei hyökkääjä pysty korvaamaan
toista avainta

00:03:14.352 --> 00:03:16.880
ja lopuksi avainta käytetään

00:03:16.880 --> 00:03:19.322
datasi suojaamiseen 
symmetrisen kryptografian avulla

00:03:19.322 --> 00:03:22.825
kaikista muistakin 
protokollista joita käytät

00:03:22.825 --> 00:03:25.075
olisi mahdollista tehdä 
tämän tyyppiset diat

00:03:25.075 --> 00:03:28.295
kuten SSH:sta mutta ne kaikki toimivat
varsin samalla tavalla

00:03:28.295 --> 00:03:30.736
korostan nyt kaksi osaa tästä diasta

00:03:30.736 --> 00:03:33.825
RSA-4096 
tyypillinen allekirjoitusjärjestelmä

00:03:33.825 --> 00:03:36.318
ja tyypillinen salausjärjestelmä 
NIST P-256

00:03:36.318 --> 00:03:40.919
koska nämä kaksi tullaan murtamaan
kvanttitietokoneiden takia

00:03:40.919 --> 00:03:43.239
ilman kvanttitietokoneita 
mitään tiedossa olevia

00:03:43.239 --> 00:03:44.936
uhkia ei olisi mutta

00:03:44.936 --> 00:03:47.249
kunhan hyökkääjällä on 
iso kvanttitietokone

00:03:47.249 --> 00:03:49.055
mikä luultavasti tapahtuu

00:03:49.055 --> 00:03:52.187
se ei ole varmaa 
ehkä panostukset kvanttitietokoneisiin

00:03:52.187 --> 00:03:53.365
epäonnistuvat jostain syystä

00:03:53.365 --> 00:03:56.458
mutta näyttää siltä 
että kvanttitietokoneet

00:03:56.458 --> 00:03:57.364
ovat yhä menestyvämpiä

00:03:57.364 --> 00:03:59.076
ja kunhan kvanttitietokoneet 
ovat tarpeeksi isoja

00:03:59.076 --> 00:04:01.193
ehkä kymmenen vuoden päästä

00:04:01.193 --> 00:04:04.127
sen jälkeen hyökkääjät 
voivat ajaa hyökkäysalgoritmin

00:04:04.127 --> 00:04:07.631
jota kutsutaan Shorin algoritmiksi
joka löytää salaiset RSA-avaimesi ja

00:04:07.631 --> 00:04:12.522
salaiset NIST P-256 avaimesi
ja tässä vaiheessa hyökkääjät voivat

00:04:12.522 --> 00:04:14.568
tarkastella tietoja 
joita he tallentavat nyt

00:04:14.568 --> 00:04:17.861
se ei ole uhka vain tulevaisuuden datalle
vaan se on myös uhka

00:04:17.861 --> 00:04:21.005
nykyhetken tietojesi 
luottamuksellisuudelle

00:04:21.005 --> 00:04:25.230
koska hyökkääjät tallentavat jo
nyt kaiken minkä he voivat Internetissä

00:04:25.230 --> 00:04:28.001
ja sitten kun heillä on 
iso kvanttitietokone

00:04:28.001 --> 00:04:33.715
he voivat takautuvasti purkaa salaukset
koska he voivat murtaa RSA-4096:n

00:04:33.715 --> 00:04:38.946
ja NIST P-256:n
nimenomaan NIST P-256 tarjoaa salauksen

00:04:38.946 --> 00:04:43.143
ja he voivat palata ajassa taaksepäin
ja murtaa salauksen jota käytät tänään

00:04:43.143 --> 00:04:45.380
mitä me teemme tälle?

00:04:45.380 --> 00:04:48.155
Norminmukainen lähestymistapa 
on mitä me kutsumme

00:04:48.155 --> 00:04:50.954
kvantti-jälkeiseksi kryptografiaksi
kuulit sen jo aiemmin se oli meidän

00:04:50.954 --> 00:04:54.907
otsikossamme se on korvaava kryptografia
joka on suunniteltu se mielessä pitäen

00:04:54.907 --> 00:04:57.785
että hyökkääjällä on 
käytössä kvanttitietokone

00:04:57.785 --> 00:05:02.308
joten eli kuten airue 
jo aiemmin mainitsikin

00:05:02.308 --> 00:05:06.449
olin koordinaattorina PQCRYPTO projektissa
ja se tarkoittaa että olen nipistellyt

00:05:06.449 --> 00:05:09.828
ympäri maailmaa ja pitänyt puheita
kvantti-jälkeisestä kryptografiasta

00:05:09.828 --> 00:05:13.791
tässä on kuvankaappaus puheesta jonka
pidin kuusi ja puoli vuotta sitten

00:05:13.791 --> 00:05:19.827
missä korostin kuten Dan teki tänään
kvantti-jälkeisen kryptogragian tärkeyttä

00:05:19.827 --> 00:05:23.161
ja korostin 
että on tärkeää tehdä suositukset

00:05:23.161 --> 00:05:27.067
jotka kertovat mitä algoritmeja meidän
pitäisi käyttää korvataksemme RSA:n ja

00:05:27.067 --> 00:05:30.684
NIST P-256:n jotka 
näitte edellisillä dioilla

00:05:30.684 --> 00:05:36.628
ja sitten käsittelin kysymystä pitäisikö
meidän standardisoida nyt vai myöhemmin

00:05:36.628 --> 00:05:42.872
argumentteja löytyy molemmilta puolilta
ja, no, jos stardardisoitaisiin nyt,

00:05:42.872 --> 00:05:47.115
kuusi vuotta sitten tuntui että vielä on
niin paljon tehtävää ja meillä on paljon

00:05:47.115 --> 00:05:49.350
parempi järjestelmä 
jos odotamme vähän pidempään

00:05:49.350 --> 00:05:56.779
toistaalta on huoli virastojen ja muiden
pimeyden voimien keräämästä datasta

00:05:56.779 --> 00:06:03.378
ja mitä myöhempään se julkaistaan
sitä enemmän dataa ja turvallisuutta

00:06:03.378 --> 00:06:07.762
menetetään joten olisi tärkeää saada
asioita eteenpäin ja ratkaisumme silloin

00:06:07.762 --> 00:06:13.579
mitä olin mainostamassa vuonna 2016 oli
vuonna 2015 julkaistut suositukset jossa

00:06:13.579 --> 00:06:17.082
sanottiin että 
keskittäminen vie paljon aikaa

00:06:17.082 --> 00:06:20.820
me emme ole siinä vaiheessa vielä
mutta jos joku haluaa suojella itseään

00:06:20.820 --> 00:06:24.160
tässä mitä me, 
no tässä on aikamoinen määrä

00:06:24.160 --> 00:06:28.559
tutkijoita jotka ilmoittautuivat tähän
lausuntoon osana PQCRYPTO projektia

00:06:28.559 --> 00:06:34.875
mitä me suosittelemme?
meidän suosittelumme olivat mitä kutsumme

00:06:34.875 --> 00:06:36.577
varovaiseksi kryptografiassa

00:06:36.577 --> 00:06:38.440
se ei tarkoita 
poliittisesti konservatiivinen

00:06:38.440 --> 00:06:42.516
vaan se tarkoittaa tylsää se tarkoittaa
että jokin on ollut jo pitkään ilmoilla

00:06:42.516 --> 00:06:47.079
monet ihmiset ovat analysoineet sen
ja emme odota mitään muutoksia siihen

00:06:47.079 --> 00:06:53.032
symmetrisen avaimen puolella, kuten Dan
oli jo sanonut, niihin kvanttitietokoneet

00:06:53.032 --> 00:06:56.130
eivät vaikuta joten jos käytät tarpeeksi
suuria kokoja

00:06:56.130 --> 00:07:02.005
256-bittisten avainten kanssa
niin AES tai Salsa20 ovat riittäviä

00:07:02.005 --> 00:07:07.068
myös todentamisessa, kun saat avaimen,
siihen ei voi vaikuttaa

00:07:07.068 --> 00:07:14.402
julkisen avaimen salauksen ja
allekirjoituksen RSA-4096:n ja

00:07:14.402 --> 00:07:19.336
ECC NIST P-256:n me juodumme korvaamaan
niitä varten meillä on korvikkeet ja tässä

00:07:19.336 --> 00:07:21.657
me annoimme 
korkean luottamuksen suosituksen

00:07:21.657 --> 00:07:24.461
eli käytä 
McEliecen järjestelmää minkä nimi

00:07:24.461 --> 00:07:26.624
saattaa näkyä hieman myöhemmin

00:07:26.624 --> 00:07:29.036
ja käytä 
tiivistepohjaisia allekirjoituksia

00:07:29.036 --> 00:07:33.557
ja SPHINCS:n haluat tutusta myöhemmin
me myös julkistimme joitain arvioinnin

00:07:33.557 --> 00:07:37.475
alaisena olevia kohteina mikä tarkoittaa
että niitä ei kannata käyttää juuri nyt

00:07:37.475 --> 00:07:43.541
mutta tulevaisuudessa ne voivat olla ok
ja meille tämä oli ok, me iskemme seipään

00:07:43.541 --> 00:07:45.366
maahan, me sanomme 
että nämä ovat turvallisia

00:07:45.366 --> 00:07:50.487
ja ihmisten tulisi toimia niin ja kaikki
elävät onnelisina elämän loppuun asti

00:07:50.487 --> 00:07:52.490
ja me olemme valmiita puheemme kanssa

00:07:52.490 --> 00:07:54.921
vai elivätkö sittenkään 
kaikki onnellisesti

00:07:54.921 --> 00:07:56.392
elämänsä loppuun asti?

00:07:56.392 --> 00:07:58.918
Katsotaan mitä oikeasti 
tapahtui tämän jälkeen

00:07:58.918 --> 00:08:01.241
järjestely, no, 
asiat jotka pitäisi julkistaa

00:08:01.241 --> 00:08:05.041
itse asiassa oli eräs kokeilu
jota Google piti käynnissä

00:08:05.041 --> 00:08:09.236
joka sanoi että vuonna 2016 Google Chrome
lisäsi kvantti-jälkeisen vaihtoehdon

00:08:09.236 --> 00:08:11.438
nyt, se ei tarkoita että jokainen

00:08:11.438 --> 00:08:14.096
verkkopalvelin tuki sitä 
se oli vain kokeilu

00:08:14.096 --> 00:08:15.674
missä Google laittoi sen päälle joillain

00:08:15.674 --> 00:08:19.064
heidän palvelimillaan 
ja sanoi ok katsotaan

00:08:19.064 --> 00:08:22.034
miten hyvin tämä toimii ja kuulostivat
todella innostuineilta heidän blogissaan

00:08:22.040 --> 00:08:24.695
jossa he julkistivat sen että he auttavat
käyttäjiä suojautumaan

00:08:24.695 --> 00:08:26.853
kvanttitietokoneilta
katsotaan toimiiko tämä

00:08:26.853 --> 00:08:29.462
järjestelmä jota he käyttivät kutsuttiin
nimellä New Hope (NH)

00:08:29.462 --> 00:08:34.886
he eivät pelkästään salanneet NH:lla,
NH on kvantti-jälkeinen salausjärjestelmä

00:08:34.886 --> 00:08:39.633
he myöskin salasivat kvanttia-edeltävällä
salauksella, elliptisten käyrien

00:08:39.633 --> 00:08:42.369
salausmenetelmällä, ECC
kuten Tanja aikaisemmin

00:08:42.369 --> 00:08:46.679
mainitsi NIST P-256
on esimerkki ECC:stä, x25519 on toinen

00:08:46.679 --> 00:08:49.897
esimerkki ECC:stä, tämä on jotain mitä
käytät tänä päivänä salataksesi datasi

00:08:49.897 --> 00:08:55.076
ja mitä Google teki, se salasi NH:lla
kvantti-jälkeisen turvallisuuden

00:08:55.076 --> 00:08:58.548
takaamiseksi ja salasi myös 
x25519:lla kuten he tekevät

00:08:58.548 --> 00:09:01.972
normaalisti myös tänä päivänä
asian ydin on että jos jotain menee

00:09:01.972 --> 00:09:07.756
pahasti pieleen NH:n kanssa niin meillä
silti on kvanttia-edeltävä turvallisuus

00:09:07.756 --> 00:09:11.422
joten ainakaan välitöntä turvallisuusuhkaa
ei ole, he eivät ole pahentamassa asioita

00:09:11.422 --> 00:09:14.363
tietysti jos NH on rikki niin he eivät ole
myöskään parantamassa

00:09:14.363 --> 00:09:17.141
asioita mutta pääasia
oli yrittää saada asioita paremmaksi ja

00:09:17.141 --> 00:09:20.609
varmistaa samalla ettei asiat mene
pahemmaksi salaamalla molemmilla sekä

00:09:20.609 --> 00:09:22.686
kvanttia-edeltävällä 
että kvantti-jälkseisellä

00:09:22.686 --> 00:09:27.657
asioilla ja varasuunnitelma on todella
tärkeää olla olemassa koska NH on uusi

00:09:27.657 --> 00:09:32.590
salausjärjestelmä, no, oli vuonna 2016
pääpalat NH:n suunnittelussa tulivat

00:09:32.590 --> 00:09:38.252
vuosilta 2010, 2014 ja 2015 ja se ei ole
paljon aikaa asioiden läpikäymiseen ja

00:09:38.252 --> 00:09:41.878
kryptografiassa asiat voivat välillä olla
maisemissa vuosia ennen kuin niistä

00:09:41.878 --> 00:09:45.097
löydetään turvallisuusongelmia
on todella tärkeää että uusille

00:09:45.097 --> 00:09:50.926
salausjärjestelmille annetaan aikaa kypsyä
toinen ongelma uusien salausjärjestelmien

00:09:50.926 --> 00:09:55.859
kanssa on että joskus ne patentoidaan
patenit säilyvät 20 vuotta ja tämä tapahtui

00:09:55.859 --> 00:10:00.755
NH:lle, patentin haltija otti yhteyttä
Googleen ja sanoi että haluan rahaa teidän

00:10:00.755 --> 00:10:06.669
NH kokeilusta. Google ei koskaan
antanut julkista lausuntoa tästä patentti-

00:10:06.669 --> 00:10:11.116
uhkasta, mutta jostain syystä 
marraskuussa 2016 he poistivat NH

00:10:11.116 --> 00:10:16.125
mahdollisuuden Chromesta ja palvelimiltaan
muitakin asioita tapahtui vuonna 2016

00:10:16.125 --> 00:10:22.404
Yhdysvaltain hallinnolla on virasto, NIST,
jolla on pitkä historia yhteistyöstä

00:10:22.404 --> 00:10:28.271
kansallisen turvallisuusviraston (NSA)
kanssa ja NIST sanoi että vuoden päästä

00:10:28.271 --> 00:10:33.193
loppuvuodesta 2017 he haluaisivat 
kryptograafikkojen toimittavan ehdotuksia

00:10:33.193 --> 00:10:37.349
kvantti-jälkeiselle salausjärjestelmälle,
salausjärjestelmät ja allekirjoitusjärjestelmät

00:10:37.349 --> 00:10:44.678
joka standardisoitaisiin aikanaan
yksi mielenkiintoinen asia jonka he sanoivat

00:10:44.678 --> 00:10:50.410
pyynnössään oli että et saa toimittaa
sekamuotoja, eli salata molemmilla

00:10:50.410 --> 00:10:56.042
kvantti järjestelmillä ja ECC:llä tai 
allekirjoittaa jollain mitä käytät nyt ja

00:10:56.042 --> 00:10:59.424
jollain kvantti-jälkeisellä ratkaisulla
he sanoivat että algoritmit eivät saa

00:10:59.424 --> 00:11:03.488
sisältää ECC:tä tai mitään muuta joka 
voidaan murtaa kvanttitietokoneilla

00:11:03.488 --> 00:11:07.962
sovelluskehittäjän näkökulmasta on hyvä 
olla ECC kerros erillään kaikesta muusta

00:11:07.962 --> 00:11:10.524
ja sanoa että mitä tahansa teetkään
kvantti-jälkeisellä järjestelmällä se

00:11:10.524 --> 00:11:15.998
yhdistetään x25519 kanssa esimerkiksi. 
Mutta he eivät sanoneet että sinun täytyisi

00:11:15.998 --> 00:11:20.756
yhdistää kaikki ECC:n kanssa, esimerkiksi
x25519 erillisenä kerroksena, he sanoivat

00:11:20.756 --> 00:11:23.855
älä toimita mitään mikä on 
yhdistetty ECC:n kanssa

00:11:23.855 --> 00:11:33.185
järjestämällä tämän kilpailun kvantti-
jälkeisille järjestelmille NIST viestititti

00:11:33.185 --> 00:11:36.194
yrityksille että odottakaa, älkää ottako
käyttöön kvantti-jälkeisiä salauksia

00:11:36.194 --> 00:11:43.637
ja tässä oli sekä keppi että porkkana, 
keppi oli patentit, Google joutui juuri

00:11:43.637 --> 00:11:47.174
ongelmiin ottamalla jotain käyttöön
ja hupsista sillä olikin patentti

00:11:47.174 --> 00:11:51.662
mikä muu on patentoitu? ja NIST sanoi että
meillä on prosessi joka johtaa

00:11:51.662 --> 00:11:55.690
kryptografisiin standardeihin jotka voi 
vapaasti toteuttaa eli patentit eivät estä

00:11:55.690 --> 00:11:59.358
sinua ottamasta käyttöön asioita ja he myös
sanoivat että he aikovat valita jotain

00:11:59.358 --> 00:12:05.308
mikä on tarpeeksi vahva, turvallisuus on
kaikkein tärkein tekijä arvioinnissa

00:12:05.308 --> 00:12:10.724
joten toimialat katsovat tätä ja sanoivat 
ok odotetaan NIST:ä ja muut

00:12:10.724 --> 00:12:16.124
standardisointi organisaatiot odottavat 
myös. IETF:llä on oma tutkimusorganisaatio

00:12:16.124 --> 00:12:22.156
IRTF asettaa Internetin standardeja ja 
kryptoryhmä IRTF:ssä pohti että me

00:12:22.156 --> 00:12:28.544
standardisoimme ne jotka ovat jo meidän
pöydällämme, kuten tiivistejärjestelmiä

00:12:28.544 --> 00:12:35.623
mutta kaiken muun osalta me odotamme
NIST:ä. ISO sanoi myös että he odottavat

00:12:35.623 --> 00:12:40.718
NIST:ä. Ihan kaikki organisaatiot eivät 
sanoneet näin, esimerkiksi Kiinan hallitus

00:12:40.718 --> 00:12:45.587
sanoi että he järjestävät heidän oman
kilpailunsa mutta, no, ketä kiinnostaa?

00:12:45.587 --> 00:12:53.258
Joten takaisin NIST kilpailuun, tässä on
kaikki ehdotukset, joten loppuvuodesta 2017

00:12:53.258 --> 00:12:58.591
oli 69 ehdotusta 260 eri kryptograafikolta
en aio lukea kaikki nimiä mutta tämä oli

00:12:58.591 --> 00:13:01.161
aikamoinen työkuorma kryptografian
analyytikoille.

00:13:01.161 --> 00:13:08.940
me pidettiin hauskaa alkuvuodesta 2017, he
jotka näkivät meidät lavalla vuonna 2018

00:13:08.940 --> 00:13:12.613
tietävät että pidimme puheita siitä kuinka
hauskaa meillä oli rikkoa näitä ehdotuksia

00:13:12.613 --> 00:13:16.653
mutta se oli aikamoinen taakka. Katsotaan
mitä NIST teki kilpailulla.

00:13:16.653 --> 00:13:20.722
vuonna 2019 eli kaksi vuotta myöhemmin, no
vuosi ja vähän myöhemmin he olivat

00:13:20.722 --> 00:13:26.753
rajaamassa ehdotuksia 26 ehdokkaaseen
ja vuonna 2020 heinäkuussa he rajasivat

00:13:26.753 --> 00:13:32.987
ehdokkaita lisää, he ottivat 15 ehdokasta 
26:sta. Tarkoitus oli keskittyä johonkin

00:13:32.987 --> 00:13:40.221
missä on järkeä ja he priorisoivat 
vahvimpia ehdokkaita paitsi silloin jos

00:13:40.221 --> 00:13:43.893
sovellus todella tarvitsee jotain
tehokkaampaa

00:13:43.893 --> 00:13:49.228
itse asiassa ei, he eivät ollenkaan 
tehneet näin. Jos luet raportin ja katsot

00:13:49.228 --> 00:13:52.093
mitkä ehdokkaat he valitsivat, milloin
tahansa kun heillä oli vaihtoehto

00:13:52.093 --> 00:13:55.919
nopeuden ja turvallisuuden välillä,
tarkoitat he totta kai karsivat pois asiat

00:13:55.919 --> 00:14:02.034
jotka olivat todella rikki ja karsivat
asiat jotka olivat todella tehottomia

00:14:02.034 --> 00:14:04.844
mutta ottakaapa esimerkiksi SPHINCS jonka
Tanja mainitsi aikaisemmin, todella

00:14:04.844 --> 00:14:09.364
varovainen kaikki ovat samaa mieltä että 
tämä on turvallisin allekirjoitusjärjestelmä

00:14:09.364 --> 00:14:21.859
no, NIST ei sanonut että käytä SPHINCS:iä
vaan että me odotetaan SPHINCS+:n

00:14:21.859 --> 00:14:27.114
standardisoimista ellei niin moni asia
ole rikki että meidän pitää käyttää SPHINCS:ä

00:14:27.114 --> 00:14:36.315
Niin ja tämän vuoden heinäkuussa NIST 
sanoi että he valitsevat neljä standardia

00:14:36.315 --> 00:14:43.232
yksi oli SPHINCS+ ja neljää muuta ehdotusta
tutkittiin yhä. Tämä vaikuttaa siltä

00:14:43.232 --> 00:14:47.335
että ehkä heidän itseluottamuksensa horjui
Joten mitä tapahtui?

00:14:47.335 --> 00:14:55.935
Kuva 69 ehdotuksesta muuttuu kun menemme 
ajassa viisi ja puoli vuotta eteenpäin

00:14:55.935 --> 00:15:01.376
tässä on värikoodaus. Siniset ovat edelleen
mukana NIST:n kilpailussa, eli neljä

00:15:01.376 --> 00:15:06.179
standardisoitavaa järjestelmää ja neljä
neljännen kierroksen ehdokasta

00:15:06.179 --> 00:15:12.863
harmaat eivät päässeet eteenpäin ja 
tarkoittaa ettei niitä ole murrettu mutta

00:15:12.863 --> 00:15:18.277
ne putosivat niin aikaisin ettei ketään
enää kiinnostanut niiden murtaminen

00:15:18.277 --> 00:15:21.036
ruskea väri tarkoittaa vähemmänen 
turvallinen kuin väitetty, punainen

00:15:21.036 --> 00:15:25.044
tarkoittaa todella murrettua ja punainen 
joka on alleviivattu tarkoittaa

00:15:25.044 --> 00:15:33.781
todella todella murrettua.
Mitä voit nähdä tässä on se että murrettuja

00:15:33.781 --> 00:15:40.404
järjestelmiä on paljon. On myös
mielenkiintoinen violetti oikeassa alakulmassa

00:15:40.404 --> 00:15:48.831
Jos muistat vesivärit niin violetti on 
punaisen ja sinisen sekoitus. SIKE valittiin

00:15:48.831 --> 00:15:57.647
heinäkuussa sekä murrettiin heinäkuussa 
viiden vuoden analyysin jälkeen hyökkäyksellä

00:15:57.647 --> 00:16:02.646
joka voidaan ajaa sekunneissa joten SIKE
on tapaus jossa jotain meni todella väärin

00:16:02.646 --> 00:16:07.676
ja voidaan sanoa että useat pienet asiat
horjuttivat vähän itseluottamusta

00:16:07.676 --> 00:16:13.247
jonka jälkeen NIST valitsi sentään edes
SPHINCS:n, tämä ei johtanut muiden

00:16:13.247 --> 00:16:17.587
varovaisten vaihtoehtojen valitsemiseen
jotkut niistä ovat edelleen hautumassa

00:16:17.587 --> 00:16:20.909
mutta tämä ei olekaan kypsä ala.

00:16:20.909 --> 00:16:26.367
Mitäs tapahtui sillä välin käyttöönoton
puolella? Muistakaa, on kaksi osaa Tanjan

00:16:26.367 --> 00:16:30.796
dioista vuodelta 2016. Hän sanoi että 
olisi hyvä ottaa käyttöön jotain nyt

00:16:30.796 --> 00:16:33.643
suojellaksesi käyttäjiä koska meillä on 
turvallisuusongelma nyt, hyökkääjät

00:16:33.643 --> 00:16:37.997
tallentavat asioita nyt ja meidän pitää
yrittää suojautua siltä ja meidän pitää

00:16:37.997 --> 00:16:41.343
pystyä tekemään se nopeammin kuin 
standardisaatioprosessi joka Google oli

00:16:41.343 --> 00:16:48.584
aloittamassa vuonna 2016 mutta pelästyivät
patenttiongelmaa. Vuoteen 2019 mennessä

00:16:48.584 --> 00:16:52.778
toimialat ja useat avoimen lähdekoodin 
projektit katsoivat tätä ja pohtivat että

00:16:52.778 --> 00:16:59.060
ehkä olisi hyvä aika ottaa käyttöön asioita
sillä jotain meni väärin vuonna 2016

00:16:59.060 --> 00:17:04.130
mutta tässä vaiheessa NIST on kerännyt
lausuntoja kaikilta ehdokkailta tässä

00:17:04.130 --> 00:17:08.310
kilpailussa todeten mitkä ehdotukset ovat
patentoituja ja se antaa meille paljon

00:17:08.310 --> 00:17:12.346
tietoa kun 260 kryptograafikkoa kertoo 
mitkä ovat patentoituja

00:17:12.346 --> 00:17:18.379
ja vuonna 2019 oli yhä selkeämpää että 
kvanttitietokoneet ovat tulossa

00:17:18.379 --> 00:17:20.616
joten esimerkkejä siitä mitä tapahtui
vuonna 2019

00:17:20.616 --> 00:17:26.530
OpenSSH version 8, kopioiden TinySSH:ta 
kertoi että he lisäävät sekamuodon joka

00:17:26.530 --> 00:17:32.833
koostuu elliptisten käyrien 
salausmenetelmästä sekä yhdestä

00:17:32.833 --> 00:17:36.597
kvantti-jälkeisestä ehotuksesta. Sitä ei
käytetä oletuksena mutta jos lisäät rivin

00:17:36.597 --> 00:17:39.900
palvelimen sekä asiakasohjelman 
konfiguraatioon niin se käyttää kvantti-

00:17:39.900 --> 00:17:45.071
jälkeistä salausta, ja jos kvantti-jälkeinen
osa murretaan niin siellä on silti vielä ECC

00:17:45.071 --> 00:17:51.737
Heinäkuussa 2019 Google ja Cloudflare 
kokeilivat kvantti-jälkeistä salausta

00:17:51.737 --> 00:17:59.196
kaksiosaisessa kokeessa. Jotkin käyttäjät
salasivat toisella versiolla, ntruhrss:lla

00:17:59.196 --> 00:18:02.784
ja ECC:llä totta kai, käytä aina 
sekamuotoja. Ja toinen versio oli

00:18:02.784 --> 00:18:08.659
salaaminen sikep:llä ja ECC:llä. Joo 
Tanja sanoi hups. Tämä on esimerkki siitä

00:18:08.659 --> 00:18:15.268
miten tärkeää on varmistaa että yhdistät
kaiken ECC:n kanssa jotta et kadota

00:18:15.268 --> 00:18:19.338
turvallisuutta verrattuna tähän päivään
jossa kaikki käytämme ECC:tä. Kokeile

00:18:19.338 --> 00:18:24.259
kvantti-jälkeisiä järjestelmiä sekä ECC:tä
samaan aikaan jotta pahimmassa tapauksessa

00:18:24.259 --> 00:18:29.266
hukkaat vain aikaa mutta toivottavasti 
jokin paranee ja ainakin sikep käyttäjillä

00:18:29.266 --> 00:18:38.740
on ECC turva. Myös vuonna 2019 lokakuussa 
Google väitti omaavansa kvanttiylemmyyden

00:18:38.740 --> 00:18:44.186
tarkoittaen että heillä oli kvanttitietokone
tekemässä jotain nopeammin kuin mikään

00:18:44.186 --> 00:18:49.152
tavallinen supertietokone. Se ei ole 
hyödyllinen laskenta ja menee silti vuosia

00:18:49.152 --> 00:18:52.507
ennen kuin meillä on hyödyllisiä laskelmia
pyörimässä kvanttitietokoneilla nopeammin

00:18:52.507 --> 00:18:56.486
kuin tavallisilla tietokoneilla mutta silti
pelkästään nimi kvanttiylemmyys on

00:18:56.486 --> 00:19:00.112
harhaanjohtava mutta se silti 
mielenkiintoinen askel eteenpäin kvantti-

00:19:00.112 --> 00:19:06.908
laskennassa ja nimi varmaankin herätti
huomiota sekä huolta

00:19:06.908 --> 00:19:17.988
vuonna 2021 ja 2022 OpenSSH, OpenBSD ja Google
kaikki päivittivät yhtäkkiä

00:19:17.988 --> 00:19:27.677
no, openSSH versio 9.0 tarjoaa sntrup:n ja 
ECC:n oletuksena joten jos sinulla on

00:19:27.677 --> 00:19:31.423
OpenSSH 9 asennettuna palvelimellesi sekä 
siihen palvelimeen mihin otat yhteyttä

00:19:31.423 --> 00:19:36.403
sekä asiakasohjelmaasi niin se käyttää 
automaattisesti kvantti-jälkeistä vaihtoehtoa

00:19:36.403 --> 00:19:42.391
ja itse asiassa OpenSSH versiot aina 8.5 asti
tukevat täysin samaa asiaa, mutta silloin

00:19:42.391 --> 00:19:46.917
sinun täytyy ottaa se käyttöön manuaalisesti
jotta palvelin ja asiakasohjelma käyttäisivät

00:19:46.917 --> 00:19:50.989
sitä mutta OpenSSH 9:ssä se tapahtuu
oletuksena ja sama juttu Googlen suhteen

00:19:50.989 --> 00:19:55.916
he ovat marraskuusta, eli viime kuusta 
lähtien salanneet heidän sisäisen

00:19:55.916 --> 00:20:03.778
kommunikaationsa ntruhrss:llä ja ECC:llä
joten toivottavasti ntruhrss toimii ja se

00:20:03.778 --> 00:20:06.777
on turvallinen kvanttitietokoneita vastaan
tulevaisuudessa

00:20:06.777 --> 00:20:11.382
Tämä on myös hienosti linjassa 
puhdistamiskoodin sanoman kanssa

00:20:11.382 --> 00:20:16.670
kuten jo sanottu puhdistamiskoodit eivät 
ole vielä stardardisoituja kryptografisiin

00:20:16.670 --> 00:20:22.265
järjestelmiin itsessään mutta he kannustavat
ihmisiä tutkimaan asioita ja totuttelemaan

00:20:22.265 --> 00:20:31.280
siihen, esimerkiksi US ANSI joka on pankki-
standardi NTX9, totesivat että he siirtyvät

00:20:31.280 --> 00:20:35.889
aikanaan kvantti-jälkeisiin stardardeihin 
joten he odottavat klassisen kryptografian

00:20:35.889 --> 00:20:38.461
jota kutsutaan kvanttia edeltäväksi 
kryptografiaksi ja kvantti-jälkeinen

00:20:38.461 --> 00:20:43.130
kryptografian samanaikaista käyttöä
joten he ajattelevat että yksi asia on

00:20:43.130 --> 00:20:49.048
standardisoitu ja auditoitu ja toinen on 
silti vielä vähän uusi ja epämukava mutta

00:20:49.048 --> 00:20:52.956
me tarvitsemme sitä pitkän ajan 
turvallisuutta varten ja ehkä se vaativat

00:20:52.956 --> 00:20:59.559
tätä sekamuoto yhdistelmää pitkässä
juoksussa. Sitten, Yhdysvalloista Ranskaan

00:20:59.559 --> 00:21:07.139
eli ANSI:sta ANSSI:n, joka on Ranskan
turvallisuusvirasto. He sanovat myös että

00:21:07.139 --> 00:21:14.596
älkää käyttäkö kvantti-jälkeisiä järjestelmiä
yksinään koska ne ovat vielä kypsymättömiä

00:21:14.596 --> 00:21:19.122
mutta, kypsymättömyys ei tarvitse olla syy
ensimmäisten käyttöönottojen viivyttämiselle

00:21:19.122 --> 00:21:27.495
joten ANSSI kannustaa ihmisiä ottamaan
sekamuodot käyttöön käyttäen jotain hyvää

00:21:27.495 --> 00:21:32.102
kvanttia edeltävää ratkaisua yhdessä 
kvantti-jälkseisen ratkaisun kanssa

00:21:32.102 --> 00:21:36.988
Noniin kiva eli kaikki etenee hienosti 
niiden linjausten mukaan mitkä olivat Tanjan

00:21:36.988 --> 00:21:42.816
dioissa vuonna 2016. Standardisaatio 
etenee hitaasti mutta saman aikaan

00:21:42.816 --> 00:21:47.052
olemme ottamassa käyttöön kvantti-jälkeistä
salausta yhdessä ECC:n kanssa siltä varalta

00:21:47.052 --> 00:21:51.769
jos jokin menee pieleen ja saada käyttäjät
suojatuksi niin nopeasti kuin mahdollista

00:21:51.769 --> 00:21:59.295
Mitä Yhdysvaltojen hallinto sanoi tästä? 
Vuodesta 2021 lähtien Yhdysvaltojen hallinto

00:21:59.295 --> 00:22:02.917
teki erittäin selväksi että se haluaa sinun
nyt saatat miettiä että he haluavat sinun

00:22:02.917 --> 00:22:07.350
suojatuvan kvanttitietokoneita vastaan mutta
eijei ei, he eivät halua että suojaudut

00:22:07.350 --> 00:22:14.126
kvanttitietokoneita vastaan. Esimerkiksi, 
tässä on sitaatti NIST:n

00:22:14.126 --> 00:22:17.601
kyberturvallisuusosaston päälliköltä
informaatioteknologian laboratoriosta

00:22:17.601 --> 00:22:20.943
joka käynnisti kvantti-jälkeisen krypto-
järjestelmien kilpailutuksen.

00:22:20.943 --> 00:22:27.469
Heinäkuussa 2021, pian OpenBSD:n projektien
ja OpenSSH:n käyttöönottojen jälkeen

00:22:27.469 --> 00:22:32.382
hän sanoi, älkää antako ihmisten ostaa ja 
jalkauttaa epästandardisoituja kvantti-

00:22:32.382 --> 00:22:39.156
jälkeisiä kryptografioita. Ja sitten, toinen
esimerkki, NSA, joka toimii läheisesti

00:22:39.156 --> 00:22:44.314
NIST:n kanssa sanoi, älä toteuta tai käytä 
epästandardisoituja kvantti-jälkeisiä krypto-

00:22:44.314 --> 00:22:49.120
grafioita. Ja siltä varalta ettei ihmiset
tajunneet viestiä, turvallisuusvirasto,

00:22:49.120 --> 00:22:51.930
luuletko että nämä virastot keskustelevat
keskenään?

00:22:51.930 --> 00:22:57.345
turvallisuusvirasto sanoi, älä käytä kvantti-
jälkeisiä kryptografiatuotteita ennen kuin

00:22:57.345 --> 00:23:02.593
korvattavien ohjelmien standardisaatio, 
toteutus ja testaus hyväksytyillä

00:23:02.593 --> 00:23:05.487
algoritmeilla on tehty NIST:n toimesta.

00:23:05.487 --> 00:23:15.608
Tässä jo hieman huonoja uutisia. Toinen 
juttu mikä on outoa tässä on että he sanovat

00:23:15.608 --> 00:23:19.122
että jos olet ottamassa käyttöön kvantti-
jälkeistä kryptografiaa, niin sinun ei tule

00:23:19.122 --> 00:23:24.131
käyttää sekamuotoja, ja saatat ehkä ajatella
ymmärsinkö väärin ein kyllänä tai jotain

00:23:24.131 --> 00:23:29.956
tässä oli NSA:n kaveri konferenssissa ja 
tämä dia on Markku Saarisen kuvankaappaus

00:23:29.956 --> 00:23:35.701
mutta olin tilaisuudessa ja voin vahvistaa
että hän totesi että sinun ei tulisi käyttää

00:23:35.701 --> 00:23:44.512
sekamuotoja. Hän myös toisti useasti että 
älä käytä mitään tällä hetkellä. He eivät

00:23:44.512 --> 00:23:48.767
myöskään odottaneet kvantti-jälkeisten 
algoritmien hyväksymistä minkään

00:23:48.767 --> 00:23:52.642
"varmuuden vuoksi yhdistä algoritmit"
ohjeiden pohjalta.

00:23:52.642 --> 00:23:58.510
Myöhemmin he julkaisivat lisää ohjeita jossa
sanottiin että se tulee olemaan kahdenkeskinen

00:23:58.510 --> 00:24:03.167
korvike, ECC ja RSA irti, kvantti-
jälkeinen kryptografia sisään.

00:24:03.167 --> 00:24:08.823
ja heidän argumenttinsa oli että ECC:ssä
voi olla ohjelmointivirheitä joten sammuta

00:24:08.823 --> 00:24:15.635
ECC. Ei hyvä idea. Ellet ole hyökkääjä 
silloin se on huippuidea.

00:24:15.635 --> 00:24:21.828
nyt ehkä ajattelet että totta kai me käytämme
sekamuotoja vaikka NSA kannustaa ihmisiä

00:24:21.828 --> 00:24:29.207
olemaan käyttämättä niitä, ja sitten tämä 
lause, älä käytä jotain epästandardisoitua

00:24:29.207 --> 00:24:35.880
se lykkäys on nyt korjattu, vai mitä? NIST 
kertoi heinäkuussa Kyberin standardisoinnista

00:24:35.880 --> 00:24:43.460
ja se tarkoittaa, ota Kyber käyttöön. 
noh, ei, oikeastaan he eivät sano niin

00:24:43.460 --> 00:24:49.524
Tarkastellaanpa yksityiskohtia. Ensinnäkin
muistatteko Googlen patenttiongelman NH:n

00:24:49.524 --> 00:24:58.691
kanssa? No, NH:n poika on nimeltään Kyber.
He kai sekoittivat Star Trekin

00:24:58.691 --> 00:25:01.950
ja Tähtien Sodan keskenään joten 
sisäisesti heidän huhuttiin nimeävän

00:25:01.950 --> 00:25:07.822
Kyberin New Hope the Next Generation 
mutta sitten he keksivät paremman nimen

00:25:07.822 --> 00:25:11.398
sille myöhemmin. mutta joka tapauksessa 
Kyber muistuttaa paljon NH:ta sillä sillä

00:25:11.398 --> 00:25:15.841
on patenttiongelmia ja tämä on ainoa
salausjärjestelmä, NIST valitsi SPHINCS+:n

00:25:15.841 --> 00:25:20.245
ja valitsi kaksi muuta 
allekirjoitusmahdollisuutta ja valitsi yhden

00:25:20.245 --> 00:25:24.492
salausmenetelän, Kyberin. Se on ainoa tapa
datasi turvaamiseksi NIST:n valitsemien

00:25:24.492 --> 00:25:32.464
standardien mukaan. Kyber in NH:n tavoin 
keskellä seitsemän eri patentin miinakenttää

00:25:32.464 --> 00:25:36.745
Se ei tarkoita että kaikki seitsemän pätevät
se on varsin monimutkainen asia. Kun

00:25:36.745 --> 00:25:40.409
tarkastelet patenttia sinun täytyy ymmärtää
miten patenttilaki toimii ja analysoida mitä

00:25:40.409 --> 00:25:47.535
patentti tarkoittaa tärkeysjärjestyksen ja
laajentamisen näkökulmasta. Se on monimutkaista

00:25:47.535 --> 00:25:51.490
Yksi helppo tapa päästä eroon patenteista
on ostaa ne ja antaa ne jakoon ilmaiseksi

00:25:51.490 --> 00:25:56.173
Niinpä NIST sanoi heinäkuussa neuvottelevansa
useiden kolmansien osapuolten kanssa

00:25:56.173 --> 00:25:59.028
heidän mukaan liittymisestä useisiin 
sopimuksiin jotta mahdolliset haasteet

00:25:59.028 --> 00:26:04.128
liityen patentteihin voitaisiin välttää.
Ok, hyvä, nyt voidaan käyttää Kyberiä

00:26:04.128 --> 00:26:09.277
Paitsi että, yritykset katsovat tätä ja 
sanovat että hei voitteko näyttää sopimukset

00:26:09.277 --> 00:26:12.819
jotta me tiedämme mitä kaikkea 
allekirjoititte. Esimerkiksi Scott Fluhrer

00:26:12.819 --> 00:26:17.258
Ciscolta sanoi, Cisco ei voi käyttää Kyberiä
ennen kuin me saamme lisenssien tekstit

00:26:17.258 --> 00:26:26.385
No, sittenpä kävi ilmi että NIST ei ollut 
allekirjoittanut mitään heinäkuussa mutta

00:26:26.385 --> 00:26:31.029
he sanoivat että he aikovat ja marraskuussa
he viimein sanoivat, kyllä, me olemme

00:26:31.029 --> 00:26:36.140
allekirjoittaneet kaksi lisenssisopimusta
ja tässä hieman tekstiä niistä lisensseistä

00:26:36.140 --> 00:26:43.390
Mutta jos katsot katsot tekstiä, niin 
lisenssit ovat NIST:n kuvaamalle standardille

00:26:43.390 --> 00:26:49.124
ja minkäänlaisten muokkausten käyttö tai 
minkään muun kuin NIST:n standardisoitujen

00:26:49.124 --> 00:26:54.524
asioiden käyttö Kyberissä ei ole sallittua 
tämän lisenssin mukaan

00:26:54.524 --> 00:27:00.467
Nyt ehkä ajattelet että no he valitsivat
Kyberin, he standardisoivat sen heinäkuussa

00:27:00.467 --> 00:27:04.937
mutta ei, he eivät tehneet niin. Mitä he
sanoivat heinäkuussa oli että he

00:27:04.937 --> 00:27:10.288
suunnittelevat Kyberin standardisoimista 
mikä ei ole sama asia kuin että Kyber olisi

00:27:10.288 --> 00:27:17.796
standardisoitu. He suunnittelevat Kyberin 
standardoinnin olevan valmis vuonna 2024

00:27:17.796 --> 00:27:24.361
Ja tilannetta pahentaa se että me emme tiedä
minkälainen Kyber tulee olemaan vuonna 2024

00:27:24.361 --> 00:27:31.721
koska he vieläkin ehdottavat muutoksia siihen
Eli, yhteenvetona, vuonna 2024, jos he

00:27:31.721 --> 00:27:37.669
tuolloin julkistavat standardin, niin 
lisenssi antaa sinun käyttää Kyberiä

00:27:37.669 --> 00:27:45.424
ja ehkä vuonna 2023 he vakiintavat Kyberin
ja ehkä ne viisi muuta patenttia eivät

00:27:45.424 --> 00:27:50.973
vaikuta Kyberiin. On olemassa tapauksia 
joissa ihmiset ovat kävelleet miinakentän

00:27:50.973 --> 00:27:53.999
läpi räjähtämättä.

00:27:54.466 --> 00:27:59.564
Tämä tuo meidät puuhemme loppuun, me selitimme
tarpeeksi viivästyksistä ja kiertoteistä

00:27:59.564 --> 00:28:05.379
mutta, mitä tarkoitamme katastrofilla? 
Totta kai jos jokin menee rikki joka on

00:28:05.379 --> 00:28:10.363
otettu käyttöön Googlen ja Cloudflaren
kokeilussa, niin kyllähän se on katastrofi

00:28:10.363 --> 00:28:14.681
mutta he käyttivät varasuunnitelmaa, he 
käyttivät sekamuotoa joten se on ok

00:28:14.681 --> 00:28:19.776
Mikä oikeasti on katastrofi on se että 
olemme täällä vuonna 2022 ja meillä

00:28:19.776 --> 00:28:24.298
ei vieläkään ole käytössä kvantti-jälkeistä
kryptografiaa puhelimissa tai tietokoneissa

00:28:24.298 --> 00:28:27.715
se ei ole vieläkään laajasti käyttöön otettua
Voimme ilomielin osoittaa esimerkkejä joissa

00:28:27.715 --> 00:28:32.980
sitä käytetään mutta sitä ei käytetä laajasti
Datasi on edelleen kvanttia edeltävillä

00:28:32.980 --> 00:28:37.787
algoritmeilla salattua ja siksi mahdollista
purkaa kvanttitietokoneella. Se on se oikea

00:28:37.787 --> 00:28:41.698
katastrofi. Kiitos huomiostanne!

00:28:45.893 --> 00:28:47.106
Kiitos, kiitos

00:28:47.106 --> 00:28:53.288
<i>Epäselvää</i>

00:28:53.288 --> 00:28:57.076
tai teknologia mitä käytän taustalla 
käyttävät kvantti-jälkeistä kryptografiaa

00:28:57.076 --> 00:29:02.001
luulen että minun SSH yhteys käyttää 
vähintään, joten on se varmaan jotain

00:29:02.001 --> 00:29:09.982
voimme aina luottaa OpenBSD:n.
Ehdottomasti.

00:29:09.982 --> 00:29:20.747
Tarkistetaan onko kysymyksiä. Yksi kysymys
Kehittäjänä, joka kehittää jotain

00:29:20.747 --> 00:29:24.884
sovellusta, ei välttämättä kryptografista,
varmistanko että käyttämäni salaus on

00:29:24.884 --> 00:29:29.375
turvallinen kvantti-jälkeiseen aikaan
käyttämällä sekamuotoa nyt?

00:29:29.375 --> 00:29:35.835
Hei, sinullahan on dia juuri tätä varten!
Näytä dia!

00:29:35.835 --> 00:29:41.175
Me ennustimme joitain kysymyksiä kuten, no
tämä oli aika masentava mitä voimme tehdä

00:29:41.175 --> 00:29:46.677
nyt joten meillä on dia valmiina ratkaisu-
keinoista joita voit käyttää nyt ja kyllä

00:29:46.677 --> 00:29:53.224
meidän ehdotus on että käyttäkää sekamuotoja
Tunnen kuin tämä olisi takautuma vuoteen 2016

00:29:53.224 --> 00:29:57.264
milloin sanoin hei voit tehdä jotain juuri
nyt tässä ovat meidän ehdotuksemme

00:29:57.264 --> 00:30:02.150
jotka ovat mielestämme todella turvallisia
ja silti täällä olen joulukuussa vuonna 2022

00:30:02.150 --> 00:30:07.568
sanomassa että McEliecen on todella varovainen
järjestelmä ja meillä ei ole samaa patentti

00:30:07.568 --> 00:30:13.425
ongelmaa jota Kyber menee tällä hetkellä 
läpi. Mitä sekamuoto tarkoittaa?

00:30:13.425 --> 00:30:17.036
Se tarkoittaa kvanttia edeltävän ja kvantti-
jälkeisen järjestelmän yhdistämistä

00:30:17.036 --> 00:30:23.720
Salauksessa haluat niiden yhdessä luovan 
avaimen ja julkisen avaimen allekirjoituksessa

00:30:23.720 --> 00:30:26.735
haluat tietysti varmistaa että molemmat
allekirjoitukset yksinään ovat päteviä

00:30:26.735 --> 00:30:35.115
jotta sekamuotoinen allekirjoitus toimii
On olemassa useita eri ohjelmistokirjastoja

00:30:35.115 --> 00:30:39.263
joita voit tarkastella ja saada siten 
laajempaa kuvaa eri järjestelmistä

00:30:39.263 --> 00:30:43.495
joita voit yrittää ottaa käyttöön. Kun 
katsot kirjastoja niin sovelluksien laatu

00:30:43.495 --> 00:30:49.106
ei ole niin huono kuin se oli pari vuotta
sitten kvantti-jälkeisille sovelluksille

00:30:49.106 --> 00:30:55.134
Ihmiset käyttävät paljon aikaa näiden 
parantamiseen. Siellä on silti paljon riskejä

00:30:55.134 --> 00:31:02.334
mutta riski verrattuna siihen ettei tee mitään
ja siten varmistamalla että data on

00:31:02.334 --> 00:31:05.233
tulevaisuudessa suojaton tulevaisuuden 
hyökkääjiä vastaan jotka käyttävät

00:31:05.233 --> 00:31:07.998
kvanttitietokoneita ja jotka tallentavat 
dataa juuri nyt niin haluat todellakin

00:31:07.998 --> 00:31:13.069
kokeilla eri asioita. Esimerkiksi yksi kirjasto 
joka on toteuttanut pari eri järjestelmää

00:31:13.069 --> 00:31:18.587
on nimeltään Quantum safe oqs. On olemassa
muita kirjastoja jotka käyttävät tiettyjä

00:31:18.587 --> 00:31:21.794
salausjärjestelmiä joten useimmilla 
järjestelmäsuunnittelijoilla on jonkinlainen

00:31:21.794 --> 00:31:25.384
sovellus mutta jälleen kerran sinun täytyy
miettiä kuinka hyvä sovelluksen laatu on

00:31:25.384 --> 00:31:34.913
Uusi kirjasto on tulossa nimeltään lib.js 
jolla on useita verifikaatteja, joten sanoisin

00:31:34.913 --> 00:31:40.219
että se on hyvänlaatuinen mutta valitettavasti
ainoa kvantti-jälkeinen salausjärjestelmä

00:31:40.219 --> 00:31:44.135
jota se tarjoaa tällä hetkellä on Kyber,
joka on no, jos suunnittelet eteenpäin

00:31:44.135 --> 00:31:49.055
vuoteen 2024 jolloin se tulee käyttöön mutta
juuri nyt se ei ole käyttökelpoinen

00:31:49.055 --> 00:31:57.852
Joten jos haluat jotain joka on nopea, 
niin jos katsot mitä OpenSSH tai Google

00:31:57.852 --> 00:32:03.422
tekevät ntruhrss:lla joten se sovellus 
on ainakin jotenkin testattu

00:32:03.422 --> 00:32:07.940
joten voit kokeilla sitä mutta muista
aina käyttää sekamuotoja ECC:n kanssa

00:32:07.940 --> 00:32:11.303
varmuuden vuoksi jos jokin sattuukin
menemään pahasti pieleen kvantti-jälkeisen

00:32:11.303 --> 00:32:13.520
osan kanssa.

00:32:14.441 --> 00:32:20.807
Eikö ole kuitenkin aika hankalaa luoda oma
yhdistäjä? Minulla pitää silti olla oikea tapa

00:32:20.807 --> 00:32:24.348
yhdistää kaksi järjestelmää, kvanttia 
edeltävä ja kvantti-jälkeinen

00:32:24.348 --> 00:32:31.269
Kyllä ja se on mahdollista, joten jopa niin
yksinkertainen juttu kuin allekirjoita

00:32:31.269 --> 00:32:34.411
tällä järjestelmällä, allekirjoita toisella
järjestelmällä, tarkista molemmat

00:32:34.411 --> 00:32:38.165
allekirjoitukset. Me olemme nähneet 
sovelluksia joissa tämä on mennyt väärin

00:32:38.165 --> 00:32:46.650
On todella tärkeää käydä se läpi
varovaisesti. Salaamiseen sinulla yleensä

00:32:46.650 --> 00:32:51.499
on ECC joka vaihtaa avaimen ja sitten sinun
kvantti-jälkeinen järjestelmä vaihtaa avaimen

00:32:51.499 --> 00:32:57.691
ja tiivistät molemmat avaimet yhteen suosikki-
tiivistefunktiollasi. Standardisoitu

00:32:57.691 --> 00:33:02.227
tiivistefunktio on hyvä. Mutta jälleen kerran,
mainitsit yhdistämisen, on olemassa useita

00:33:02.227 --> 00:33:02.723
tutkimuksia

00:33:02.723 --> 00:33:04.920
<i>epäselvää</i>

00:33:05.325 --> 00:33:06.885
Anteeksi, sanotko uudestaan?

00:33:07.188 --> 00:33:11.515
Standardi tarkoittaa kryptografista tiiviste-
funktiota. Älä käytä jotain XX-tiivistettä

00:33:11.515 --> 00:33:13.549
vaan käytä jotain joka on kryptografista.

00:33:13.549 --> 00:33:21.281
Kyllä, eli esimerkiksi SHA-512 joka on 
NSA:n suunnittelema mutta ihmiset ovat

00:33:21.281 --> 00:33:25.927
lyöneet sitä jo pitkän aikaa rikkomatta
sitä. Jotain mikä on käynyt läpi julkista

00:33:25.927 --> 00:33:32.402
arviota, on SHA-3 järjestelmät ja yleensä
se ei ole suorituskykyongelma tiivistää

00:33:32.402 --> 00:33:36.917
kaksi 32 tavuista merkkijonoa yhteen, 
ketjuta ja tiivistä ne ja sinulla on

00:33:36.917 --> 00:33:41.242
uusi merkkijono joka on sinun symmetrisen
kryptografian avain

00:33:41.242 --> 00:33:50.617
On olemassa ehdotuksia miten tehdä tämä
esimerkiksi IRTF:n tai tarkemmin CFRG:n RFC

00:33:50.617 --> 00:33:55.376
sitten on jotain NIST:n stardardeissa 
liittyen sekamuotojen käyttöön

00:33:55.376 --> 00:34:00.743
lopuksi hieman itsemainontaa, meillä on
yksi dia jonka julkaisemme ja siellä on

00:34:00.743 --> 00:34:07.880
joitain alustavia tutkimuksia joissa käymme
läpi yksityiskohtaisemmin sekamuotojen

00:34:07.880 --> 00:34:12.405
käyttöönottoa ja yhdistämistä. Eli miten voit
turvallisesti tehdä tämän. Tieysti on

00:34:12.405 --> 00:34:21.202
asentamisen valinta, eli valitset sinun oman
järjestelmäsi, ja kuten näet niin on huolia

00:34:21.202 --> 00:34:26.822
mallitilanteen suhteen, lisäksi mainitsen 
kokeilututkimuksia varten voit käyttää Skypeä

00:34:26.822 --> 00:34:29.593
se on vain ongelma silloin jos haluat 
ottaa sen käyttöön

00:34:29.593 --> 00:34:35.231
yleinen varoitus on mutta jos olet vain 
harrastelija tai haluat tökkiä sitä tai

00:34:35.231 --> 00:34:37.844
haluat kirjoittaa tutkimuksen aiheesta 
niin se ei ole ongelma

00:34:37.844 --> 00:34:42.777
mutta yleisesti sinulla on valinta tehokkaiden
järjestelmien kuten mitä Google on tehnyt

00:34:42.777 --> 00:34:47.697
kokeilemalla jotain uutta ja katsomalla 
räjähtääkö se meidän tietokoneillamme

00:34:47.697 --> 00:34:52.842
onneksemme se ei räjähtänyt, joten Google
pystyi jatkamaan sen käyttöä yhdistämällä

00:34:52.842 --> 00:34:59.802
NH:n tai myöhemmin NTRU:n ja ECC:n
tai sitten voit sanoa että tärkeintä on se

00:34:59.802 --> 00:35:05.453
että järjestelmä pysyy turvassa, ja olemme
valmiita uhraamaan hieman nopeutta ja kaistaa

00:35:05.453 --> 00:35:09.033
joten ottamalla kaikkein varovaisimmat
kvantti-jälkeiset järjestelmät ja yhdistamällä

00:35:09.033 --> 00:35:13.554
ne ECC:n tai RSA:n kanssa. Se on myös
valinta jonka joudut tekemään

00:35:13.554 --> 00:35:16.158
jos haluat ottaa sen käyttöön

00:35:19.112 --> 00:35:25.729
Eli olisiko ok ottaa käyttöön salakirjoitus-
järjestelmä joka on vielä mukana kilpailussa

00:35:25.729 --> 00:35:29.530
joka ei ole vielä tai jota ei tulla 
standardisoimaan NIST:n toimesta?

00:35:29.530 --> 00:35:34.305
Vaikka ei olisi tiedossa olevia hyökkäyksiä?
No, yleisesti, kun katsot tällaista kuvaa

00:35:34.305 --> 00:35:46.597
jossa on niin paljon punaista niin sinä 
mahdat ajatella ettemme me kryptograafikot

00:35:46.597 --> 00:35:51.319
tiedä mitä me teemme. Miten meillä voi olla
niin moni asia rikki? Se on todella todella

00:35:51.319 --> 00:35:59.797
vaarallista. Sanoisin että sillä onko jokin
NIST:n valitsema vai ei ei lisää paljoa

00:35:59.797 --> 00:36:03.503
informaatiota tässä. Ok haluat kommentoida
tähän.

00:36:03.503 --> 00:36:08.063
Haluan mainita että asiat jotka pudotettiin
ensimmäisellä kierroksella eivät saaneet

00:36:08.063 --> 00:36:12.581
paljoa huomiota. Ihmiset menettivät 
kiinnostuksensa. Asiat jotka selvisivät

00:36:12.581 --> 00:36:15.461
kolmannelle kierrokselle ja sitten eivät
selvinneet neljännelle kierrokselle

00:36:15.461 --> 00:36:20.111
esimerkiksi kaksi Android muunnelmaa,
NTRU Prime ja NTRU-HRSS-KEM jotka ovat

00:36:20.111 --> 00:36:27.037
mainittuina tässä, ne pääsivät kolmannelle
kierrokselle mutta eivät voittaneet kauneus-

00:36:27.037 --> 00:36:31.017
kilpailua jota NIST pyöritti. Luulen että
ne ovat aivan yhtä hyviä kuin ne jotka

00:36:31.017 --> 00:36:33.533
ovat tässä kuvassa sinisellä.

00:36:33.533 --> 00:36:41.503
Yleisesti kaikki tässä ovat pelottavia. 
Eli NTRU ja NTRU-HRSS ovat Googlen

00:36:41.530 --> 00:36:47.917
käyttöönottamia ja OpenSSH mutta todella 
harva näistä 69:stä ehdotuksesta omaa

00:36:47.917 --> 00:36:52.268
samaa turvallisuustasoa nyt tiedettyjä 
hyökkäyksiä vastaan kuin mitä niillä oli

00:36:52.278 --> 00:36:58.192
viisi vuotta sitten kun ne ensin toimitettiin
Turvallisuutta ollaan aina menetetty koska

00:36:58.192 --> 00:37:03.168
hyökkäykset ovat kehittyneet paremmiksi
jollain oli turvallisuusmarginaalia niistä

00:37:03.168 --> 00:37:11.219
selviytymiseen. Tehdäksesi turvallisen 
päätöksen sinun valitettavasti täytyy

00:37:11.219 --> 00:37:15.701
tutustua näiden historiaan ja kysyä kuinka
hyvin nämä ovat kestäneet kuinka hyvin

00:37:15.701 --> 00:37:19.709
näitä on tutkittu. Mitä Tanja korosti oli
se että joitain näistä on tutkittu todella

00:37:19.709 --> 00:37:25.410
vähän ja joitain hieman enemmän, ja se 
kuinka hyvin nämä järjestelmät kestivät

00:37:25.410 --> 00:37:28.838
tutkimuksen aikana määrittelee sen kuinka
vaarallisia ne ovat loppujen lopuksi

00:37:28.838 --> 00:37:33.977
Esimerkiksi Three Bears on kaunis 
järjestelmä mutta se pudotettiin toisen

00:37:33.977 --> 00:37:37.920
kierroksen jälkeen ja sen jälkeen ihmiset 
lopettivat sen tutkimisen eikä se saanut

00:37:37.920 --> 00:37:44.485
paljoa analyysia. Tuntuu siltä että se on
hyvä mutta sitä ei ole toisaalta tutkittu

00:37:44.485 --> 00:37:48.601
melkein yhtään. Mutta jos tarkastelet 
kolmannen kierroksen valikoimaa jotka ovat

00:37:48.601 --> 00:37:53.327
mustia tai harmaita tässä sanoisin että 
ne ovat suurimmaksi osaksi ok.

00:37:53.327 --> 00:37:58.593
Ja tietysti siniset.

00:37:58.593 --> 00:38:04.201
Ok eli valitse se joka on joko sininen tai
musta dialla. Luulen että ne ovat varsin

00:38:04.201 --> 00:38:11.000
tiettyjä asioita. Nopea viimeinen kysymys 
jos olen tinapaperihattu, voinko tehdä

00:38:11.000 --> 00:38:13.606
jotain oman kommunikaationi suojaamiseksi?

00:38:13.606 --> 00:38:24.257
Käytä kaikki OpenSSH:n läpi, se on hyvä 
alku. Tilanne on se että tietysti tarvitset

00:38:24.257 --> 00:38:28.449
asiakasohjelman sekä palvelimen 
jotka tukevat asioita ja on olemassa

00:38:28.449 --> 00:38:31.578
useita kokeiluja mutta vain vähäistä
käyttöönottoa

00:38:31.578 --> 00:38:40.297
on olemassa VPN:n käyttöönottoa esimerkiksi 
Joo on olemassa kvantti-jälkeistä VPN:ä

00:38:40.297 --> 00:38:47.906
Movadilla on kvantti-jälkeinen vaihtoehto,
he käyttävät McElieceä, he käyttävät

00:38:47.906 --> 00:38:52.948
WireGuardia VPN:ä varten ja WireGuardilla 
on vaihtoehto ylimääräisen avaimen

00:38:52.948 --> 00:38:57.888
syöttämiseksi, ennalta jaettu avain jota 
movad käyttää McEliecen kanssa eli lataat

00:38:57.888 --> 00:39:01.200
sen McEliecen läpi kvantti-jälkeisen 
turvan saamiseksi movadiin

00:39:01.200 --> 00:39:07.793
Tämä on siis VPN jossa et mene päästä 
toiseen, haluat yleensä mennä koko tien

00:39:07.793 --> 00:39:11.315
siihen sivustoon johon otat yhteyttä, ja 
jos sinulla on päästä päähän turva käytössä

00:39:11.315 --> 00:39:14.629
se tarkoittaa että asiakasohjelmiston ja 
palvelimen pitää tukea kvantti-jälkeistä

00:39:14.629 --> 00:39:19.643
kryptografiaa ja kun se on nyt viivästynyt
niin se ei ole niin yleisesti käytössä kuin

00:39:19.643 --> 00:39:23.440
olisin kuvitellut sen olevan vuosia sitten
kun sitä kohtaan tuntui olevan paljon

00:39:23.440 --> 00:39:25.033
innostusta

00:39:25.033 --> 00:39:27.137
<i>epäselvää</i>

00:39:27.137 --> 00:39:34.646
Ok Tanja haluaa että kerron PQ Connectista,
tulossa pian joka toivottavasti helpottaa

00:39:34.646 --> 00:39:38.023
kvantti-jälkeisen kryptografian 
käyttöönottoa yhteytesi turvaamiseksi

00:39:38.023 --> 00:39:43.035
päästä päähän mutta sitä ei ole julkaistu
vielä joten en voi sanoa paljoa siitä

00:39:43.035 --> 00:39:50.086
odotan innolla PQ Connectia. Luulisin että
tämä oli tässä, kiitos että olitte täällä

00:39:50.086 --> 00:39:54.585
ja jaoitte tietojanne jaoitte päivityksiä
liityen kvantti-jälkeiseen kryptografiaan

00:39:54.585 --> 00:39:58.991
Kiitos todella paljon Tanja Lange 
ja D.J.B!

00:39:58.991 --> 00:40:01.071
Kiitos!

00:40:02.501 --> 00:40:12.290
[Translated by Timo Broström 
(KYBS2004 course assignment at JYU.FI)]