All posts by Anonymous

Някои идеи за електронното гласуване

Post Syndicated from Anonymous original http://delian.blogspot.com/2015/09/blog-post_24.html

Чета постоянно истерия от представители или почитатели на партии с твърд пенсионерски електорат или партии разчитащи на по малко грамотни граждани срещу електронното гласуване, как то нямало да бъде сигурно.



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



За мен технологичните дискусии на този етап са преждевременни. Те са еквивалентни на дискусиите – дайте да нямаме гласуване въобще, защото може да се подправя. По добре ли ще ни е с един неподправен цар или дикатура на партията? 🙂 Няма съществена разлика в тезите. И вероятно за това царските движения и почитатели на диктатурата на партии, са основните противници на електронното гласуване.



Това не значи, че бягам от обсъждане на технологии. Това ми е страст. В този текст, искам да опиша един процедурен модел, как може да бъде реализирано електронно гласуване сигурно и анонимно. Това не е предложение как да бъде реализирано. Нито твърдение, че ще бъде реализирано точно така. Това е само илюстрация, че може. Технологичната дискусия е въпрос за обсъждане след като бъде взето решение да има електронно гласуване. Там трябва да сме внимателни, за да няма издънки от държавата. Но същевременно, не можем да смятаме, че държавата цели или съществува само за да прави издънки, защото иначе какъв е смисъла от нея? Най добре да дойде друг цар и господар, който да ни управлява нали? Ах, да, рязясних още една от тезите на противниците 🙂



Всъщност няма значение дали говорим за електронно или хартиено, присъствено или дистанционно гласуване, всяко нещо може да бъде реализирано сигурно или несигурно, като основният момент в него никога не е технологията по същество, а алгоритъма – процедурата използвана за реализацията.



В този смисъл нека за момент да не говорим за технология. Нека говорим за процедури-процедура.
И аз нямам за цел, да кажа, че дадена процедура за дистанционно гласуване гарантира абсолютна сигурност. Аз искам само да отбележа, че във всеки един момент, тя е винаги по-добра и по-сигурна отколкото моментната процедура за присъствено гласуване.



Изискванията към гласуването, без значение дали е присъствено или дистанционно, са да бъде лично, тайно, и гарантирано (тоест да не може да се подмени вота).



Тук не става въпрос за електронно гласуване или не. Можем да имаме електронно безприсъствено гласуване и електронно присъствено (което се експериментира от години при вотовете у нас, наричано машинно гласуване, заради помощ от машина), технологията е от не особено съществено значение. Основният въпрос е в процедурите за прилагане (включително и на технология).



Процедурата, която коментирам, е приложима за присъствено и безприсъствено гласуване, машинно или с бюлетини. Подобна процедура вече се разработва и в подходяща законодателна форма от друга група ентусиасти, но основните идеи (макар и да изказвам различно някой специфични детайли) са същите.



При присъственото гласуване, “личното” се гарантира типично чрез механизмите за аутентикация предвидени за личната карта. Ако снимката ти отговаря на личната карта, и ти имаш доверие на картата и издателят и, то ти приемаш (но няма абсолютна гаранция), че лицето е това, за което се представя и идва да гласува лично.



Тайната на вота се гарантира от безименни бюлетини и от гласуване в (макар и) обществена стая, такава в която трети страни твърдят, че е сигурно, че няма никой друг (но няма абсолютна гаранция).



Сигурноста на вота трябва да се гарантира от това, че няма как друга бюлетина да е влязла в урната, освен такава от гласуващи. Бюлетината не може пък да се подмени, защото е пазена зорко, от хора, които се предполага, че са врагове и ще се дебнат един друг (изборната комисия съставена от представители на различни партии).



Ние добре знаем обаче, че над 1 на 10000 лични карти са фалшифицирани.
Знаем, за мъртвите души – хора, които имат право да гласуват, и са в списъците за гласоподаватели, но са починали, и се използват за да се позволи да има останали свободни бюлетини добавяни в последният момент в урните, без това да създава подозрения при централното преброяване, тъй като броят на бюлетините е под или около очакваната бройка.
Само сега, за тези избори са премахнати над 500000 мъртви души (заради правилото за уседналост), но това не са всички, и ни дават чудесен индикатор колко неточни са всъщност изборните списъци. На по-предни избори бяха премахнати други 700000. Но постоянната урбанизация (при местните избори има изискване за уседналост), емиграция, динамика на смъртността, създават естествен процес на проява на мъртви души, тъй като списъците по места, физически няма как да са идеално актуални (макар централно да има как).


Знаем, че някой хора гласуват едновременно на две различни физически места, и поради невъзможност при присъственото гласуване да се подсигури в реално време национална проверка дали вече си гласувал или не, гласът се приема, а поради невъзможност за валидация на бюлетината по произход, не може да се премахнат двойни гласувания и следователно въпреки, че знаем за нарушението, то остава в преброеният резултат и какво ли още не.


Нещо повече, на някой места местни картели от представители в ИК си добавят бюлетини в последният момент, и дори да са преброени много над подписалите се, че са гласували, тъй като няма как да се разбере, кои са истински и кои не са, се броят всички и участват в преброяването. Общо, грешките (невалидни, дублирани бюлетини, мъртви души) плават между 5 и 15% на изборите и обикновено нямат съществено значение по отношение на цялостният изборен резултат. Но имат съществено значение при преразпределението на локалните мандати и при местните избори, където често един мандат (заради фрагментацията) или кмет се избират с по малко от 5000 гласа. Тези грешки, както и ниската избирателна активност имат значение и за партиите, които влизат в парламента или получават субсидия. За пример, на предните парламентарни избори само 50000 гласа по голяма изборна активност (под 1% от всички имащи право на глас) деляха дали АБВ и АТАКА ще влязат в парламента или не. Даже, нямаше значение за кого са гласували тези хора, тъй като става въпрос за фрагментацията от разпределението на мандати. Само ниска избирателна активност. Дали това е една от причините и двете партии да са твърди противници на всякакви методики за повишаване на изборната активност (от реклами, през задължително гласуване, до против електронното гласуване, всъщност АБВ официално е за електронно гласуване, но негови представители се изказват публично против) не знам.


Всички тези дефекти, и други, са породени от това, че няма въведен механизъм за двустранна валидация.
Ние знаем за тях от години, коментират се на всички избори, и постоянно променяме изборният кодекс така че да атакуваме един или друг проблем, до момента не особено ефективно.



Състемата за сигурност на присъственото гласуване разчита прекоменрно много на заплахи (глоби), политически присъствени изборни комисии (които ще се следят едни други поради естествената политическа конкуренция), и изборни наблюдатели за защита. Но с години, постепенно се съкращава количеството хора и партии имащи право да присъстват в изборна комисия, до парламентарно представени или до коалиционно партниращи си субекти, и така започват да се толерират естествени картелни съглашения, които отслабват значително присъственият контрол. Отделно независимите изборните наблюдатели се съкращават (сложна процедура за регистрация, и изискване да трябва да идват от политически партии предимно), а самите сътрудници или наблюдатели от своя страна злоупотребяват като гласоподаватели (предимно с дублиране на гласовете – пример ББЦ, БСП и ДПС на предни избори, те когато гласуват могат да заобикалят правилото за уседналост, което автоматично допуска злоупотреби с дублиране на гласовете, двойно гласуване, и други).



Нека да си представим обаче, следната хипотетична ситуация –



Че имаме разеделние между компонентите – лична оторизация, придобиване на право да гласуваш (бюлетина), асоциирането на бюлетина с вот (гласуване) и преброяване на гласовете. Всеки един от тези елементи се оторизира и проверява в отделна и независима организация, а нещо друго (например математиката?) ни гарантира съседна двустранна асоциация, но не и такава, която прескача съсед. Тогава много изкривявания (но не всички) на текущият модел биха били преодолени автоматично.



Обяснявам малко по детайлно – всичко това си го имаме и сега, но нека си представим че то е напълно отделено в отделни организации и процесите се случват независимо. Следните отделни и независими компоненти, мога да определя:



  1. Оторизация на едно място, че ти си си ти (еквивалент на издаване на личната карта) и получаване на съответният идентификатор за това (сега това е личната карта издадена от МВР, но може да бъде и електроне подпис или друго, от една организация)
  2. Оторизация, че имаш право да получиш бюлетина, с която да гласуваш (сега това го прави изборната комисия, проверяваща те в изборният списък и гарантираща, че ти си ти, чрез сертификата издаден от организация 1, в електронният можеш да получиш генериран математически случаен електронен сертификат, проверяем математически (може да е hash функция) и подписан със сертификата на тази втора организация, така че да е непроменим)
  3. Асоцииране на вот с бюлетина (сега го правиш пред изборната комисия, която подпечатва бюлетината ти, за да гарантира пред трети страни че е валидна, електронно може да е трета организация, например сайт, в който ти подписваш електронно избора си с полученият от 2 сертификат)
  4. Преброяване на бюлетините (прави го ЦИК, с под изпълнител типично ИО, в електронният свят това е преброяване и двойно валидиране на валидноста на електронната бюлетина, от четвърта организация)



Нека си представим преднатата система реализирана така (отново, технологията е примерна, не е важна, важна е процедурата и принципа) –
  1. Отиваш и си издаваш електронен подпис, който валидира, че ти си си ти. Той съдържа уникален твой сертификат валидиран от издателят на сертификата (всъщност днес това го правят всички клонове на банки, за 15 лева), което има това право (еквивалент на МВР). Електронният подпис е само пример. Може да бъде електронната ти идентификационна карта (личната ти карта, която ще можеш да получиш от 2017-та година нататък), може да е One-Time-Password система от друга форма. Няма голямо значение. Технологията не е важна, на този етап.
  2. Отиваш и получаваш електронна бюлетина срещу електронният си подпис, тя представлява да речем hash функционално число, подписано от твоят сертификат (но без идентификационна информация) или от алтернативен по-анонимен алгоритъм, като да речем модифициран DH (или уникален случаен частен ключ, и двете могат да дойдат пак през електронният ти подпис). Получената информация пък е подписана със сертификат от организацията издаваща електронните бюлетин (тук можем да правим вариации, може да имаш уникален публичен и частен ключ, генерирани случайно и дадени за теб например).
  3. Отиваш на сайта за гласуване, там с полученият частен ключ подписваш бюлетината и я пращаш обратно на сайта за гласуване, който я подписва със своят си сертификат (сертификатите играят роля на печатите при ИК) и предава веднага или по късно на организацията за преброяване (или пък я предава веднага на междинна организация, но тя я предава на организацията за преброяване след приключване на изборният ден).
  4. Организацията за преброяване получава всички сертификати. Тя има публичните ключове на (1), 2 и 3 (но не и частните). Като резултат тя може да чете информацията (но никой друг не може да чете освен своята си част) и да направи преброяване и пълна валидация. Отделно от 2 е получила списъка с генерираните хешове, има как да ги валидира математически (че са истински) и приема само тези сертификати, които съдържат коректен хеш.



Какъв е резултата от това разделение на отделни независими и несвързани организации:



Имаме невъзможност за генериране на фалшификати (подписванията при 2 и 3 стават локално при гласуващият, през мрежата пътуват и сайтовете получават само подписани сертификати), за да има фалшификат трябва някой да е компрометирал едновременно 1, 2 и 3 (което може да стане само при личният компютър на гласуващият, но дори той да е компрометиран, пак не може да стане лесно – опитайте се да подмените съдържанието на подписваната информация от електронният подпис в ръцете ви на собственият ви компютър. Ако успеете, ми се обадете).
Дори да приемем това за възможно при компютъра на гласуващият, то ще бъде невъзможно да бъде направено масово (няма как в ограничен период от време да повлияеш и да проконтролираш милиони компютри и милиони сертификати), което го прави по добре стоящо от сегашният модел (ЦИК публикува на всяко гласуване статистика показваща близо поне 100к невалидни или дублирани бюлетини, и то по доста консервативният механизъм на оценка, който имат). Също така, подмяната изисква интерактивно действие в момента, в който потребителят се оторизира. Ще ми бъде изключително интересно да чуя как може да стане при един масов електронен вот, в реално време, в рамките на изборният ден. Дори да имаме 1-2 случая на подмяна, те ще са много малко за да повлияят на резултата, и отделно точно електронното гласуване може да допусне механизъм как да се откриват и поправят.



Имаме и гаранция за тайна на вота. Защото само 1 знае дали имаш право да гласуваш и кой си ти. Само 2 издава бюлетина срещу информацията от 1 (но не е задължително да знае кой си, стига да знае, че имаш валиден сертификат, чиято валидация може да се подсигури анонимно), но не знае дали и за кой си гласувал. Само 3 може да знае (това е опционално, 3 може да не разполага със собственият си публичен ключ и да не може да знае), електронната бюлетина с кой вот е асоциирана, но не знае кой е гласувал. Само 4 може да преброи и да валидира бюлетините, пак без да знае кой е гласувал.
За да компрометираш тайната на вота, трябва да компрометираш всичките едновременно. Това е теоретично възможно за държавата да се организира и да го направи, но това е малко вероятно, защото първо може лесно да се установи (много по лесно от при физическото гласуване, понеже тук всички записи се пазят на всякъде), и второ това не е проблем да се прави и сега, така че за него няма технологичен проблем при присъственото гласуване, има принципен държавен и морален проблем, и не можем да кажем, че е нещо, което ще го докара електронното гласуване. Проблемът ако съществува, ще е проблем е на организацията, държавата и културата.



Тъй като подписите стават локално там където ги извършва гласуващият, то хакер хакнал по отделно 2 или 3 или 4 не може да генерира фалшиви подписи. Нито може да подпише (няма частните ключове или сертификатите при клиента от предната организация), нито да създаде валиден сертификат (защото той изисква участие от край до край). Теоретично е възможно да създаде масови фалшиви подписи ако хакне 1, но пък красотата на всичко тук, е че това може лесно да се установи (от ГРАО, в реално време или постфактум при проверката при 4) и всички гласове генерирани по този начин да се извадят от вота (да се инвалидизират хешовете от 2 или сертификатите от 1 и ще се получи инвалидизация при преброяването при 4), включително пост фактум, отново при запазване на пълна анонимност за гласуващият.



Дублирането е премахнато заради валидацията по активен хеш в организация 4. Но за дублирането ще кажа още нещо по-късно. Всеки електронно гласувал ще има само един единствен валиден вот.



Как гарантираме личното гласуване? Това в хипотезата ми го прави електронният подпис, но той може да бъде валидизиран (при 2) ако трябва от видео или снимка обаждане, и ще получи същата форма на валидизация, каквато има и при изборната комисия (да те видят че си приличаш).



Ами подслушването? Дори да гледаме логове и IP адреси, можем да догадаем че някой е гласувал, но не със сигирност кой е той точно, и определено не и за кого е гласувал. Ако криптираната информация е с еднаква дължина, дори статистически механизми не биха могли да помогнат да се различи от подслушване, кой или колко за кого са гласували. Този отговор може да даде само организация номер 4.
Защитата, която имаме тук е дори значително по-добра, при това дори при пълна откритост, отколкото тази, която имаме при присъственото гласуване. Ако например журналист следи пред сградата с изборни секции и да снима кой влиза и излиза (а това го виждаме по телевизията на всички избори), той получава много по-голяма и точна информация, отколкото ако подслушвате мрежата за електронно гласуване.



Как ще гарантираме, че подписите не се дават на други хора? Гаранция, че не си си дал подписа (паспорта) на някой друг е същата, каквато е и при нормалното гласуване. Никаква. Но отново, много е трудно и малко вероятно това да стане масово, и може да се валидира с видео обаждане (или заснемане при получаване на правото за гласуване).



Звучи сложно? На пръв поглед технологията изглежда сложна и многостъпкова. Сигурно ще е трудно за потребителите да я следват? Всъщност не. Идеята с разделението и многото подписвания не е нова и не е случайна. Всъщност тя се изпълнява от ИК и сега, в присъственото гласуване (личната ти карта е сертификат/електронен подпис издаден от МВР, бюлетина с воден знак е сертификат от издателя на бюлетините, проверката по ИК и лична карта и подписа в избирателният списък е еквивалента на получаването на право за гласуване е моята стъпка 2, гласуването в стаичаката и последващият печат върху бюлетината е еквивалента на стъпка 3, валидацията на печатите, и водният знак бюлетините и съдържанието от ЦИК и ИО е еквивалента на стъпка 4). Тази технология с 3-ен подпис е класическата технология използвана от технологията за оторизация KERBEROS на MIT, която до сега не е разбивана, а всъщност е изключително масово употребявана (Active Directory оторизацията в Windows е базирана на нея). Използва се и от свръх популярната OAUTH2 система за оторизация. За потребителят изглежда че попълва данните си само на едно място, но отзад има двойна (или дори тройна) оторизация, и нито една организация не разполага с цялата и пълната информация за личните данни на участника. По важното е, че потребителите дори не разбират как става, и не се налага да се логват на 3 сайта едновременно. Но това не премахва гаранциите за сигурността.



Компрометирани броусъри, операционни системи, троянски коне не компрометират автоматично например електронният подпис (всъщност всички хакове, за които знаем не компрометират системата по същество, а само дебнат ситуация в която потребителят подписва в реално време и се опитват да изземат сесията. Дори да заподозрем 1-2 такива случая, това е невъзможно да се изпълни масово в изборният ден по начин по който да се повлияе на изборният резултат).



За дублиранията – тъй като имаме вторична анонимна проверка (при 4), потребителят може да гласува безброй пъти анонимно (издавайки си безброй бюлетини), и да му се брои само последният вот. Това не само не е недостатък, но може да е и предимство. Дори да бъде принуден от някой “да се гласува правилно” пред него, по късно потребителят може да гласува пак, и да инвалидизира предното си гласуване. Така насилственият вот може да стане много по труден (но не и продаденият, но той не може да бъде преборен с технология – това е лично решение), тъй като хората ще имат алтернатива. Особено в малките населени места локалното влияние (в изборната секция със заплаха от кмета, както често се случва) може да стане много трудно, тъй като хората могат да отидат и пак да си гласуват валидно – другаде.



Тъй като само потребителят може да е в състояние да прочете информацията от подписите си, то системата може да бъде направена така, че потребителят да може да провери как е гласувал (ако се предостави такава услуга от 4) и да открие фалшификации, хакове, или да инвалидизира гласа си. Нещо повече, никой няма да бъде в състояние да му попречи да го направи, или да разбере, че това се е случило, без да има абсолютно цялата информация от 1,2,3 и 4 (а пък ако дори само един се оплаче, това лесно ще се открива проблема и ще се хваща виновника. При добре работеща полиция, много бързо и точно ще се излавят хората опитващи да правят компрометиране на системата).



Обърнете внимание, технологиите не са толкова важни (ползвам публични-частни ключове, защото са добра и позната илюстрация), а процедурата и разделението са важни. Ние следваме същата процедура и сега, но нямаме разделение, просто всичко е концентрирано на едно място и не се проверява вторично. Така там където е концентрацията (ИК) може да се правят фалшификации, а поради липсата на вторична проверка, не могат да се изфилтрират. Също така в приръственото гласуване днес използваме значително по-лесни за фалшификация идентификатори (номера на кочани, водни знаци), отколкото в една електронна система.



Аз лично не само че не виждам по големи недостатъци при така описаната по горе процедура, за дистанционно електронно гласуване, отколкото при сегашният ни физически модел, но и виждам адресирани едни от най важните технически проблеми при сегашното гласуване – повишаване на изборната активност (с което пък адресираме изкривяванията, които имаме от ниската изборателна активност) поради улесняване, премахване на възможностите за валидно преброяване на дубликати, и също така създаване на алтернативи за запазване на гражданските права и личният избор, с което при добра комуникация с избирателите, можем директно да атакуваме (минимум с оскъпяване на) платеният вот и (да обезсмислим) феодализираният вот.



До момента няма нито един случай, на наистина хакната система за електронно гласуване или за електронно банкиране. Нямаме познат случай, при който да е хакнат електронен подпис (но знаем за хиляди подправени паспорти). Нямаме случай, в който да е хакнат алгоритъм за оторизация.
Имаме случаи на откраднати (физически) електронни подписи (но както и при личният паспорт, те могат да се инвалидизират и за разлика от личният паспорт инвалидизацията може да е мигновенна). Имаме случаи на откраднати статични сертификати. Имаме случаи на пробити банкови системи по друг начин (достъп до софтуера управляващ трансферите на парите). Имаме класически Denial of Service атаки, които блокират или забавят скороста на работа на системите. Но те не нарушават анонимноста или оторизационната система на потребителите, а са плод на грешен дизайн в други части от софтуера. Така че не могат да се ползват като доказателство за несигурност. Сигурността за личноста и решенията накрайните потребители си се запазва. Но некадърността на системите си е друг проблем.



В предложената от мен схема, нито една организация и дори нито една произволна комбинация от две организации, не може да генерира фалшива система за оторизация, фалшива бюлетина, фалшива асоциация с вот, които да минат на проверка при номер 4. Всички те само ги записват, подписванията прави само потребителят локално.
Можем да имаме (умишлено) фалшиво преброяване при 4, но пък всички сертификати/бюлетини си стоят и подлежат на вторична проверка, така че при всяко подозрение, могат да се проверят и изловят. Доста по добре, отколкото при сегашният модел на присъствено гласуване.



Отделно, една от красотите на цялата работа е, че 1,2,3 и частично дори 4, могат да бъдат реализирани частно, и повече от веднъж едновременно. Можете да имате много издатели на оторизационни системи (електронен подпис), много издатели на електронни бюлетини, много сайтове за асоцииране на вот, много преброители. Това не само че не нарушава сигурността, но дори я увеличава. Потребител, който има подозрения, или ако направи проверка за собственият си вот, какво е гласувал и види несъвпадение, може да смени в рамките на изборният период (ден) и да гласува пак на друго място, и така да инвалидизира грешката, както и да заобиколи проблема. Обратно, полицията пък може да сваля фалшиви сайтове.



Фишинг атаки (сайтове за фалшиво гласувне) няма да сработят, тъй като не разполагат със сертификатите от публичните ключове, както за да вземат гласа на потребителя, така за да го пратят валидно към 3 или 4.



Единствената атака, която остава е DoS атака, към електронните места за гласуване, така че да бъдат блокирани и потребителите да не могат да гласуват и да се нервят. Но DoS атаките се решават лесно, с добре дистрибутирани и скалирани системи. Дори и без атака, системата може да бъде крайно бавна, защото е проектирана лошо (и тук мога да дам пример с Търговският Регистър или сайта за електронно преброяване на предните избори). Но това не е причина да няма електронно гласуване, това може да е причина да притиснем държавните организации да бъдат много по сериозни в разработката на софтуера си.



Послепис:
За незапознатите, ще кажа няколко думи за основни алгоритми в криптографията, които могат да се ползват (и всъщност се ползват във всички системи с електронни подписи, онлайн оторизация и електронно банкиране):



Challenge алгоритъм – Представете си че имате две страни които си комуникират през несигурна среда. Страна А иска да валидира, че страна Б е тази, за която се представя. Страна А знае, че страна Б ще се валидира с информация, която страна А знае (да кажем парола).
Когато Б иска да се представи, той моли А да му даде едно случайно число. А му изпраща случайно число. Б използва случайното число, за да криптира (или hash-не) информацията си, и я подава на А. А знае числото, знае алгоритъма за криптация (hash), и извършва действието на Б локално, след което сравнява резултата с това, което е получил от Б. Ако има съвпадение, значи Б е този, за когото се представя.
Ако някой подслушва мрежата, той знае че Б се опитва да се оторизира пред А. Но не знае паролата на Б, тя никога не минава некриптирана. Отделно не може да използва информацията, получена от Б за да се представи за Б някъде другаде, понеже друго случайно число ще бъде използвано в онази оторизация.
В резултат – имаме активна оторизация, която не може да се декриптира, и не може да се използва другаде или тук по друго време.



Асиметрични алгоритми за криптиране – Това са алгоритми с публични частни ключове. Идеята е проста – имаме математически алгоритми, които ни гарантират, с изключително високо ниво на сигурност, че имаме два ключа, наричани условно публичен и частен. С частният ключ можем да криптираме информация, която може да се декриптира само с публичният ключ. Частният не може да я декриптира. А по частният ключ не можем да създадем публичен и обратно. Така ако вземем частен ключ и криптираме с него някакъв текст, то знаем, че той е криптиран и подписан от този, за който се представя отсрещната страна, ако можем да му го декриптираме с публичният ключ. Без да имаме публичният ключ, не можем да декриптираме, без да е криптиран с реципрочният частен ключ, не можем да декриптираме с публичният. Този алгоритъм е хитър, защото можете да раздадете на приятелите си вашият публичен ключ, и само те ще могат да четат криптираната информация, която им пращате. Но никой друг, освен вас, няма да може да им пише и изпраща информация.



Електронен Сертификат – Двоен (или повече) подпис с публични и частни ключове. Пример – представете си, че вие си създадете своя двойка публичен и частен ключ. Частният си е винаги у вас. Но искате публичният да е достъпен за група хора или всички. Отивате в полицията (или Certificate Authority) и те проверяват, че вие сте вие. След което криптират с техният си частен ключ информация-текст, която казва – да, това е лицето Пешо Пешев, и неговият публичен ключ е този и този (записан вътре). Полученото нещо се нарича сертификат, и можете да го публикувате публично (или да го изпращате, с криптираната от вашият частен ключ поща).
Всеки, който получи вашият сертификат, ако има публичният ключ на полицията (CA) ще може да го прочете. И ще знае, че полицията (гарантирано от нейният частен ключ) твърди, че вие сте този, за когото се представяте, и вашият публичен ключ кой е. С него пък получателят ще декриптира вашата поща, и ще знае че тя е написана от вас, защото само вие имате вашият частен ключ.



Дифъл-Хелман алгоритъм – друга форма на асиметрично криптиране, при което участниците дори си разменят публично индикатори за ключовете, от които може да се регенерира публичният (или друг) ключ, но подслушващият не може да го направи.



Еднократна парола – частна форма на challenge алгоритъма, при която криптираната информация, която се обменя за валидация (паролата) се допълва от компонент, който е зависим от времето (или последователността на събитието), примерно времето е добавено към паролата. Така дори някой да подслуша и да се опита да кракне с речник паролата, няма да може, понеже само след да речем минута информацията е чисто нова, и старата инвалидизирана.



Електронен подпис – Това е комбинация от електронен сертификат и еднократна парола. През мрежата се транспортира сертификационна информация, модифицирана и криптирана с форма на еднократна парола. Може да бъде реализиран и по опростено (например чиповете на кредитните карти са с много по опростена форма на оторизация), и по сложно. Но това е избор на имплементацията, а не е проблем на технологията. Технологията може да бъде удивително сигурна, дори и всички публични ключове и информация, да бъдат свободно достъпни в мрежата.

Безспорно е, че нещо може да бъде реализирано несигурно. Но също така е безспорно, че може да бъде реализирано и сигурно. Това обаче не е въпрос на дискусията дали да има или да няма електронно гласуване. Това е дискусия, след като решим да има електронно гласуване, как точно да бъде направено то. Да казваш, по добре да няма, защото може да бъде направено лошо, е същото, като да отказваш да летиш със самолети, защото от време на време падат. Да, няма да паднеш със самолет, но не значи, че ще живееш вечно, или че самолет няма да ти падне на главата. Значи само, че ще си винаги по бавен от тези, които пътуват със самолет.


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

Моите опорни точки за електронното гласуване

Post Syndicated from Anonymous original http://delian.blogspot.com/2015/09/blog-post_73.html

Аз съм почитател на електронното гласуване. Не се смятам за специалист, но когато видя самозвани специалисти да приказват технологични и алогични глупости по отношение на електронното гласуване и не мога да не се присмея, като хърбел на щърбел.

И тъй като откакто си сложих баджа ме нападнаха куп хора с мнения против електронното гласуване, къде от страх, къде от тръшкане (че ще навреди на нашите), реших да обобщя някой и да ги коментирам. Така се получи този кратък и непълен списък с моите опорни точки (да иронизирам малко БСП-то и МВР-то от времето на Орешарски) по отношение на електронният вот:



Защо електронен вот а не машинен вот?
Името “електронен вот” е подбрано некоректно и е ограничаващо. И електронният и машинният вот днес са електронни (след време може да са биологични или други). В действителност става въпрос за дистанционен вот, използвайки възможностите на познанията ни и науката за да си осигурим механизъм за сигурно дистанционно гласуване. Това е основната и разлика с машинният вот, който е също некоректно наименование на присъствен вот подпомогнат от машини. В частният случай говорим за референдум, който да позволи започването на дискусия по отношение на това да се намери механизъм за предоставяне на възможност за сигурно и дистанционно гласуване от страна на гласоподавателите. Дали ще го има, и как ще бъде реализиран не е въпрос на референдума, а е въпрос на дискусията, която евентуално би ги последвала след референдума. Без положителен вот от референдума обаче политическата ни история показва, че такава дискусия въобще не влиза в дневен ред.
Няма нужда от конституционна промяна, за да се допусне дистанционен вот. Това е оправдание. Форми на дистанционен вот имаме у нас дори и днес. Ако политическата клика желаеше да дискутира технологии и проблеми по същество, нямаше да има нужда и от референдум. И обратно, решенията от референдума не са обвързващи и задължителни (виж референдума за АЕЦ Белене). Но биха задължили парламента да ги обсъди и да се види публично, кой кой е.



Защо дистанционен вот?
Дистанционният вот улеснява гласуването. За разлика от типичните ограничителни мерки, като например въвеждане на възрастов, расов или образователен ценз, и дори задължителен вот, дистанционният вот увеличава достъпа и възможностите на гражданите да изразяват вот и мнение. Той е разширение, а не ограничаване на демократичната база.



Дистанционният вот би разширил значително възможноста на хора работещи и/ли живеещи в чужбина да гласуват, както и сериозно би намалил разходите по отношение на вота и в България и в чужбина.



Дистанционното гласуване позволява на хора в затруднения (възрастни, болни и други) да гласуват по-свободно и по-достъпно.

Дистанционният вот би намалил значително държавните разходи (пример – електронното преброяване съкрати значително разходите за извършването на преброяването у нас), включително и ако стане масов, ще позволи намаляването на хората работещи в изборните секции и като ефект значително съкращаване на държавните разходи.



Защо да позволяваме да гласуват хората, които вече са избрали да живеят в чужбина?
Грешно е да се фокусираме само върху хората, живеещи в чужбина, по отношение на тяхното право на глас. Електронното и дистанционно гласуване носи ползи за абсолютно всички грамотни граждани в страната. То би повишило значително изборната активност особено сред по-образованото население в страната, и като цяло.

Но дори и да разгледаме в частност само хората, които живеят в чужбина, е безспорно видно, че те са затруднени във възможностите си да упражняват правото си на глас. МВнР от години се справя добре да организира гласуването само в Турция, където са повече от половината отворени секции, и те се запазват поради добра организираност на българската диаспора в Турция, инерция от миналото, предизборен фокус или законодателство определящо къде да се отварят автоматично секции.

Дистанционното/електронното гласуване би улеснило и останалите българи, които нямат достъп до секции за гласуване на под 100 (дори 50)км разстояние или в държави, в които поради локално законодателство такива могат да се отварят само в ограничените ни на брой консулства, значително ограничаващи гражданите ни в други държави да упражняват правото си на глас. Вероятно между 10 и 30% от гласоподавателите се намират в чужбина или далеч от изборните си секции по времето когато се провеждат избори. Въвеждането на дистанционен вот допуска възстановявне поне на половината от тези загубени в момента гласове и значително повишаване на изборната активност. Лесно можете да калкулирате, че всъщност поради невъзможност да присъстват лично, не гласуват повече хора, отколкото сборно гласове получава дори най-голямата партия у нас по време на избори.

Но отново, дистанционното гласуване не е фокусирано и няма отношение само към българите в чужбина, то би значително повишило изборната активност, особено сред по-образованото население, младите и средната класа – точно тази част от гласоподавателите, която се е отдръпнала от урните от години.



Хора, които са избрали да живеят в чужбина не би трябвало да имат право на глас!
Правото на гласуване на един гражданин е определено от неговият паспорт. Той трябва да има право да избира тези, които заради назначеният му паспорт определят дали и какви данъци да плаща и дали да ходи на война.
България губи в емиграция над 3 души на 10000 (2015 est, Worldfactbook), почти изключително млади, в икономически и политически активна и детеродна възраст. В последните 30 години държавата са напуснали 2.5 милиона души. Лесно се изчислява, че при запазване на тенденцията, след 20 години над една трета от младите българи ще живеят и ще бъдат родени в чужбина. Над две трети от тях ще имат (само) българско гражданство поради правилата на европейският съюз. България трябва да се стреми да приобщава тези хора да помагат на страната, да са свързани с нея и да участват в политическият и живот. Електронното дистанционно гласуване е един от най важните механизми, с които реално можем да запазим българщината. Той няма алтернатива. Време е тази дискусия да започне и у нас.



Хора с два паспорта не би трябвало да имат право на глас
Тази дискусия няма отношение към електронното или дистанционно гласуване. Дали да имат или нямат право на глас няма отношение към начина, по който се гласува. Но е редно да отбележа, че тези хора имат право да гласуват според конституцията ни и също така имат и права и задължения поради това, че имат български паспорт, която прави правото им да гласуват справедливо.



Електронното гласуване само ще повиши изборната активност в Турция
Този коментар няма отношение към електронното гласуване. Политическата или етническа сегрегация не е въпрос на технологията на гласуване, дали ще бъде електронна, дистанционна или присъствена. 
Отделно не би трябвало сегрегацията да бъде и въобще въпрос обсъждан в една съвременна демокрация.
В частност обаче, гласуващите ни сънародници в Турция през годините остават константно число и дори намаляват като абсолютна бройка. Причините са логични: демографски и социални. Пика на гласуващите в Турция е отдавна достигнат, и числото не може да нарастне – просто няма от къде. Неговият дял има значение, защото негласуващите в страната се увеличават или защото много българи в други държави не гласуват, и заради недомислената система за разпределение на не целите мандати и липсата на мандатни райони за чужбина.

Електронното/дистанционно гласуване цели да се започне дискусия, с която да се създаде механизъм за по-лесен, по-масов, дистанционен вот, с което да се позволи и на другите българи – в българия или чужбина да гласуват по-лесно и така да се увеличи избирателната активност. Това е мярка за увеличаване на избирателната активност. Точно електронното гласуване може да бъде един от механизмите, с които да се включат по-активно гражданите ни, и да се намали значението на капсулираните вотове.

Не е проблем това, че над 80% от “етническите турци гласуват”. Те имат това си право. И не, електронното гласуване няма как да направи тези 80% на 120%. Но електронното гласуване може да улесни и върне част от онези 45% от населението, които редовно не гласуват, и да вдигне избирателната активност. А точно, чрез вдигането на избирателната активност биха били решени проблемите на  изкривяването на гласовете от ниската избирателна активност.

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



Електронното гласуване ще създаде възможност за злоупотреби и фалшив вот
Злоупотреби и фалшив вот има и сега. Това е проблем на реализацията и процедурите и не трябва да е фокус на дискусията по същество. Има достатъчно сигурни механизми, с които да се реализира електронно и дистанционно гласуване, с които да се гарантира, че то е лично и тайно (по конституционните изисквания). Ако бъде реализирано лошо, може и да не е лично и тайно, точно така и както е сега с физическото присъствено гласуване. Но да се отказваме от него, защото има риск да бъде направено лошо (справедливо отнесен и към сегашното присъствено гласуване) би означавало да се откажем от гласуването въобще защото има риск от проблеми. Или да не излизаме навън защото има риск от проблеми. Да не се качваме в колата си, защото има риск да се повреди.
Въпрос на техническата дискусия е, как да бъде реализирано сигурно и с необходимите гаранции за конституционните изисквания. Можем свободно да водим техническата дискусия отделно. Но не можем да водим дискусия, да забраним гласуването защото имало риск.



Електронният подпис не гарантира сигурност еквивалентна на паспорт
Дали да има или няма дистанционно-електронно гласуване няма отношение към специфична технология на реализацията му. То може да бъде реализирано добре с или без електронен подпис.
В частност обаче, няма никаква техническа разлика между електронен подпис и паспорт. Паспорта съдържа информация, за лицето което го пренася. Самият паспорт е издаден от организация, на която ти вярваш и поради това вярваш на информацията, която можеш да прочетеш в него. Идентификаторите и защитите на паспорта (воден знак, печати и други) показват за теб, че той е издаден от доверената организация. Част от информацията в паспорта идентифицира приносителя (снимката). Комбинацията от информацията за преносителя, която можеш да прочетеш и да сравниш с него (снимката) и доверието (чрез защитите срещу фалшификация) към организацията издател, определят доверието ти към (само)идентификацията на приносителя. Същото се отнася и с електронният подпис, той съдържа публична информация, която можеш да провериш (идентифицираш приносителя), подписана от организация, на която имаш доверие (CA). Защитата е значително по голяма и фалшификацията значително по малка. Всъщност ние не знаем дори за един единствен случай на фалшифициран електронен подпис, докато знаем за не малко случаи (всъщност са доста, над 1 на 10000) за фалшифициран паспорт. Очевидно е, че електронният подпис е много по сигурен от паспорта.
Също като паспорта, електронният подпис подлежи на кражба, но тя не може да е масова, и инвалидацията е мигновенна (за разлика от тази на откраднат паспорт, за която трябват дни и седмици).
Но отново, тук не говорим въобще за дискусия как точно ще се направи електронното и дистанционно гласуване, а да позволим на гражданите да го ползват, ако се намери сигурен технологичен начин.



Електронният вот ще позволи по лесно купуване на гласове
Продажбата на глас е личен акт и въпрос на личен морал. Технологията не може да спре или на обратно да създаде възможност за продажба на гласове. Електронният вот няма отношение към това дали някой ще си продава гласовете или не.
Но електронният вот ще повиши значително избирателната активност, с което ще се намали значително дялът на купеният вот.
Електронният вот при добра техническа реализация обаче би допуснал механизъм, с който самият избирател да може да отменя или променя вота си в рамките на избирателният ден и да обезсмисли масовото закупуване или изнудване за гласуване. Локални форми на феодализъм върху гласовете (например случаите с миньорите на Ковачки, или кмета който брои кой и за кого гласува в неговото село) не са въпрос който ще бъде решен или пък направен по лош от електронният вот. Те са въпрос на независимост, свобода и алтернатива за тези хора. Електронният вот увеличава техните шансове, поради значително затрудняване на местните феодали да проследяват кой за кого е гласувал.



Феодалите ще купуват електронни подписи или ще ги събират и гласуват от името на хората
Отново тук не става въпрос за технологията за гласуване. Не е задължително да се ползва електронен подпис. Но в частност, всеки който знае как се издава и как работи електронен подпис знае, че той не може “да се купи” от чуждо име, и също така е много по лесно да се “изловят” феодали, гласували електронно, отколкото когато хората заплашени са отишли и сами са си гласували. Отново обаче, електронният подпис няма да реши (нито да усложни) проблема с продажбата или заробване-феодализиране на гласове. Това е различен проблем. Той се решава по различен начин. Но дистанционният вот със създаването на повече опции и възможности допуска да създаде на образованите хора повече независимост и алтернатива. Необразованите, хората в затруднения и феодализираните ще намалеят, но няма да изчезнат. Техните проблеми трябва да се решават по друг начин, макар че електронният вот да им създава повече възможности за свобода.



Електронният вот ще позволи на много хора да гласуват по два пъти
Точно обратно, електронният вот ще премахне напълно тази възможност за хората, които са гласували електронно – някой да гласува от тяхно име, или на няколко места. Това е един от най-лесно решимите технологично проблеми, който не се решава (поради човешката обработка на списъците) в традиционното безмашинно присъствено гласуване и е един от най големите проблеми на сегашният ни модел.



Електронният вот е безсмислен защото е много скъп
Това не е вярно, и отделно няма отношение към това дали да има електронно гласуване или не. Електронното гласуване няма да замени нормалното, и на който му е скъпо дистанционното гласуване, ще гласува присъствено. Въпреки това, е редно да отбележим, че електронното гласуване може да бъде реализирано много евтино както за гласоподавателя (безплатно) така и за държавата. Тук и в момента не става въпрос “да похарчим едни пари”. Единсвено става въпрос да позволим на гражданите да имат и тази алтернатива когато гласуват, с което да ги заинтересоваме и повишим политическият им интерес, и избирателната активност. Нека и не забравяме, че от 2017-та година новоиздадените лични карти у нас ще имат чип и ще могат да се използват като електронен подпис.



Електронният вот няма да бъде популярен
За това дори имаме пряк пример, че е невярно твърдение. Така се говореше и очакваше, и по отношение на електронното преброяване на гражданите. Но то бе супер успешно. Над половината граждани доброволно и самоинициативно се преброиха електронно, за много кратко време и това спести много пари на държавата. Недейте да подценявате българите. Ние имаме традиции в телекомуникациите, ИТ и Интернет. Ако процедурите са прости и лесни, можем да очакваме съизмеримо електронно гласуване с електронното преброяване, което би направило вотовете значително по бързи, значително по евтини и със значително по голяма избирателна активност.



Хората нямат какво да ядат а вие искате електронен вот
Това е най безмисленият и най несвързан с темата коментар, който съм чувал

Жените обичат лидери!

Post Syndicated from Anonymous original http://delian.blogspot.com/2015/09/blog-post_22.html

Жените обичат лидери, казват някой, за да обясняват защо млади мацки се омъжват за богати старчета. Така ще да е и с Ден…

Posted by Delian Delchev on Monday, September 21, 2015

Валат на Капо

Post Syndicated from Anonymous original http://delian.blogspot.com/2015/09/blog-post.html

След фиаското с некадърно преправеното ДП на 10 от тефтерчетата на Златанов, прокуратурата си е взела поука и вчера е обявила обществена поръчка за класифициран (таен) изпълнител, който да поправи валат на капо
Posted by Delian Delchev on Tuesday, September 22, 2015

По-Неделник

Post Syndicated from Anonymous original http://delian.blogspot.com/2015/09/blog-post_71.html

Както съм казвал и преди – ако името неделя значи ден, в който не се работи, то в по-неделник не трябва да се работи дори повече!

Posted by Delian Delchev on Sunday, September 20, 2015

Задължителният вот в Гърция…

Post Syndicated from Anonymous original http://delian.blogspot.com/2015/09/blog-post_45.html

За почитателите на задължителният вот – в Гърция гласуването е задължително, но на последните избори са гласували по малко отколкото у нас

Posted by Delian Delchev on Monday, September 21, 2015

ЦиПрасчо и другарите от ПЕС

Post Syndicated from Anonymous original http://delian.blogspot.com/2015/09/blog-post_21.html

Не разбирам почудата на другарят Станишев, и други заслужили другари от ПЕС или председатели на ЕП (Шулц, от ПЕС), или п…

Posted by Delian Delchev on Monday, September 21, 2015

За носорога и романтиката

Post Syndicated from Anonymous original http://delian.blogspot.com/2015/09/blog-post_20.html

В очите на романтиката носорога става еднорог!

Posted by Delian Delchev on Sunday, September 20, 2015

Просто бизнес

Post Syndicated from Anonymous original http://delian.blogspot.com/2015/09/blog-post_89.html

Ако АБВ прави партиен купон в хотел Гоце, и плаща с партийната субсидия, това подкрепа, подкуп или случайност е за вожда, или просто бизнес?

Posted by Delian Delchev on Sunday, September 20, 2015

Изненадан Гоце

Post Syndicated from Anonymous original http://delian.blogspot.com/2015/09/blog-post_92.html

Гоце все е изненадан, я че спечели президентски избори, я че бил сътрудник на ДС, я че архар застанал пред пушката му, я…

Posted by Delian Delchev on Sunday, September 20, 2015

Морето ни било по чисто от това на съседите, и борбата ни с корупцията също!

Post Syndicated from Anonymous original http://delian.blogspot.com/2015/09/blog-post_19.html

Според Борисов, когато вече ги няма туристите да акат и моето ни ставало по чисто (вече) от това в Гърция и Турция (където още има туристи)

Posted by Delian Delchev on Saturday, September 19, 2015

Чуждофобията била враг на България

Post Syndicated from Anonymous original http://delian.blogspot.com/2015/09/blog-post_59.html

Някой трябва да ми обясни как русофобията е враг на България? 🙂 Разбирам да е русофилството (страст към чужда държава) …

Posted by Delian Delchev on Saturday, September 19, 2015

Manicure or moneycure?

Post Syndicated from Anonymous original http://delian.blogspot.com/2015/09/manicure-or-moneycure.html

Manicure is a form of a cure against money!

Posted by Delian Delchev on Saturday, September 19, 2015

JavaScript private methods and variables

Post Syndicated from Anonymous original http://deliantech.blogspot.com/2015/08/javascript-private-methods-and-variables.html

Often I am told that JavaScript has no real private methods and variables the same way as this is for Python or Perl.
Although, that is true for Python and Perl (all scopes and their content are publicly accessible and there is always a way to list and access the content) it is not true for JavaScript.
JavaScript have one of the most powerful scoping technique available for a main-stream programing language and provides you with the ability to hide and make private some content if needed.
Let me show you an example:
function MyClass() {
    var fullyPrivateVar = ‘xxxx’;
    this.notFullyPrivateVar = ‘yyyy’;

    function privateMethod() {
        return fullyPrivateVar;
    }

    this.publicMethodWithPrivateAccess = function() { return privateMethod() }
}

MyClass.prototype.publicMethodWithNoPrivateAccess = function() {
    return this.notFullyPrivateVar;
}

x = new MyClass();
console.log(x.publicMethodWithNoPrivateAccess());
yyyy
console.log(x.publicMethodWithPrivateAccess());
xxxx

I think the example is self explanatory, but let me say few words on it:
In JavaScript you can have hierarchy of scopes and you can define unlimited amount function in functions levels (and scope levels) in difference to other programming languages where you have limited / fixed scope levels.
So I have a privateMethod and fullyPrivateVar defined within MyClass. Because of it, only things defined in this scope will have access to them. Like publicMethodWithPrivateAccess that I assign with the constructor to the newly constructed object. However,  publicMethodWithNoPrivateAccess is defined outside of the scope and has no access to those values. But it has access to everything in the this scope. One could argue, that this approach takes more memory for the methods because I define a new method with every initialization of the class (the function assignment). But that is not true. The function in the function is having a static code (it is not part of eval+variable) and is compiled during the initial javascript processing of the JS virtual machine. So it will not take extra memory. Only during execution the function will be dynamically assigned with the private scope of the constructor, something you want anyway.

Node.JS module to access Cisco IOS XR XML interface

Post Syndicated from Anonymous original http://deliantech.blogspot.com/2015/03/nodejs-module-to-access-cisco-ios-xr.html

Hello to all,
This is the early version of my module for Node.JS that allows configuring routers and retrieving information over Cisco IOS XR’s XML interface.
The module is in its early phases – it still does not read IOS XR schema files and therefore decode the data (in JSON) in a little ugly way (too much arrays). I am planning to fix it, so there may be changes in the responses.
Please see bellow the first version of the documentation I’ve set in the github:

Module for Cisco XML API interface IOS XR

This is a small module that implements interface to Cisco IOS XR XML Interface.
This module open an maintain TCP session to the router, sends requests and receive responses.

Installation

To install the module do something like that:
npm install node-ciscoxml

Usage

It is very easy to use this module. See the methods bellow:

Load the module

To load and use the module, you have to use a code similar to this:
var cxml = require('node-ciscoxml');
var c = cxml( { ...connect options.. });

Module init and connect options

host (default 127.0.0.1) – the hostname of the router where we’ll connect
port (default 38751) – the port of the router where XML API is listening
username (default guest) – the username used for authentication, if username is requested by the remote side
password (default guest) – the password used for authentication, if password is requested by the remote side
connectErrCnt (default 3) – how many times it will retry to connect in case of an error
autoConnect (default true) – should it try to auto connect to the remote side if a request is dispatched and there is no open session already
autoDisconnect (default 60000) – how much milliseconds we will wait for another request before the tcp session to the remote side is closed. If the value is 0, it will wait forever (or until the remote side disconnects). Bear in mind autoConnect set to false does not assume autoDisconnect set to 0/false as well.
userPromptRegex (default (Username|Login)) – the rule used to identify that the remote side requests for a username
passPromptRegex (default Password) – the rule used to identify that the remote side requests for a password
xmlPromptRegex (default XML>) – the rule used to identify successful login/connection
noDelay (default true) – disables the Nagle algorithm (true)
keepAlive (default 30000) – enabled or disables (value of 0) TCP keepalive for the socket
ssl (default false) – if it is set to true or an object, then SSL session will be opened. Node.js TLS module is used for that so if the ssl points to an object, the tls options are taken from it. Be careful – enabling SSL does not change the default port from 38751 to 38752. You have to set it explicitly!
Example:
var cxml = require('node-ciscoxml');
var c = cxml( {
    host: '10.10.1.1',
    port: 5000,
    username: 'xmlapi',
    password: 'xmlpass'
});

connect method

This method forces explicitly a connection. It could accept any options of the above.
Example:
var cxml = require('node-ciscoxml');
var c = cxml();
c.connect( {
    host: '10.10.1.1',
    port: 5000,
    username: 'xmlapi',
    password: 'xmlpass'
});
The connect method is not necessary to be used. If autoConnect is enabled (default) the module will automatically open and close tcp connections when needed.
Connect supports callback. Example:
var cxml = require('node-ciscoxml');
cxml().connect( {
    host: '10.10.1.1',
    port: 5000,
    username: 'xmlapi',
    password: 'xmlpass'
}, function(err) {
    if (!err)
        console.log('Successful connection');
});
The callback may be the only parameter as well. Example:
var cxml = require('node-ciscoxml');
cxml({
    host: '10.10.1.1',
    port: 5000,
    username: 'xmlapi',
    password: 'xmlpass'
}).connect(function(err) {
    if (!err)
        console.log('Successful connection');
});
Example with SSL:
var cxml = require('node-ciscoxml');
var fs = require('fs');
cxml({
    host: '10.10.1.1',
    port: 38752,
    username: 'xmlapi',
    password: 'xmlpass',
    ssl: {
          // These are necessary only if using the client certificate authentication
          key: fs.readFileSync('client-key.pem'),
          cert: fs.readFileSync('client-cert.pem'),
          // This is necessary only if the server uses the self-signed certificate
          ca: [ fs.readFileSync('server-cert.pem') ]
    }
}).connect(function(err) {
    if (!err)
        console.log('Successful connection');
});

disconnect method

This method explicitly disconnects a connection.

sendRaw method

.sendRaw(data,callback)
Parameters:
data – a string containing valid Cisco XML request to be sent
callback – function that will be called when a valid Cisco XML response is received
Example:
var cxml = require('node-ciscoxml');
var c = cxml({
    host: '10.10.1.1',
    port: 5000,
    username: 'xmlapi',
    password: 'xmlpass'
});

c.sendRaw('<Request><GetDataSpaceInfo/></Request>',function(err,data) {
    console.log('Received',err,data);
});

sendRawObj method

.sendRawObj(data,callback)
Parameters:
data – a javascript object that will be converted to a Cisco XML request
callback – function that will be called with valid Cisco XML response converted to javascript object
Example:
var cxml = require('node-ciscoxml');
var c = cxml({
    host: '10.10.1.1',
    port: 5000,
    username: 'xmlapi',
    password: 'xmlpass'
});

c.sendRawObj({ GetDataSpaceInfo: '' },function(err,data) {
    console.log('Received',err,data);
});

rootGetDataSpaceInfo method

.rootGetDataSpaceInfo(callback)
Equivalent to .sendRawObj for GetDataSpaceInfo command

getNext

Sends getNext request with a specific id, so we can retrieve the rest of the previous operation if it has been truncated.
id – the ID callback – the callback with the data (in js object format)
Keep in mind next response may be truncated as well, so you have to check for IteratorID all the time.
Example:
var cxml = require('node-ciscoxml');
var c = cxml({
    host: '10.10.1.1',
    port: 5000,
    username: 'xmlapi',
    password: 'xmlpass'
});

c.sendRawObj({ Get: { Configuration: {} } },function(err,data) {
    console.log('Received',err,data);
    if ((!err) && data && data.Response.$.IteratorID) {
        return c.getNext(data.Response.$.IteratorID,function(err,nextData) {
            // .. code to merge data with nextData
        });
    }
    // .. code
});

sendRequest method

This method is equivalent to sendRawObj but it can automatically detect the need and resupply GetNext requests so the response is absolutley full. Therefore this method should be the preferred method for sending requests that expect very large replies.
Example:
var cxml = require('node-ciscoxml');
var c = cxml({
    host: '10.10.1.1',
    port: 5000,
    username: 'xmlapi',
    password: 'xmlpass'
});

c.sendRequest({ GetDataSpaceInfo: '' },function(err,data) {
    console.log('Received',err,data);
});

requestPath method

This is a method equivalent to sendRequest but instead of an object, the request may be formatted in a simple path string. This metod is not very useful for complex requests. But its value is in the ability to simplify very much the simple requests. The response is in JavaScript object
Example:
var cxml = require('node-ciscoxml');
var c = cxml({
    host: '10.10.1.1',
    port: 5000,
    username: 'xmlapi',
    password: 'xmlpass'
});

c.requestPath('Get.Configuration.Hostname',function(err,data) {
    console.log('Received',err,data);
});

reqPathPath method

This is the same method as requestPath, but the response is not an object, but a path array. The method supports optional filter, which has to be a RegExp object and all paths and values will be tested against it Only those returning true will be included in the response array.
Example:
var cxml = require('node-ciscoxml');
var c = cxml({
    host: '10.10.1.1',
    port: 5000,
    username: 'xmlapi',
    password: 'xmlpass'
});

c.reqPathPath('Get.Configuration.Hostname',/Hostname/,function(err,data) {
    console.log('Received',data[0]);
    // The output should be something like
    // [ 'Response("MajorVersion"="1","MinorVersion"="0").Get.Configuration.Hostname("MajorVersion"="1","MinorVersion"="0")',
           'asr9k-router' ] 
});
This method could be very useful for getting simple responses and configurations.

getConfig method

This method requests the whole configuration of the remote device and return it as object
Example:
c.getConfig(function(err,config) {
    console.log(err,config);
});

cliConfig method

This method is quite simple, it executes a command(s) in CLI Configuration mode and return the response in JS Object. You have to know that any configuration change in IOS XR is not effective unless it is committed!
Example:
c.cliConfig('username testuser\ngroup operator\n',function(err,data) {
    console.log(err,data);
    c.commit();
});

cliExec method

Executes a command(s) in CLI Exec mode and return the response in JS Object.
c.cliExec('show interfaces',function(err,data) {
    console.log(err,data?data.Response.CLI[0].Exec[0]);
});

commit method

Commit the current configuration.
Example:
c.commit(function(err,data) {
    console.log(err,data);
});

lock method

Locks the configuration mode.
Example:
c.lock(function(err,data) {
    console.log(err,data);
});

unlock method

Unlocks the configuration mode.
Example:
c.unlock(function(err,data) {
    console.log(err,data);
});

Configure Cisco IOS XR for XML agent

To configure IOS XR for remote XML configuration you have to:
Ensure you have *mgbl*** package installed and activated! Without it you will have no xml agentcommands!
Enable the XML agent with a similar configuration:
xml agent
  vrf default
    ipv4 access-list SECUREACCESS
  !
  ipv6 enable
  session timeout 10
  iteration on size 100000
!
You can enable tty and/or ssl agents as well!
(Keep in mind – full filtering of the XML access has to be done by the control-plane management-plane command! The XML interface does not use VTYs!)
You have to ensure you have correctly configured aaa as the xml agent uses default method for both authentication and authorization and that cannot be changed (last verified with IOS XR 5.3).
You have to have both aaa authentication and authorization. If authorization is not set (aaa authorization default local or none), you may not be able to log in. And you shall ensure that both the authentication and authorization share the same source (tacacs+ or local).
The default agent port is 38751 for the default agent and 38752 for SSL.

Debugging

The module uses “debug” module to log its outputs. You can enable the debugging by having in your code something like:
require('debug').enable('ciscoxml');
Or setting DEBUG environment to ciscoxml before starting the Node.JS

ExtJS short highlight of a gridrow in case of an update

Post Syndicated from Anonymous original http://deliantech.blogspot.com/2015/03/extjs-short-highlight-of-gridrow-in.html

In my ExtJS code I often update the values of records associated with Stores/Data Models associated with Grid Panel. 
Sometimes this an automated update received from the web server (an example you can see here) sometimes not.
However, as a user I like to be able to see if somewhere in the grid some data has been modified.
And to create a code, that highlight for a moment the row or a cell where a change happened is actually not so hard. 
Here is a small example how you can do that – you just have to bind to event ‘itemupdate‘ on a tableview. See the example bellow, that is supposed to be self explanatory:

Ext.ComponentQuery.query(‘#mytableview’).on(‘itemupdate’, function(record, index, node) {
    node.className = node.className + ‘ x-grid-item-alt’;
    setTimeout(function() {
        node.className = node.className.replace(/x-grid-item-alt/, ”);
    }, 500);
});

node.js module implementing EventEmitter interface using MongoDB tailable cursors as backend

Post Syndicated from Anonymous original http://deliantech.blogspot.com/2015/03/nodejs-module-implementing-eventemitter.html

I’ve published in the npm a new module, that I’ve used privately for a long time which implements EventEmitter interface using MongoDB tailable cursors as backend.
This module could be used as a messaging bus between processes or even between node.js modules as it allows implementing EventEmitter wihout need of sharing the object instance in advance.
Please see the first version of the README.md bellow:

Module for creating event bus interface based on MongoDB tailable cursors

The idea behind this module is to create EventEmitter like interface, which uses MongoDB capped collections and tailable cursors as an internal messaging bus. This model has a lot of advantages, especially if you already use MongoDB in your project.
The advantages are:
You don’t have to exchange the event emitter object between different pages or even different processes (forked, clustered, living on separate machines). As long as you use the same mongoUrl and capped collection name, you can exchange information. This way you can even create applications that runs on a different hardware and they may exchanging events and data as if they are the same application! Also your events are stored in a collection and could be used as a transaction log latley (mongodb’s own transaction log is implemented with capped collections).
It simplifies an application development very much.

Installation

To install the module run the following command:
npm install node-mongotailableevents

Short

It is easy to use that module. Look at the following example:
var ev = require('node-mongotailableevents');

var e = ev( { ...options ... }, callback );

e.on('event',callback);

e.emit('event',data);

Initialization and options

The following options can be used with the module
  • mongoUrl (default mongodb://127.0.0.1/test) – the URL to the mongo database
  • mongoOptions (default none) – Specific options to be used for the connection to the mongo database
  • name (default tailedEvents) – the name of the capped collection that will be created if it does not exists
  • size (default 1000000) – the maximum size of the capped collection (when reached, the oldest records will be automatically removed)
  • max (default 1000) – the maximum size in amount of records for the capped collection
You can call and create a new event emitter instance without options:
var ev = require('node-mongotailableevents');
var e = ev();
Or you can call and create a event emitter instance with options:
var ev = require('node-mongotailableevents');
var e = ev({
   mongoUrl: 'mongodb://127.0.0.1/mydb',
   name: 'myEventCollection'
});
Or you can call and create a event emitter instance with options and callback, which will be called when the collection is created successfuly:
var ev = require('node-mongotailableevents');
ev({
   mongoUrl: 'mongodb://127.0.0.1/mydb',
   name: 'myEventCollection'
}, function(err, e) {
    console.log('EventEmitter',e);
});
Or you can call and create event emitter with just callback (and default options):
ev(function(err, e) {
    console.log('EventEmitter',e);
});

Usage

This module inherits EventEmitter, so you can use all of the EventEmitter methods. Example:
ev(function(err, e) {
    if (err) throw err;

    e.on('myevent',function(data) {
        console.log('We have received',data);
    });

    e.emit('myevent','my data');
});
The best feature is that you can exchange events between different pages or processes, without the need of exchange in advance of the eventEmitter object instance or without any complex configuration, as long as both pages processes uses the same mongodb database (but it could be a different replica servers) and the same “name” (the name of the capped collection). This way you can create massive clusters and messaging bus distributed among multiple machines without a need of any separate messaging system and its configuration.
Do a simple example – start two separate node processes with the following code, and see what the results are:
var ev = require('node-mongotailableevents');
ev(function(err, e) {
    if (err) throw err;

    e.on('myevent',function(data) {
        console.log('We have received',data);
    });

    setInterval(function() {
        e.emit('myevent','my data'+parseInt(Math.random()*1000000));
    },5000);
});
You shall see on both of the outputs both of the messages received.

Example how to use node-netflowv9 and define your own netflow type decoders

Post Syndicated from Anonymous original http://deliantech.blogspot.com/2015/03/example-how-to-use-node-netflowv9-and.html

This is an example of how you can use node-netflowv9 library (version >= 0.2.5) to define your own proprietary Netflow v9 type decoders if they are not supported.
The given primer is adding decoding for types 30000, 30001, 30002 for Cisco ASA/PIX netflow:

var Collector = require('node-netflowv9');

var colObj = Collector(function (flow) { console.log(flow) });
colObj.listen(5000); var aclDecodeRule = { 12: 'o["$name"] = { aclId: buf.readUInt32BE($pos), aclLineId: buf.readUInt32BE($pos+4), aclCnfId: buf.readUInt32BE($pos+8) };'
}; colObj.nfTypes[33000] = { name: 'nf_f_ingress_acl_id', compileRule: aclDecodeRule }; colObj.nfTypes[33001] = { name: 'nf_f_egress_acl_id', compileRule: aclDecodeRule }; colObj.nfTypes[33002] = { name: 'nf_f_fw_ext_event', compileRule: { 2: 'o['$name']=buf.readUInt16BE($pos);' } }; colObj.nfTypes[40000] = { name: 'nf_f_username', compileRule: { 0: 'o["$name"] = buf.toString("utf8",$pos,$pos+$len);' } };

node-netflowv9 node.js module for processing of netflowv9 has been updated to 0.2.5

Post Syndicated from Anonymous original http://deliantech.blogspot.com/2015/03/node-netflowv9-nodejs-module-for.html

My node-netflowv9 library has been updated to version 0.2.5

There are few new things –

  • Almost all of the IETF netflow types are decoded now. Which means practically that we support IPFIX
  • Unknown NetFlow v9 type does not throw an error. It is decoded into property with name ‘unknown_type_XXX’ where XXX is the ID of the type
  • Unknown NetFlow v9 Option Template scope does not throw an error. It is decoded in ‘unknown_scope_XXX’ where XXX is the ID of the scope
  • The user can overwrite how different types of NetFlow are decoded and the user can define its own decoding for new types. The same for scopes. And this can happen “on fly” – at any time.
  • The library supports well multiple netflow collectors running at the same time
  • A lot of new options and models for using of the library has been introduced
Bellow is the updated README.md file, describing how to use the library:

Usage

The usage of the netflowv9 collector library is very very simple. You just have to do something like this:
var Collector = require('node-netflowv9');

Collector(function(flow) {
    console.log(flow);
}).listen(3000);
or you can use it as event provider:
Collector({port: 3000}).on('data',function(flow) {
    console.log(flow);
});
The flow will be presented in a format very similar to this:
{ header: 
  { version: 9,
     count: 25,
     uptime: 2452864139,
     seconds: 1401951592,
     sequence: 254138992,
     sourceId: 2081 },
  rinfo: 
  { address: '15.21.21.13',
     family: 'IPv4',
     port: 29471,
     size: 1452 },
  packet: Buffer <00 00 00 00 ....>
  flow: [
  { in_pkts: 3,
     in_bytes: 144,
     ipv4_src_addr: '15.23.23.37',
     ipv4_dst_addr: '16.16.19.165',
     input_snmp: 27,
     output_snmp: 16,
     last_switched: 2452753808,
     first_switched: 2452744429,
     l4_src_port: 61538,
     l4_dst_port: 62348,
     out_as: 0,
     in_as: 0,
     bgp_ipv4_next_hop: '16.16.1.1',
     src_mask: 32,
     dst_mask: 24,
     protocol: 17,
     tcp_flags: 0,
     src_tos: 0,
     direction: 1,
     fw_status: 64,
     flow_sampler_id: 2 } } ]
There will be one callback for each packet, which may contain more than one flow.
You can also access a NetFlow decode function directly. Do something like this:
var netflowPktDecoder = require('node-netflowv9').nfPktDecode;
....
console.log(netflowPktDecoder(buffer))
Currently we support netflow version 1, 5, 7 and 9.

Options

You can initialize the collector with either callback function only or a group of options within an object.
The following options are available during initialization:
port – defines the port where our collector will listen to.
Collector({ port: 5000, cb: function (flow) { console.log(flow) } })
If no port is provided, then the underlying socket will not be initialized (bind to a port) until you call listen method with a port as a parameter:
Collector(function (flow) { console.log(flow) }).listen(port)
cb – defines a callback function to be executed for every flow. If no call back function is provided, then the collector fires ‘data’ event for each received flow
Collector({ cb: function (flow) { console.log(flow) } }).listen(5000)
ipv4num – defines that we want to receive the IPv4 ip address as a number, instead of decoded in a readable dot format
Collector({ ipv4num: true, cb: function (flow) { console.log(flow) } }).listen(5000)
socketType – defines to what socket type we will bind to. Default is udp4. You can change it to udp6 is you like.
Collector({ socketType: 'udp6', cb: function (flow) { console.log(flow) } }).listen(5000)
nfTypes – defines your own decoders to NetFlow v9+ types
nfScope – defines your own decoders to NetFlow v9+ Option Template scopes

Define your own decoders for NetFlow v9+ types

NetFlow v9 could be extended with vendor specific types and many vendors define their own. There could be no netflow collector in the world that decodes all the specific vendor types. By default this library decodes in readable format all the types it recognises. All the unknown types are decoded as ‘unknown_type_XXX’ where XXX is the type ID. The data is provided as a HEX string. But you can extend the library yourself. You can even replace how current types are decoded. You can even do that on fly (you can dynamically change how the type is decoded in different periods of time).
To understand how to do that, you have to learn a bit about the internals of how this module works.
  • When a new flowset template is received from the NetFlow Agent, this netflow module generates and compile (with new Function()) a decoding function
  • When a netflow is received for a known flowset template (we have a compiled function for it) – the function is simply executed
This approach is quite simple and provides enormous performance. The function code is as small as possible and as well on first execution Node.JS compiles it with JIT and the result is really fast.
The function code is generated with templates that contains the javascript code to be add for each netflow type, identified by its ID.
Each template consist of an object of the following form:
{ name: 'property-name', compileRule: compileRuleObject }
compileRuleObject contains rules how that netflow type to be decoded, depending on its length. The reason for that is, that some of the netflow types are variable length. And you may have to execute different code to decode them depending on the length. The compileRuleObject format is simple:
{
   length: 'javascript code as a string that decode this value',
   ...
}
There is a special length property of 0. This code will be used, if there is no more specific decode defined for a length. For example:
{
   4: 'code used to decode this netflow type with length of 4',
   8: 'code used to decode this netflow type with length of 8',
   0: 'code used to decode ANY OTHER length'
}

decoding code

The decoding code must be a string that contains javascript code. This code will be concatenated to the function body before compilation. If that code contain errors or simply does not work as expected it could crash the collector. So be careful.
There are few variables you have to use:
$pos – this string is replaced with a number containing the current position of the netflow type within the binary buffer.
$len – this string is replaced with a number containing the length of the netflow type
$name – this string is replaced with a string containing the name property of the netflow type (defined by you above)
buf – is Node.JS Buffer object containing the Flow we want to decode
o – this is the object where the decoded flow is written to.
Everything else is pure javascript. It is good if you know the restrictions of the javascript and Node.JS capabilities of the Function() method, but not necessary to allow you to write simple decoding by yourself.
If you want to decode a string, of variable length, you could write a compileRuleObject of the form:
{
   0: 'o["$name"] = buf.toString("utf8",$pos,$pos+$len)'
}
The example above will say that for this netfow type, whatever length it has, we will decode the value as utf8 string.

Example

Lets assume you want to write you own code for decoding a NetFlow type, lets say 4444, which could be of variable length, and contains a integer number.
You can write a code like this:
Collector({
   port: 5000,
   nfTypes: {
      4444: {   // 4444 is the NetFlow Type ID which decoding we want to replace
         name: 'my_vendor_type4444', // This will be the property name, that will contain the decoded value, it will be also the value of the $name
         compileRule: {
             1: "o['$name']=buf.readUInt8($pos);", // This is how we decode type of length 1 to a number
             2: "o['$name']=buf.readUInt16BE($pos);", // This is how we decode type of length 2 to a number
             3: "o['$name']=buf.readUInt8($pos)*65536+buf.readUInt16BE($pos+1);", // This is how we decode type of length 3 to a number
             4: "o['$name']=buf.readUInt32BE($pos);", // This is how we decode type of length 4 to a number
             5: "o['$name']=buf.readUInt8($pos)*4294967296+buf.readUInt32BE($pos+1);", // This is how we decode type of length 5 to a number
             6: "o['$name']=buf.readUInt16BE($pos)*4294967296+buf.readUInt32BE($pos+2);", // This is how we decode type of length 6 to a number
             8: "o['$name']=buf.readUInt32BE($pos)*4294967296+buf.readUInt32BE($pos+4);", // This is how we decode type of length 8 to a number
             0: "o['$name']='Unsupported Length of $len'"
         }
      }
   },
   cb: function (flow) {
      console.log(flow)
   }
});
It looks to be a bit complex, but actually it is not. In most of the cases, you don’t have to define a compile rule for each different length. The following example defines a decoding for a netflow type 6789 that carry a string:
var colObj = Collector(function (flow) {
      console.log(flow)
});

colObj.listen(5000);

colObj.nfTypes[6789] = {
    name: 'vendor_string',
    compileRule: {
        0: 'o["$name"] = buf.toString("utf8",$pos,$pos+$len)'
    }
}
As you can see, we can also change the decoding on fly, by defining a property for that netflow type within the nfTypes property of the colObj (the Collector object). Next time when the NetFlow Agent send us a NetFlow Template definition containing this netflow type, the new rule will be used (the routers usually send temlpates from time to time, so even currently compiled templates are recompiled).
You could also overwrite the default property names where the decoded data is written. For example:
var colObj = Collector(function (flow) {
      console.log(flow)
});
colObj.listen(5000);

colObj.nfTypes[14].name = 'outputInterface';
colObj.nfTypes[10].name = 'inputInterface';

Logging / Debugging the module

You can use the debug module to turn on the logging, in order to debug how the library behave. The following example show you how:
require('debug').enable('NetFlowV9');
var Collector = require('node-netflowv9');
Collector(function(flow) {
    console.log(flow);
}).listen(5555);

Multiple collectors

The module allows you to define multiple collectors at the same time. For example:
var Collector = require('node-netflowv9');

Collector(function(flow) { // Collector 1 listening on port 5555
    console.log(flow);
}).listen(5555);

Collector(function(flow) { // Collector 2 listening on port 6666
    console.log(flow);
}).listen(6666);

NetFlowV9 Options Template

NetFlowV9 support Options template, where there could be an option Flow Set that contains data for a predefined fields within a certain scope. This module supports the Options Template and provides the output of it as it is any other flow. The only difference is that there is a property isOption set to true to remind to your code, that this data has come from an Option Template.
Currently the following nfScope are supported – system, interface, line_card, netflow_cache. You can overwrite the decoding of them, or add another the same way (and using absolutley the same format) as you overwrite nfTypes.

node-netflowv9 is updated to support netflow v1, v5, v7 and v9

Post Syndicated from Anonymous original http://deliantech.blogspot.com/2014/11/node-netflowv9-is-updated-to-support.html

My netflow module for Node.JS has been updated. Now it support more NetFlow versions – like NetFlow ver 1, ver 5, ver 7 and ver 9. Also it has been modified to be able to be used as Event Generator (instead of doing callbacks). Now you can do as well (the old model is still supported):
Collector({port: 3000}).on('data',function(flow) {
    console.log(flow);
});
Additionally, the module now supports and decode option templates and option data flows for NetFlow v9.