diff --git a/git-obzornik.tex b/git-obzornik.tex
index d9c4aac..5736845 100644
--- a/git-obzornik.tex
+++ b/git-obzornik.tex
@@ -130,14 +130,14 @@ zgoščevalne funkcije \(H(b)\) pravimo \emph{zgostitev} vsebine \(b\)
 vsebine. Kaj pa če imata dve različni vsebini isto zgostitev? Funkcija
 \(H\) ni injektivna, saj je množica nizov, bistveno večja od množice
 zgostitev. To pomeni, da imata lahko dve različni datoteki enako
-zgostitev. Če se to zgodi, rečemo, da pride do \emph{kolizije
-zgostitve}. V primeru kolizije zgostitve bi Git shranil le eno datoteko,
+zgostitev. Če se to zgodi, rečemo, da pride do \emph{trka
+zgostitve}. V primeru trka zgostitve bi Git shranil le eno datoteko,
 za drugo pa bi predpostavil da je že shranjena. Zato je funkcija \(H\)
 izbrana tako, da sprememba enega samega bita v besedilu \(b \in B\)
 spremeni vrednost \(H(b)\) in je porazdelitev vrednosti \(H(b)\) čim
 bližje enakomerni porazdelitvi. To pomeni, da so vse vrednosti \(H(b)\)
-približno enako verjetne. Na ta način zmanjšamo verjetnost kolizije(
-glej \hyperref[sec_kolizije]{{[}sec\_kolizije{]}}). Verjetnost kolizije
+približno enako verjetne. Na ta način zmanjšamo verjetnost trka(
+glej \hyperref[sec_trk]{{[}sec\_trk{]}}). Verjetnost trka
 je izjemno majhna, zato Git lahko predpostavi, da je niz \(b\) enolično
 določen z njegovo zgostitvijo \(H(b)\).
 
@@ -279,8 +279,8 @@ objekta določena z njegovo zgostitvijo. To pomeni, da lahko enostavno
 preverimo verodostojnost vsebine, ki je shranjena v Gitu. Git hrani
 skladišče objektov v mapi \texttt{.git/objects}.
 
-\section{Kolizije zgostitev in rojstnodnevni
-paradoks}\label{sec_kolizije}
+\section{Trki zgostitev in rojstnodnevni
+paradoks}\label{sec_trk}
 
 Git hrani datoteke pod imeni, ki so enaka zgostitvi vsebine. Če imata
 dve datoteki z različno vsebino isto zgostitev, Git shrani le eno
@@ -288,7 +288,7 @@ datoteko in pride do izgubil podatkov. Git se zanaša na to, da je
 verjetnost za to izjemno majhna. Kako bi ocenili to verjetnost?
 
 Koliko datotek bi morali shraniti v Git, da bi z znatno verjetnostjo
-prišlo do kolizije? Vprašanje je povezano z rojstnodnevnim problemom.
+prišlo do trka? Vprašanje je povezano z rojstnodnevnim problemom.
 Kako velika naj bo skupina ljudi, da bo vsaj \(50\%\) verjetnost, da
 imata dve osebi na isti dan rojstni dan? Velikost skupine je
 presenetljivo majhna(23), zato rojstnodnevnei problem imenujemo tudi
@@ -312,7 +312,7 @@ Za vrednosti \(1 \ll n \ll h\) je \(1 - e^{- \frac{n^{2}}{2h}}\) tudi
 dobra aproksimacija za \(p(n,h)\).
 
 Da bi odgovorili kako odporna je zgoščevalna funkcija na morebitne
-kolizije, moramo rešiti obratno nalogo: največ koliko števil \(n(p,d)\)
+trka, moramo rešiti obratno nalogo: največ koliko števil \(n(p,d)\)
 lahko izberemo, da bo verjetnost pojava dveh enakih števil manjša od
 \(p \in \lbrack 0,1\rbrack\)? Natančen odgovor na to vprašanje ni tako
 preprost \cite{brink_probably_2012}. Lahko pa uporabimo oceno
@@ -328,10 +328,10 @@ Funkcija \(\sqrt{\log(\frac{1}{1 - p})}\) zelo počasi narašča, ko se
 \(p\) približuje \(1\), zato jo lahko zanemarimo. Če je zgoščevalna
 funkcija \(160\) bitna, kot na primer SHA1, je
 \(n \approx \sqrt{2^{160}} \approx 2^{80}\). Znatna verjetnost, da pride
-do kolizije zgostitev, bi se pojavila, ko bi shranili \(2^{80}\)
+do trka zgostitev, bi se pojavila, ko bi shranili \(2^{80}\)
 različnih verzij datotek v Git. Raziskovalci, ki so razvili napad
 \emph{SHAttered}, so se posebej potrudili in so potrebovali ``zgolj''
-približno \(2^{63}\) primerov, da so prišli do kolizije.
+približno \(2^{63}\) primerov, da so prišli do trka.
 
 \section{Zgodovinski graf sprememb}
 
diff --git a/git-obzornik.typ b/git-obzornik.typ
index 81277e6..69d0cb7 100644
--- a/git-obzornik.typ
+++ b/git-obzornik.typ
@@ -83,8 +83,8 @@ $
   H: B -> {0, 1, dots, 2^(n)-1},
 $
 ki vsakemu besedilu $b$ priredi $n$-bitno vrednost $H(b)$. Vrednosti zgoščevalne funkcije $H(b)$ pravimo _zgostitev_ vsebine $b$ (angl. hash).
-Git hrani datoteke pod imeni, ki so enaka zgostitvi vsebine. Kaj pa če imata dve različni vsebini isto zgostitev? Funkcija $H$ ni injektivna, saj je množica nizov, bistveno večja od množice zgostitev. To pomeni, da imata lahko dve različni datoteki enako zgostitev. Če se to zgodi, rečemo, da pride do _kolizije zgostitve_. V primeru kolizije zgostitve bi Git shranil le eno datoteko, za drugo pa bi predpostavil da je že shranjena. Zato je funkcija $H$ izbrana tako, da
-sprememba enega samega bita v besedilu $b in B$ spremeni vrednost $H(b)$ in je porazdelitev vrednosti $H(b)$ čim bližje enakomerni porazdelitvi. To pomeni, da so vse vrednosti $H(b)$ približno enako verjetne. Na ta način zmanjšamo verjetnost kolizije( glej @sec_kolizije). Verjetnost kolizije je izjemno majhna, zato Git lahko predpostavi, da je niz $b$ enolično določen z njegovo zgostitvijo $H(b)$.
+Git hrani datoteke pod imeni, ki so enaka zgostitvi vsebine. Kaj pa če imata dve različni vsebini isto zgostitev? Funkcija $H$ ni injektivna, saj je množica nizov, bistveno večja od množice zgostitev. To pomeni, da imata lahko dve različni datoteki enako zgostitev. Če se to zgodi, rečemo, da pride do _trka zgostitve_. V primeru trka zgostitve bi Git shranil le eno datoteko, za drugo pa bi predpostavil da je že shranjena. Zato je funkcija $H$ izbrana tako, da
+sprememba enega samega bita v besedilu $b in B$ spremeni vrednost $H(b)$ in je porazdelitev vrednosti $H(b)$ čim bližje enakomerni porazdelitvi. To pomeni, da so vse vrednosti $H(b)$ približno enako verjetne. Na ta način zmanjšamo verjetnost trka( glej @sec_trk). Verjetnost trk je izjemno majhna, zato Git lahko predpostavi, da je niz $b$ enolično določen z njegovo zgostitvijo $H(b)$.
 
 Git uporablja $160$ bitno zgoščevalno funkcijo _SHA1_. Funkcija SHA1 je posebna implementacija zgoščevalne funkcije, ki se je uporabljala v kriptografiji#footnote[Leta 2017 so raziskovalci
   iz CWI Amsterdam in Google Research našli prvi praktični primer dveh različnih pdf datotek, ki imata isto SHA1 zgostitev#cite(<stevens_first_2017>). Opisan napad so poimenovali _SHAttered_. Git je zato z verzijo `v2.13.0`
@@ -152,13 +152,13 @@ vsebina objekta določena z njegovo zgostitvijo. To pomeni, da lahko enostavno p
 
 ]
 
-== Kolizije zgostitev in rojstnodnevni paradoks <sec_kolizije>
+== trk zgostitev in rojstnodnevni paradoks <sec_trk>
 
 Git hrani datoteke pod imeni, ki so enaka zgostitvi vsebine. Če imata dve datoteki z različno vsebino
 isto zgostitev, Git shrani le eno datoteko in pride do izgubil podatkov. Git se zanaša na to, da je verjetnost za to izjemno majhna.
 Kako bi ocenili to verjetnost?
 
-Koliko datotek bi morali shraniti v Git, da bi z znatno verjetnostjo prišlo do kolizije? Vprašanje je povezano z rojstnodnevnim problemom. Kako velika naj bo skupina ljudi,
+Koliko datotek bi morali shraniti v Git, da bi z znatno verjetnostjo prišlo do trk? Vprašanje je povezano z rojstnodnevnim problemom. Kako velika naj bo skupina ljudi,
 da bo vsaj $50%$ verjetnost, da imata dve osebi na isti dan rojstni dan? Velikost skupine je presenetljivo majhna(23), zato rojstnodnevnei problem imenujemo tudi rojstnodnevni paradoks. Vprašanje zastavimo matematično. Naključno izberemo $n<d$ števil iz množice ${1, 2, dots, h}$, tako da je vsaka izbira enakomerno porazdeljena. Kolikšna je verjetnost $p(n, h)$, da bosta vsaj dve števili enaki? Verjetnost $p(n, h)$ izračunamo elementarno z verjetnostjo nasprotnega dogodka:
 
 $
@@ -177,15 +177,15 @@ $
 $<eq_ocena>
 Za vrednosti $1 << n << h$ je $1- e^(-n^2/(2h))$ tudi dobra aproksimacija za $p(n, h)$.
 
-Da bi odgovorili kako odporna je zgoščevalna funkcija na morebitne kolizije, moramo rešiti obratno nalogo: največ koliko števil $n(p, d)$ lahko izberemo, da bo verjetnost pojava dveh enakih števil manjša od $p in [0,1]$? Natančen odgovor na to vprašanje ni tako preprost #cite(<brink_probably_2012>). Lahko pa uporabimo oceno (@eq_ocena) in čez palec ocenimo vrednost $n(p, h)$:
+Da bi odgovorili kako odporna je zgoščevalna funkcija na morebitne trke, moramo rešiti obratno nalogo: največ koliko števil $n(p, d)$ lahko izberemo, da bo verjetnost pojava dveh enakih števil manjša od $p in [0,1]$? Natančen odgovor na to vprašanje ni tako preprost #cite(<brink_probably_2012>). Lahko pa uporabimo oceno (@eq_ocena) in čez palec ocenimo vrednost $n(p, h)$:
 
 $
   -n^2 approx log(1-p) =>\ n(p, h) approx sqrt(2h log(1/(1-p))) approx sqrt(2h).
 $
 
 Funkcija $sqrt(log(1/(1-p)))$ zelo počasi narašča, ko se $p$ približuje $1$, zato jo lahko zanemarimo. Če je zgoščevalna funkcija $160$ bitna, kot na primer SHA1, je
-$n approx sqrt(2^(160)) approx 2^(80)$. Znatna verjetnost, da pride do kolizije zgostitev, bi se pojavila, ko bi shranili $2^(80)$ različnih verzij datotek v Git.
-Raziskovalci, ki so razvili napad _SHAttered_, so se posebej potrudili in so potrebovali "zgolj" približno $2^(63)$ primerov, da so prišli do kolizije.
+$n approx sqrt(2^(160)) approx 2^(80)$. Znatna verjetnost, da pride do trka zgostitev, bi se pojavila, ko bi shranili $2^(80)$ različnih verzij datotek v Git.
+Raziskovalci, ki so razvili napad _SHAttered_, so se posebej potrudili in so potrebovali "zgolj" približno $2^(63)$ primerov, da so prišli do trka.
 
 = Zgodovinski graf sprememb