Complete disk encryption 2

Posted by Kiril Kirov Sun, 05 Oct 2008 08:00:00 GMT

Преди време бях писал нещичко по темата как можем да останем анонимни в Интернет, не политически, а технически. Потребителите, които наистина ги е страх от ДАНС (или пък третата световна война, това си е параноя до голяма степен), е необходимо да предприемат още една стъпка за своята сигурност. Представете си, че въпреки използването сигурни на мерки за анонимност, преследващата ви институция разбере за вашата самоличност, по някакъв друг начин. Рискът да ви набият естествено нараства значително, но има и един друг риск. Ако искат да ви съдят – ще им трябват някакви доказателства. За целта обикновено в дома ви ще пристигнат една банда качулати сладури с пушки, автомати, бронирани джипове и незнам още какво. Те най-вероятно ще отмъкнат всичките ви компютри със себе си, надявайки се от там да извадят повече информация за вашата дейност. Естествено ако данните ви са на диска в чист вид, и още повече ако ползвате 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: 305245MB  at ata2-master SATA300
ad6: 305245MB  at ata3-master SATA300
На тях имаме пуснат софтуерен RAID1 (mirror). Върху него имаме крипто драйвера, използваме AES-CBC 128 за шифър (това е по подразбиране, мисля че няма нужда от 256).
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
След като тръгне операционната система се пускат следните 5 kernel threads. Първата е за работа с RAID масива, другите са за работа с криптографията съответно на четирите процесорни ядра.
   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

Posted by Kiril Kirov Tue, 22 Jul 2008 11:31:00 GMT

Вчера си купих 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.

Имотен регистър

Posted by Kiril Kirov Fri, 20 Jun 2008 17:36:00 GMT

След “бонбонките” в ДАИ и мислещите компютри в Паспортна служба се сблъсках със следващата голяма, типично българска простотия. Тя е един от многото типични примери как държавата нарушава собствените си закони. “Агенция по Вписванията” е направила някакъв “Имотен регистър”, който можело да се ползва от физически лица през Интернет. До тук добре, обаче има подробности:

Значи за да ползвам “електронната” услуга на Агенцията, трябва да отида на крак до банката. Там трябва да платя 4 лева, 2 лева за Агенцията и 2 лева банкова такса за превод. Трябва да взема хартииката от банката, че съм внесъл парите и да отида до Служба по вписванията. Там трябва да подам молба и да покажа, че наистина съм платил 2 лева на Агенцията. После трябва да се прибера и да изпратя един email за да ми бъде пусната услугата.

Аз от няколко месеца съм горд собственик на “Универсален Електронен Подпис”. В закона пише, че този подпис има същата тежест каквато и ръчен подпис върху хартия. Нормално е да искам да подам въпросната молба с електронен подпис и да преведа парите през Интернет банкиране. Попитах “поддръжката” на Агенцията мога ли да направя това. Отговор не получих. Всъшност ако бях получил, това щеше да ми е първия отговор на email получен от държавна институция. Неотговорените писма са поне 10, пращани до различни институции в различни периоди от време. Очевидно думичката “универсален” в името на този подпис има за цел да прикрие, че той всъшност за нищо не става. Разбира се, това не пречи Информационно Обслужване АД да ми прибира нереално високи годишни такси без да прави нищо в замяна. Като стана дума за “електронни подписи” стигаме и до следващата глупост на този сайт. Ето как изглежда сертификата на Имотен регистър:

Обобщавам за хората, които не разбират от криптография. Някой си, който нарича себе си “chronos” гарантира, че сайта с който работим действително е на Агенция по Вписванията и не е фалшив. Тази гаранция важи за периода от 11.4.2005 до 11.4.2007. Разбира се, този сертификат е невалиден, незаконен и несигурен. Той е невалиден защото срокът му е изтекъл. Незаконен е, защото според закона за Електронния подпис, сертификатите държавните институции трябва да са подписани от лицензиран доставчик на удостоверителни услуги. Лицензиран доставчик с това име в България няма. Този сертификат е несигурен, защото всеки може да си направи такъв и да го представи за сайта на Агенцията, тоест да го фалшифицира. Очевидно на никой от въпросната агенция не му пука за тези неща. Значи за мен е задължително да си плащам и да ползвам услугите на лицензиран доставчик на удостоверителни услуги. Но за Агенцията по Вписванията не е задължително. Нали те са част от Министерство на Правосъдието, очевидно законите за тях не важат.

Скорост на OpenSSL

Posted by Kiril Kirov Sat, 10 May 2008 13:35:00 GMT

Като един стар потребител на 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

Posted by Kiril Kirov Sun, 30 Dec 2007 12:52:00 GMT

Тези дни реших да си потърся решение на проблема със SSH червейте. Много са досадни, защото ми пълнат логовете с опитите си за кракване на пароли. Така и не намерих готово разумно решение на проблема. За това си направих една PF таблица, където си добавям ръчно IP адресите, които ме сканират. Всякакъв опит за автоматично забраняване на IP адреси след неуспешни опити за влизане в системата създава елементарна възможност за DoS атака. Както си ровех логовете на една машина днес, намерих поредния червей, който прави опити да влиза. Ето извадка от auth.log:
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
Нищо необичайно, типичен SSH червей. Все пак реших да пусна един traceroute, да видя каква е тази машина и какво се каня да сложа в таблицата с нежелани гости. По принцип съм свикнал подобни машини да са някакви хакнати “dedicated servers”, или някакви глупави домашни потребители от западна европа. Проблемът идва от там, че на машините има потребителски достъп, като се използва слаба парола. Това може да бъде избегнато елементарно, като се използва криптографски ключ за автентикация. Този път се изненадах от машината, която е заразена.
[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
Мда, освен простотии, цигани, безработни и пенсионери явно от Министерството на труда и социалната политика се отглеждат и SSH червей. То червейчето само по себе си нищо лошо не прави. Като се има предвид, че при всяка една конекция се пресмята Diffie-Hellman handshake, най-много да гори малко повече ток тази машина. Ама какво от това, нали данъкоплатците го плащат. Чудя се дали тази машина не се използва и за нещо по-смислено от разпространение на червей, горене на ток и топлене на времето. Може би пък там има някоя интересна база данни с име и ЕГН на всеки безработен в България. От както е хакната може да има и някой огромен архив с детска порнография. В краен случай, при липса на въображение от страна на ползващите достъпа, може да има просто един spambot, който изпраща милиони писма на ден. Важното е, че там има безплатен достъп за всеки, който го пожелае. Друг интересен момент в историята с government.bg е, че човек по никакъв начин не може да се свърже с компютърно грамотен човек от там, който да отговаря за някакъв вид техническа поддръжка. Във всичките страници на министерства тази информация много старателно и стратегически не е публикувана. Преди време си загубих няколко дни да търся такъв човек, за един много подобен проблем с техни машини. Накрая пуснах едно любезно писмо до 4-5 техни адреса, но разбира се отговор не последва. Дори човек да има най-добри чуства и намерения, и да иска да им помогне да си оправят “лайната” без да се вдига шум, пак не може да го направи. Може би сега, предпразнично трябва да се обадя на някоя неграмотна журналистка, в някоя българска медия. Като и спомена за хакнат правителствен компютър и детска порнография веднага ще и светнат очичките за сензация. Ще изтипосат една първа страница с големи букви и купища технически неверни, измислени факти. Проблемът на този подход е, че тази сензация ще отмине, ще се забрави и от там нататък ще си караме по старо му. И така до следващия хакнат техен компютър. В случая предпочитам да не се занимавам, просто ще взема да се напия предпразнично за да забравя, че живея в тази държава.

Криптографски хеш за IBAN и Булстат 1

Posted by Kiril Kirov Fri, 30 Nov 2007 07:34:00 GMT

Винаги съм се чудил защо системата Bulstat е организирана по този начин. Това е един типичен пример за родната простотия и мърлявщина. От скоро в България въведоха системата IBAN и на мен започнаха да ми стават ясни някои неща. Двете системи са просто ужасни и те са направени такива абсолютно умишлено. Най-напред аз не мога да си представя кой здраво мислещ човек, сега или преди 30 години, би предложил представяне на числа с нули отпред. Защо една фирма да няма булстат “527”, а да има булстат “000000527”? По закон трябва цифрите да са 9, ами добре, направете ги 9, сложете една единица вместо първата нула и готово. Така няма да има опасност, някой служител, на някой компютър, някъде в страната, да направи съдбоносната грешка, да представи едно число, като число. Например в момента, ако аз си отворя един Excel и напиша един булстат в една клетка. Програмата Excel, и то с пълно право, ще ми “изяде” нулите, които стоят пред числото. Резултатът от това е пълна каша, защото булстат номерата могат да съдържат 9 или 13 цифри. Друга велика тъпотия е това, че на някакъв етап от време, към някакви булстат номера, по някакви причини, е била залепена някаква буква. Това не оставя никакъв друг избор на програмистите, освен да използват поле string, и то с променлива дължина, за пазене на Булстат. До тук възможните грешки са следните:

  1. Представяне на числото, като integer
  2. Представяне на числото, като няколко integer числа
  3. Представяне на числото, като string с недостатъчна (фиксирана) дължина

Всеки човек, който поне веднъж е работил с булстат номера на компютър е правил поне една от горните грешки. Блъскаме си главите, псуваме управляващите, а те през това време дописват следващата голяма глупост в “Законът за регистър Булстат”. Преди да видя системата IBAN бях сигурен, че това е само български феномен. Тогава ми стана ясно, че подобни глупости виреят и на други места. Системата IBAN е значително по-зле от Булстат, там плетеницата от значещи и не незначещи букви и цифри е просто умопомрачителна. Тези дни се нагледах на хора, които броят нули, разположени някъде към средата на IBAN номера. Запомнят бройката им, преписват ги и после ги пращат по SMS или факс, някъде си. Там някой друг прави същото – преписва същите тези неща от SMS или факс съобщението в компютъра си. След като и на мен ми се наложи да го направя няколко пъти реших да седна и да предложа очевидното решение на тези проблем. Защо трябва да индексираме, когато можем да хешираме? Сигурен съм, че много хора знаят за това решение, но то не се прилага по някакви политически или икономически причини. Аз колкото и да мислих по този въпрос не можах да стигна до тези причини. Ето как аз си представям задачата и решението:

Задачата и пред двете системи IBAN и Булстат е практически една и съща. Те трябва да съпоставят някакви уникални данни, на някакво уникално число. Част от тези данни могат да са лични, конфиденциални, секретни и т.н., но това не е от значение. Това което ни трябва е хеш (еднопосочна) функция. Даваме нашите данни на тази функция и тя ни произвежда номера. Ето един пример с първата криптографска хеш функция, която ми попадна:

MD5 ("BG, SF, FIB, Kiril Kirov, 821221xxxx") = 81efb5d44ab33f3a071998d1bd444492

Подадох на функцията един string, той съдържа моята държава, град, банка, име и ЕГН. Функцията ми даде един друг string и аз съм сигурен, че няма друг входен string, който да отговаря на този изходен. Ако си бях поиграл малко повече да избера някоя по-подходяща функция от MD5 щях да получа доста по-къс и приятен string. Ето предимствата на този подход:

  1. Изходът от функцията винаги е с фиксирана дължина
  2. Изходът от функцията лесно може да се представи, като integer или като string
  3. Изходът от функцията не е нужно да се помни, всеки може да си го произведе при услови, че разполага с функцията и с нейните входни данни

Трябва ви моят IBAN – няма проблем, напишете ми данните в компютъра си и ще го получите! От друга страна, ако не ви вярвам, аз мога да не ви давам данните си, просто ще ви дам изхода на функцията. Този подход може да се използва за всичко, физически лица, юридически лица, банкови сметки, лични данни и т.н. Държавата не трябва да ми пише в законите кой регистър с колко цифри да индексирам. Държавата трябва да ми каже кои данни и коя хеш функция да използвам. Ако е достатъчно добра хеш функцията, тя може да бъде една за всичко…