Complete disk encryption 2
Преди време бях писал нещичко по темата как можем да останем анонимни в Интернет, не политически, а технически. Потребителите, които наистина ги е страх от ДАНС (или пък третата световна война, това си е параноя до голяма степен), е необходимо да предприемат още една стъпка за своята сигурност. Представете си, че въпреки използването сигурни на мерки за анонимност, преследващата ви институция разбере за вашата самоличност, по някакъв друг начин. Рискът да ви набият естествено нараства значително, но има и един друг риск. Ако искат да ви съдят – ще им трябват някакви доказателства. За целта обикновено в дома ви ще пристигнат една банда качулати сладури с пушки, автомати, бронирани джипове и незнам още какво. Те най-вероятно ще отмъкнат всичките ви компютри със себе си, надявайки се от там да извадят повече информация за вашата дейност. Естествено ако данните ви са на диска в чист вид, и още повече ако ползвате Windows – в техни ръце ще се окаже един подробен журнал на целия ви живот. Разни неща, които си мислите, че сте унищожили (тоест изтрили) също ще са там. За да се заличат някакви данни от един хард диск е необходимо на тяхно място върху повърхността на диска да се запишат поне 20 пъти някакви други данни. Незнам колко хора знаят това в България, но то наистина е една важна подробност, когато човек е решил да се отърве от нещо. Решението на всички тези проблеми е едно – криптография. Да си криптирате отделни файлове или директории обикновено не върши работа, защото операционната система по време на работата си пази значително количество метаинформация, която може да издаде съдържанието на криптираните файлове. Представете си, че имате криптиран файл с много сложна парола, дори най-мощните суперкомпютри не могат да разбият криптографията…в следващите 20 години. Обаче операционната система е кеширала тази парола и е записала този кеш на диска. Неприятно, всички усилия отиват на вятъра. Ето защо всички разумни престъпници, революционери, журналисти, параноици и т.н. е добре да използват криптография на цялата си файлова система. Аз използвам такава от 3 години насам на 4-5 машини и вече имам някакъв опит по темата. Който иска да разбере повече по темата, както и как се имплементират тези неща с помощта на FreeBSD, GEOM и GBDE или GELI може да погледне ето тази статия. От практическа гледна точка идеята е проста – имате си един USB flash, пъхате го в компютъра, пускате компютъра, пишете една парола и компютъра тръгва. След това можете да го извадите, той ще ви трябва чак, когато решите да рестартирате компютъра. Практически никой без да има този флаш и без да знае тази парола не може да получи достъп до данните ви. Всъщност силата на цялата схема се крепи на тази парола – думата парола може би не е много точна. Добре е да имате за парола някакъв израз, а не просто една дума. На английски на това нещо му казват passphrase. Ако спазвате добре стъпките описани в статията, ще получите желания резултат – при кражба (изземване) на компютъра или хард диска, крадците няма да имат никаква представа какво има на него. Цялата ви информация ще е във вид на хубаво статистически разпределен шум. Ако са хитри ще разберат, че това е някаква криптография, но нито ще знаят каква, нито ще имат каквато и да било възможност да я разбият. Шансът да се получи информация е компютъра да се открадне работещ, което също далеч не е просто. Бях попаднал на една интересна статия, от преди няколко месеца, която илюстрираше успешна атака срещу тази схема с използване на течен азот за замразяване чиповете памет на компютъра, преди да бъде изключен. Естествено до сега няма регистриран нито един такъв случай в извън лабораторни условия. Друг начин да се разбие тази криптография е, като се използва подслушване на EMI. Това е много малко вероятно, защото за да ви подслушват по този начин е необходимо преди това да знаят, че използвате такава криптосистема. Ако имате EMI защитена електроника, разбира се, този проблем отпада. Лошото е, че няма от къде да се сдобиете с такава за цивилни нужди! Мисля, че за всякакви от горе изброените нужди, тази криптография е подходяща. Вероятността някаква институция в Бъгария да се справи с нея клони към 0, ако сме се справили добре с имплементацията.
Цялата схема си има и лоши страни, например достъпът до хард диска става с помощта на доста изчисления от страна на процесора, което го прави много бавен на по-стари компютри. За щастие на новите процесори, с повече ядра, това не е проблем. Последната ми такава инсталация работи с диска на нормалната му скорост, без никакво чуствително забавяне. Но все пак това е един много нов Quad-core Intel Xeon процесор с 8 Mb кеш.
Ето един пример за добра, според мен, Complete Disk Encryption схема:
Имаме 2 хард диска по 300 Gb
ad4: 305245MBat ata2-master SATA300 ad6: 305245MB at ata3-master SATA300
GEOM_MIRROR: Device mirror/data launched (2/2). GEOM_ELI: Device mirror/data.eli created. GEOM_ELI: Encryption: AES-CBC 128 GEOM_ELI: Crypto: software Trying to mount root from ufs:mirror/data.eli
52 ?? DL 0:25.91 [g_mirror data] 53 ?? DL 0:50.07 [g_eli[0] mirror/dat] 54 ?? DL 0:56.82 [g_eli[1] mirror/dat] 55 ?? DL 1:00.19 [g_eli[2] mirror/dat] 56 ?? DL 1:02.96 [g_eli[3] mirror/dat]
И така, ако някой утре задигне тази машина, аз бих спал спокойно. Сигурен съм, че няма да получи и един байт от информацията, която имам на дисковете. Използвайте тези неща, те са удобни и свободни за ползване. Мисля, че и в GNU/Linux има подобни решения, но не съм се интересувал от алтернативи – това ми върши много добра работа. На решения от Microsoft никога не бих разчитал, те не са имали и няма и да имат системи с подобно ниво на сигурност. Тук е мястото да отбележа и, че част от този софтуер е разработен по една програма, спонсорирана от американското правителство. Явно все пак и те са стигнали до извода, че за да бъде сигурна една подобна система – тя трябва да бъде с отворен код.
Файлови системи 1
Вчера си купих Seagate FreeAgent 500Gb External Hard Disk. Изключително тъпо име за хард диск, не знам как и защо са го измислили, но като изключим тази подробност – доволен съм от него. Идеята ми е да го ползвам, като backup диск, записвайки всички неща на него – сорс код, снимки, filesystem dumps. Освен това ще е много полезно да го разнасям насам-натам и да преписвам неща от разни клиентски компютри. За целта са необходми две важни неща. Първо – необходимо е всичко записано на диска да бъде криптирано. Второ – файловата система трябва да се чете на всякакви операционни системи. Както подозирах още преди да започна цялото упражнение, тези две простички неща не мога да бъдат постигнати с никакви стандартни средства.
Когато включих диска към лаптопа (Apple MacBook) стана ясно, че диска е форматиран с някакъв вид NTFS. Тази файлова система никога не е била стандартизирана. Как точно е правилно да се работи с нея знаят само в Microsoft. Мака може да го чете, но не може да пише по него. На диска имаше програма, която ми предлагаше да го конвертирам за Мак, тоест да го форматирам с HFS+. Това е една файлова система, която никога не е била стандартизирана. Как точно е правилно да се работи с нея знаят само в Apple. Windows XP няма стандартна възможност да чете HFS+. Всички open source операционни системи могат само да четат NTFS и HFS+. Някаква криптография се поддържа и в двете, но тя не върши работа за криптиране на целите файлови системи, става само за отделни файлове или директории. За криптиране на дялове може да се ползва TrueCrypt, като се създаде виртуален дял, като файл на диска. Оказа се обаче, че TrueCrypt предлага само FAT32, като файлова система в криптирания дял. Това очевидно няма как да стане за 500Gb диск, ако помня правилно максималния размер за FAT32 е 32Gb. Слагането на FAT32 дял върху диска, който може да се чете от всякъде е невъзможно по същата причина. Естествено съществуват доста глупави частични решения на проблема. Например няколко дяла за различните операционни системи, няколко дяла с FAT32, използване на TrueCrypt със скрити дялове и др. Тези неща ме накараха да се замисля – защо по дяволите няма отворена, стандартна файлова система за хард дискове, която да се чете навсякъде. Оптичните носители имат такава – ISO9660 с всичките й плюсове и минуси. Май минусите са й повече, но това за пореден път доказва, че е по-добре да има лош стандарт, от колкото никакъв.
Тъй като не ми се цепеше хард диска, нито ми се занимаваше с FAT32 или TrueCrypt. А глупавите и нестандартни NTFS и HFS+ въобще не са опция. Реших проблема с FreeBSD – GELI+UFS2. Сигурна файлова система – знам, че няма да имам проблеми с нея. Сигурна криптография – знам, че няма как да ми откраднат данните. Преносимостта на диска обаче си остана добро пожелание. Все пак се надявам да го накарам да работи на Мака, като накарам Parallels да предаде управлението на диска към FreeBSD във виртуална машина. За четене и писане от Windows машини и дума не може да става. Windows машините ще трябва да работят с хард диска по мрежата през FreeBSD.
Имотен регистър
След “бонбонките” в ДАИ и мислещите компютри в Паспортна служба се сблъсках със следващата голяма, типично българска простотия. Тя е един от многото типични примери как държавата нарушава собствените си закони. “Агенция по Вписванията” е направила някакъв “Имотен регистър”, който можело да се ползва от физически лица през Интернет. До тук добре, обаче има подробности:
File does not exist: .
Значи за да ползвам “електронната” услуга на Агенцията, трябва да отида на крак до банката. Там трябва да платя 4 лева, 2 лева за Агенцията и 2 лева банкова такса за превод. Трябва да взема хартииката от банката, че съм внесъл парите и да отида до Служба по вписванията. Там трябва да подам молба и да покажа, че наистина съм платил 2 лева на Агенцията. После трябва да се прибера и да изпратя един email за да ми бъде пусната услугата.
Аз от няколко месеца съм горд собственик на “Универсален Електронен Подпис”. В закона пише, че този подпис има същата тежест каквато и ръчен подпис върху хартия. Нормално е да искам да подам въпросната молба с електронен подпис и да преведа парите през Интернет банкиране. Попитах “поддръжката” на Агенцията мога ли да направя това. Отговор не получих. Всъшност ако бях получил, това щеше да ми е първия отговор на email получен от държавна институция. Неотговорените писма са поне 10, пращани до различни институции в различни периоди от време. Очевидно думичката “универсален” в името на този подпис има за цел да прикрие, че той всъшност за нищо не става. Разбира се, това не пречи Информационно Обслужване АД да ми прибира нереално високи годишни такси без да прави нищо в замяна. Като стана дума за “електронни подписи” стигаме и до следващата глупост на този сайт. Ето как изглежда сертификата на Имотен регистър:
File does not exist: .
Обобщавам за хората, които не разбират от криптография. Някой си, който нарича себе си “chronos” гарантира, че сайта с който работим действително е на Агенция по Вписванията и не е фалшив. Тази гаранция важи за периода от 11.4.2005 до 11.4.2007. Разбира се, този сертификат е невалиден, незаконен и несигурен. Той е невалиден защото срокът му е изтекъл. Незаконен е, защото според закона за Електронния подпис, сертификатите държавните институции трябва да са подписани от лицензиран доставчик на удостоверителни услуги. Лицензиран доставчик с това име в България няма. Този сертификат е несигурен, защото всеки може да си направи такъв и да го представи за сайта на Агенцията, тоест да го фалшифицира. Очевидно на никой от въпросната агенция не му пука за тези неща. Значи за мен е задължително да си плащам и да ползвам услугите на лицензиран доставчик на удостоверителни услуги. Но за Агенцията по Вписванията не е задължително. Нали те са част от Министерство на Правосъдието, очевидно законите за тях не важат.
Скорост на OpenSSL
Като един стар потребител на GBDE и GELI под FreeBSD, трябваше да реша дали да ползвам криптография на хард диска под Mac OS X. Такава опция се предлага под името FileVault, за съжаление не се предлага криптиране на всичко, а само на директорията на потребителя. Може би е по-добре от нищо, въпреки че този софтуер не е с отворен код, не е много ясно колко е сигурен и дали няма някакви задни вратички. Тъй като не съм ползвал GELI на новите Intel процесори реших да изпробвам скоростта на криптографията за да добия представа колко бързо биха се движили нещата на един MacBook. Резултатите определено ме изненадаха. Това е изхода от командата openssl speed на Intel Core 2 Duo T7500 @2.2 Ghz под Mac OS X:
OpenSSL 0.9.7l 28 Sep 2006
built on: Sun Sep 23 16:08:24 PDT 2007
options:bn(64,32) md2(int) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: cc -arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe -arch ppc -arch ppc64 -arch i386 -arch x86_64 -pipe -DOPENSSL_NO_IDEA -DFAR=
available timing options: TIMEB USE_TOD HZ=100 [sysconf value]
timing function used: getrusage
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md2 1552.85k 3271.94k 4524.06k 5004.22k 5164.34k
mdc2 4204.74k 4619.19k 4757.31k 4799.52k 4809.07k
md4 15855.41k 52902.28k 142198.50k 246969.80k 317057.24k
md5 14586.42k 49474.84k 135840.67k 240148.54k 310968.00k
hmac(md5) 23251.10k 67720.57k 162782.12k 248777.43k 295469.61k
sha1 13182.11k 38272.95k 84104.41k 120792.72k 138000.81k
rmd160 10561.06k 29464.19k 61316.10k 84022.98k 94703.13k
rc4 95640.12k 101646.10k 103312.30k 104252.21k 104393.09k
des cbc 16022.67k 16444.10k 16548.69k 16572.95k 16563.80k
des ede3 14062.49k 14317.53k 14461.25k 14502.85k 14512.43k
idea cbc 0.00 0.00 0.00 0.00 0.00
rc2 cbc 20614.51k 21266.65k 21172.40k 21248.60k 21301.63k
rc5-32/12 cbc 108723.99k 127935.88k 136458.55k 142723.90k 140491.69k
blowfish cbc 54604.80k 58116.54k 58851.96k 59112.73k 59182.62k
cast cbc 36548.64k 38542.89k 38942.15k 39032.53k 39075.71k
aes-128 cbc 42344.46k 43862.27k 44255.02k 44202.57k 44116.52k
aes-192 cbc 36427.04k 37333.01k 37566.63k 37475.22k 37503.20k
aes-256 cbc 31756.28k 32454.77k 32637.07k 32536.94k 32590.66k
sign verify sign/s verify/s
rsa 512 bits 0.001318s 0.000088s 758.8 11322.0
rsa 1024 bits 0.006495s 0.000284s 154.0 3523.2
rsa 2048 bits 0.038285s 0.000990s 26.1 1010.2
rsa 4096 bits 0.245003s 0.003464s 4.1 288.7
sign verify sign/s verify/s
dsa 512 bits 0.000852s 0.001004s 1173.1 996.4
dsa 1024 bits 0.002756s 0.003275s 362.9 305.4
dsa 2048 bits 0.009637s 0.011214s 103.8 89.2Изненадващото тук са флаговете, с които е компилирана OpenSSL библиотеката. Многото архитектури са необходими, защото формата е Mach-O Universal Binary, но защо по дяволите са им debugging symbols и оптимизация по размер на мен не ми е ясно. За да сравня скоростите пуснах същата команда под FreeBSD на подобен AMD процесор – Athlon 64 BE-2350 @2.1 Ghz. Ето резултатите:
OpenSSL 0.9.7e-p1 25 Oct 2004
built on: Tue Jan 15 23:14:00 UTC 2008
options:bn(64,64) md2(int) rc4(ptr,int) des(ptr,risc2,4,int) aes(partial) blowfish(idx)
compiler: cc
available timing options: USE_TOD HZ=128 [sysconf value]
timing function used: getrusage
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md2 1450.30k 3046.74k 4234.28k 4708.83k 4860.78k
mdc2 6157.28k 7144.84k 7452.65k 7531.02k 7556.85k
md4 16149.12k 52186.87k 138171.42k 232540.73k 290777.63k
md5 12785.97k 40424.24k 98705.48k 156653.62k 188383.28k
hmac(md5) 16880.80k 48613.17k 110836.90k 164453.99k 190657.17k
sha1 12315.62k 35868.05k 79622.37k 114612.21k 130918.83k
rmd160 10203.07k 26992.17k 55980.67k 76481.20k 85377.83k
rc4 159730.21k 167051.92k 172490.07k 173262.90k 173469.21k
des cbc 41227.53k 42887.93k 43608.70k 43793.49k 43847.37k
des ede3 16126.92k 16532.56k 16658.32k 16737.51k 16669.78k
idea cbc 0.00 0.00 0.00 0.00 0.00
rc2 cbc 22156.48k 22952.47k 22989.78k 23065.41k 22981.71k
rc5-32/12 cbc 97653.25k 106976.49k 109700.90k 110490.45k 110563.13k
blowfish cbc 72234.94k 77850.37k 78994.44k 79397.11k 79810.08k
cast cbc 55748.97k 58467.84k 59135.72k 59470.92k 59308.97k
aes-128 cbc 93595.45k 97407.40k 99297.23k 99676.31k 99890.51k
aes-192 cbc 83154.82k 86677.42k 88213.47k 88343.16k 88592.05k
aes-256 cbc 75277.20k 78369.54k 79912.43k 79991.79k 80222.88k
sign verify sign/s verify/s
rsa 512 bits 0.0003s 0.0000s 3800.2 44370.9
rsa 1024 bits 0.0008s 0.0001s 1254.2 19837.2
rsa 2048 bits 0.0042s 0.0001s 238.2 7371.1
rsa 4096 bits 0.0264s 0.0004s 37.9 2430.1
sign verify sign/s verify/s
dsa 512 bits 0.0002s 0.0002s 6090.2 5498.6
dsa 1024 bits 0.0004s 0.0005s 2614.9 2185.4
dsa 2048 bits 0.0011s 0.0014s 875.9 713.2Тук флагове за компилатора няма и архитектурата е само AMD64. Но разликите в скоростите са много големи. Казано накратко, вторите резултати показват около 2.5 пъти по-бърз AES, 8 пъти по-бърз DSA и RSA. Това е доста интересен факт, очаквах да има някакви разлики в скоростта, но не и толкова големи. Този факт може да се дължи на много неща, тъй като между двете машини има прекалено големи разлики в софтуера и хардуера. Дори OpenSSL версийте са различни. Мисля, че и паметите играят някаква роля в случая, лаптопа по традиция е с DDR2 667, a другата машина е с доста бърза DDR2 800. За сметка на това пък Core 2 има доста повече кеш. Глупаво е да се правят заключения за каквото и да било от тези резултати, не знам как биха се отразили и на скороста на FileVault. Публикувам ги тук просто, като интересен факт.
За government.bg, SSH червейте и детската порнография 2
Dec 18 05:04:05 router sshd[9123]: Invalid user fluffy from 212.122.184.250 Dec 18 05:04:05 router sshd[9125]: Invalid user admin from 212.122.184.250 Dec 18 05:04:05 router sshd[9127]: Invalid user test from 212.122.184.250 Dec 18 05:04:05 router sshd[9129]: Invalid user guest from 212.122.184.250 Dec 18 05:04:06 router sshd[9131]: Invalid user webmaster from 212.122.184.250 Dec 18 05:04:06 router sshd[9133]: Invalid user mysql from 212.122.184.250 Dec 18 05:04:06 router sshd[9135]: Invalid user oracle from 212.122.184.250 Dec 18 05:04:07 router sshd[9137]: Invalid user library from 212.122.184.250 Dec 18 05:04:07 router sshd[9139]: Invalid user info from 212.122.184.250 Dec 18 05:04:07 router sshd[9141]: Invalid user shell from 212.122.184.250 Dec 18 05:04:08 router sshd[9143]: Invalid user linux from 212.122.184.250 Dec 18 05:04:08 router sshd[9145]: Invalid user unix from 212.122.184.250 Dec 18 05:04:08 router sshd[9147]: Invalid user webadmin from 212.122.184.250 Dec 18 05:04:09 router sshd[9149]: Invalid user ftp from 212.122.184.250
[root@router ~]# traceroute 212.122.184.250 traceroute to 212.122.184.250 (212.122.184.250), 64 hops max, 52 byte packets 1 192.168.1.1 (192.168.1.1) 1.112 ms 1.046 ms 1.803 ms 2 Virtual-ADSL.btc-net.bg (212.39.70.100) 7.874 ms 7.398 ms 7.347 ms 3 212-39-87-78.btc-net.bg (212.39.87.78) 6.727 ms 6.858 ms 7.085 ms 4 82-66.btc-net.bg (212.39.66.82) 6.685 ms 7.397 ms 7.097 ms 5 spnet2mc.spnet.net (212.50.10.122) 7.230 ms 7.547 ms 7.657 ms 6 mc2spnet.spnet.net (212.50.10.121) 7.645 ms 7.667 ms 7.394 ms 7 host217-161.mlsp.government.bg (212.122.161.217) 7.670 ms 8.015 ms 8.102 ms 8 ef.mlsp.government.bg (212.122.184.250) 8.469 ms 8.483 ms 8.261 ms
Криптографски хеш за IBAN и Булстат 1
Винаги съм се чудил защо системата Bulstat е организирана по този начин. Това е един типичен пример за родната простотия и мърлявщина. От скоро в България въведоха системата IBAN и на мен започнаха да ми стават ясни някои неща. Двете системи са просто ужасни и те са направени такива абсолютно умишлено. Най-напред аз не мога да си представя кой здраво мислещ човек, сега или преди 30 години, би предложил представяне на числа с нули отпред. Защо една фирма да няма булстат “527”, а да има булстат “000000527”? По закон трябва цифрите да са 9, ами добре, направете ги 9, сложете една единица вместо първата нула и готово. Така няма да има опасност, някой служител, на някой компютър, някъде в страната, да направи съдбоносната грешка, да представи едно число, като число. Например в момента, ако аз си отворя един Excel и напиша един булстат в една клетка. Програмата Excel, и то с пълно право, ще ми “изяде” нулите, които стоят пред числото. Резултатът от това е пълна каша, защото булстат номерата могат да съдържат 9 или 13 цифри. Друга велика тъпотия е това, че на някакъв етап от време, към някакви булстат номера, по някакви причини, е била залепена някаква буква. Това не оставя никакъв друг избор на програмистите, освен да използват поле string, и то с променлива дължина, за пазене на Булстат. До тук възможните грешки са следните:
- Представяне на числото, като integer
- Представяне на числото, като няколко integer числа
- Представяне на числото, като string с недостатъчна (фиксирана) дължина
Всеки човек, който поне веднъж е работил с булстат номера на компютър е правил поне една от горните грешки. Блъскаме си главите, псуваме управляващите, а те през това време дописват следващата голяма глупост в “Законът за регистър Булстат”. Преди да видя системата IBAN бях сигурен, че това е само български феномен. Тогава ми стана ясно, че подобни глупости виреят и на други места. Системата IBAN е значително по-зле от Булстат, там плетеницата от значещи и не незначещи букви и цифри е просто умопомрачителна. Тези дни се нагледах на хора, които броят нули, разположени някъде към средата на IBAN номера. Запомнят бройката им, преписват ги и после ги пращат по SMS или факс, някъде си. Там някой друг прави същото – преписва същите тези неща от SMS или факс съобщението в компютъра си. След като и на мен ми се наложи да го направя няколко пъти реших да седна и да предложа очевидното решение на тези проблем. Защо трябва да индексираме, когато можем да хешираме? Сигурен съм, че много хора знаят за това решение, но то не се прилага по някакви политически или икономически причини. Аз колкото и да мислих по този въпрос не можах да стигна до тези причини. Ето как аз си представям задачата и решението:
Задачата и пред двете системи IBAN и Булстат е практически една и съща. Те трябва да съпоставят някакви уникални данни, на някакво уникално число. Част от тези данни могат да са лични, конфиденциални, секретни и т.н., но това не е от значение. Това което ни трябва е хеш (еднопосочна) функция. Даваме нашите данни на тази функция и тя ни произвежда номера. Ето един пример с първата криптографска хеш функция, която ми попадна:
MD5 ("BG, SF, FIB, Kiril Kirov, 821221xxxx") = 81efb5d44ab33f3a071998d1bd444492Подадох на функцията един string, той съдържа моята държава, град, банка, име и ЕГН. Функцията ми даде един друг string и аз съм сигурен, че няма друг входен string, който да отговаря на този изходен. Ако си бях поиграл малко повече да избера някоя по-подходяща функция от MD5 щях да получа доста по-къс и приятен string. Ето предимствата на този подход:
- Изходът от функцията винаги е с фиксирана дължина
- Изходът от функцията лесно може да се представи, като integer или като string
- Изходът от функцията не е нужно да се помни, всеки може да си го произведе при услови, че разполага с функцията и с нейните входни данни
Трябва ви моят IBAN – няма проблем, напишете ми данните в компютъра си и ще го получите! От друга страна, ако не ви вярвам, аз мога да не ви давам данните си, просто ще ви дам изхода на функцията. Този подход може да се използва за всичко, физически лица, юридически лица, банкови сметки, лични данни и т.н. Държавата не трябва да ми пише в законите кой регистър с колко цифри да индексирам. Държавата трябва да ми каже кои данни и коя хеш функция да използвам. Ако е достатъчно добра хеш функцията, тя може да бъде една за всичко…
