All posts by Bozho

Discovering an OSSEC/Wazuh Encryption Issue

Post Syndicated from Bozho original https://techblog.bozho.net/discovering-an-ossec-wazuh-encryption-issue/

I’m trying to get the Wazuh agent (a fork of OSSEC, one of the most popular open source security tools, used for intrusion detection) to talk to our custom backend (namely, our LogSentinel SIEM Collector) to allow us to reuse the powerful Wazuh/OSSEC functionalities for customers that want to install an agent on each endpoint rather than just one collector that “agentlessly” reaches out to multiple sources.

But even though there’s a good documentation on the message format and encryption, I couldn’t get to successfully decrypt the messages. (I’ll refer to both Wazuh and OSSEC, as the functionality is almost identical in both, with the distinction that Wazuh added AES support in addition to blowfish)

That lead me to a two-day investigation on possible reasons. The first side-discovery was the undocumented OpenSSL auto-padding of keys and IVs described in my previous article. Then it lead me to actually writing C code (an copying the relevant Wazuh/OSSEC pieces) in order to debug the issue. With Wazuh/OSSEC I was generating one ciphertext and with Java and openssl CLI – a different one.

I made sure the key, key size, IV and mode (CBC) are identical. That they are equally padded and that OpenSSL’s EVP API is correctly used. All of that was confirmed and yet there was a mismatch, and therefore I could not decrypt the Wazuh/OSSEC message on the other end.

After discovering the 0-padding, I also discovered a mistake in the documentation, which used a static IV of FEDCA9876543210 rather than the one found in the code, where the 0 preceded 9 – FEDCA0987654321. But that didn’t fix the issue either, only got me one step closer.

A side-note here on IVs – Wazuh/OSSEC is using a static IV, which is a bad practice. The issue is reported 5 years ago, but is minor, because they are using some additional randomness per message that remediates the use of a static IV; it’s just not idiomatic to do it that way and may have unexpected side-effects.

So, after debugging the C code, I got to a simple code that could be used to reproduce the issue and asked a question on Stackoverflow. 5 minutes after posting the question I found another, related question that had the answer – using hex strings like that in C doesn’t work. Instead, they should be encoded: char *iv = (char *)"\xFE\xDC\xBA\x09\x87\x65\x43\x21\x00\x00\x00\x00\x00\x00\x00\x00";. So, the value is not the bytes corresponding to the hex string, but the ASCII codes of each character in the hex string. I validated that in the receiving Java end with this code:

This has an implication on the documentation, as well as on the whole scheme as well. Because the Wazuh/OSSEC AES key is: MD5(password) + MD5(MD5(agentName) + MD5(agentID)){0, 15}, the 2nd part is practically discarded, because the MD5(password) is 32 characters (= 32 ASCII codes/bytes), which is the length of the AES key. This makes the key derived from a significantly smaller pool of options – the permutations of 16 bytes, rather than of 256 bytes.

I raised an issue with Wazuh. Although this can be seen as a vulnerability (due to the reduced key space), it’s rather minor from security point of view, and as communication is mostly happening within the corporate network, I don’t think it has to be privately reported and fixed immediately.

Yet, I made a recommendation for introducing an additional configuration option to allow to transition to the updated protocol without causing backward compatibility issues. In fact, I’d go further and recommend using TLS/DTLS rather than a home-grown, AES-based scheme. Mutual authentication can be achieved through TLS mutual authentication rather than through a shared secret.

It’s satisfying to discover issues in popular software, especially when they are not written in your “native” programming language. And as a rule of thumb – encodings often cause problems, so we should be extra careful with them.

The post Discovering an OSSEC/Wazuh Encryption Issue appeared first on Bozho's tech blog.

OpenSSL Key and IV Padding

Post Syndicated from Bozho original https://techblog.bozho.net/openssl-key-and-iv-padding/

OpenSSL is an omnipresent tool when it comes to encryption. While in Java we are used to the native Java implementations of cryptographic primitives, most other languages rely on OpenSSL.

Yesterday I was investigating the encryption used by one open source tool written in C, and two things looked strange: they were using a 192 bit key for AES 256, and they were using a 64-bit IV (initialization vector) instead of the required 128 bits (in fact, it was even a 56-bit IV).

But somehow, magically, OpenSSL didn’t complain the way my Java implementation did, and encryption worked. So, I figured, OpenSSL is doing some padding of the key and IV. But what? Is it prepending zeroes, is it appending zeroes, is it doing PKCS padding or ISO/IEC 7816-4 padding, or any of the other alternatives. I had to know if I wanted to make my Java counterpart supply the correct key and IV.

It was straightforward to test with the following commands:

# First generate the ciphertext by encrypting input.dat which contains "testtesttesttesttesttest"
$ openssl enc -aes-256-cbc -nosalt -e -a -A -in input.dat -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c76' -iv 'FEDCBA987654321' -out input-test.enc

# Then test decryption with the same key and IV
$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c76' -iv 'FEDCBA987654321'
testtesttesttesttesttest

# Then test decryption with different paddings
$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c76' -iv 'FEDCBA9876543210'
testtesttesttesttesttest

$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c760' -iv 'FEDCBA987654321'
testtesttesttesttesttest

$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c76000' -iv 'FEDCBA987654321'
testtesttesttesttesttest

$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '07c07f68ea8494b2f8b9fea297119350d78708afa69c1c76' -iv 'FEDCBA987654321'
bad decrypt

So, OpenSSL is padding keys and IVs with zeroes until they meet the expected size. Note that if -aes-192-cbc is used instead of -aes-256-cbc, decryption will fail, because OpenSSL will pad it with fewer zeroes and so the key will be different.

Not an unexpected behavaior, but I’d prefer it to report incorrect key sizes rather than “do magic”, especially when it’s not easy to find exactly what magic it’s doing. I couldn’t find it documented, and the comments to this SO question hint in the same direction. In fact, for plaintext padding, OpenSSL uses PKCS padding (which is documented), so it’s extra confusing that it’s using zero-padding here.

In any case, follow the advice from the stackoverflow answer and don’t rely on this padding – always provide the key and IV in the right size.

The post OpenSSL Key and IV Padding appeared first on Bozho's tech blog.

Как да разкараме печатите от медицинските изследвания за прием в ясла

Post Syndicated from Bozho original https://blog.bozho.net/blog/3634

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

Ще коментирам обаче изследванията, и по-точно – удостоверяването на тяхната автентичност. Направихме всички изследвания, разпечатахме резултата от сайта на лабораторията, и ги занесохме заедно с другите документи. Само че – проблем. Трябвало да имат печати. Жена ми се разходи до лабораторията, сложиха ѝ един печат, обаче и това не беше достатъчно – трябвало да има втори, правоъгълен печат. Не можело да го приемат без него. Винаги бил така. А правоъгълният печат го имало само в централата на лабораторията – в другия край на града.

Попитах кой и защо го изисква – оказа се РЗИ (Столичната регионална здравна инспекция). Проведох около 15 разговора с 5-6 различни хора в РЗИ, изчетох приложимата нормативна уредба (Наредба 26, Наредба 3, и общо взето заключих три неща:

  • Това не е работа на никого. Може би на инспекторите.
  • Няма нормативно основание за изискване на печати
  • Могат да глобят яслата, ако няма печати, защото „разбира се, че ще ви върнат, като нямате печат“

Накрая се разходих до другия край на града, за да ми „набият“ правоъгълен печат. Но това не би трябвало да остава така – в ситуация на пандемия да обикаляме лаборатории и болници, увеличавайки риска от заразяване, без абсолютно никаква разумна причина за това.

Така че предприех следните мерки:

  • Писмо до Министерство на здравеопазването с предложения за нормативно уреждане на автентичността на медицински изследвания
  • Писмо до РЗИ да прекратят незаконосъобразните си практики
  • Писмо до Столична община, да установи ясни изисквания към детските ясли относно реквизитите на документи, които изискват

Целта е да има законосъобразни правила, директорите на яслите и инспекторите на РЗИ да знаят какви са правилата, а не да си ги измислят на място или да правят „както винаги са правили“, без да има нормативно основание за това.

Писмата до РЗИ и Столична община са скучни, но ще приложа писмото до Министерство на образованието, защото там са реалните предложения за промяна. Както сподели един от хората в РЗИ, съществува проблем с фалшиви изследвания, и „декларациите не работят“ (на моето предложение да спазват административнопроцесуалния кодекс и да приемат декларация за истинност на изследванията):

Чл. 43. Административният орган не може да откаже приемане на писмена декларация, с която се установяват факти и обстоятелства, за които специален закон не предвижда доказване по определен начин или с определени средства. [..]

Писмото до министъра изисква единствено нормативни изменения – с изключение на ал. 3, т. 3, останалите варианти са налице и в момента. Използването на електронни печати е по принцип правилния подход в дългосрочен план, но изисква надграждане на системи.

Уважаеми г-н Министър,

Във връзка с неписано правило Столичната РЗИ да изисква два различни печата върху изследвания за приемане на деца (по реда на чл. 20 от Наредба 26 от 18.11.2008 за устройството на дейността на детските ясли и детските кухни и здравните изисквания към тях), и отчитайки:
1. Голямото неудобство за родители в това да бъдат куриери на администрацията и в 21-ви век да обикалят за различни видове печати, особено в контекста на пандемия.
2. Риска от предоставяне на фалшиви изследвания
3. Факта, че повечето лаборатории имат онлайн системи за предоставяне на резултатите от изследвания
4. Усилията за въвеждане на електронно здравеопазване

бих искал да предложа следното изменение на Наредба 26:

В чл. 20 се създават нови алинеи 3-5:
(3) Автентичността на изследванията по ал. 1, т.3-5 се удостоверява от лабораторията, извършила изследването, по един от следните начини:
1. чрез възможност за проверка с телефонно обаждане на база на уникален идентификатор на изследването. Телефон за контакт и номер на изследването трябва да са посочени в документа с резултатите.
2. чрез предоставяне от страна на родителите на данни за достъп до онлайн система за проверка на резултата
3. чрез електронен печат на лабораторията върху електронен документ с резултатите, по смисъла на Регламент (ЕС) № 910/2014 на Европейския парламент и на Съвета от 23 юли 2014 г. относно електронната идентификация и удостоверителните услуги при електронни трансакции на вътрешния пазар и за отмяна на Директива 1999/93/ЕО (ОВ, L 257/73 от 28 август 2014 г.)
3.
(4) Резултатите от изследванията по ал. 1, т.3-5 се приемат на хартиен носител и по електронен път, на адрес на електронна поща или чрез системата за сигурно електронно връчване по смисъла на § 1, т. 31 от допълнителните разпоредби на Закона за електронното управление.
(5) Резултатите от изследванията по ал. 1, т.3-5 се съхраняват за срок от 12 месеца, след което се унищожават.

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

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

С уважение,
Божидар Божанов

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

„§ 1а. (1) Във връзка с административното обслужване на гражданите и юридическите лица административните органи, лицата, осъществяващи публични функции, и организациите, предоставящи обществени услуги не могат да изискват полагане на печат върху документ на хартиен носител за удостоверяване на авторството.
(2) Авторството на документ по ал. 1 се удостоверява от неговия издател чрез саморъчен подпис. Документът съдържа информация за имената на лицето, което го е издало, качеството и длъжността, в които действа, както и основанието на неговата представителна власт.
(3) Органите, лицата и организациите по ал. 1 не могат да отказват приемане на документ от граждани и юридически поради липса на поставен печат.
(4) За неизпълнение на задълженията по ал. 1 и 3 на отговорните длъжностни лица се налага административнонаказателна санкция по чл. 305 от Административнопроцесуалния кодекс.“

(Следват изменения на двайсетина закона, които в момента изискват печат под някаква форма, които ще ви спестя, – такъв законопроект Демократична България ще може да внесе в парламента след няколко месеца.)

Защо се занимавам с нещо толкова дребно? Нали вече записахме детето, повече едва ли ще имаме тоя проблем?

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

Материалът Как да разкараме печатите от медицинските изследвания за прием в ясла е публикуван за пръв път на БЛОГодаря.

ElasticSearch Multitenancy With Routing

Post Syndicated from Bozho original https://techblog.bozho.net/elasticsearch-multitenancy-with-routing/

Elasticsearch is great, but optimizing it for high load is always tricky. This won’t be yet another “Tips and tricks for optimizing Elasticsearch” article – there are many great ones out there. I’m going to focus on one narrow use-case – multitenant systems, i.e. those that support multiple customers/users (tenants).

You can build a multitenant search engine in three different ways:

  • Cluster per tenant – this is the hardest to manage and requires a lot of devops automation. Depending on the types of customers it may be worth it to completely isolate them, but that’s rarely the case
  • Index per tenant – this can be fine initially, and requires little additional coding (you just parameterize the “index” parameter in the URL of the queries), but it’s likely to cause problems as the customer base grows. Also, supporting consistent mappings and settings across indexes may be trickier than it sounds (e.g. some may reject an update and others may not depending on what’s indexed). Moving data to colder indexes also becomes more complex.
  • Tenant-based routing – this means you put everything in one cluster but you configure your search routing to be tenant-specific, which allows you to logically isolate data within a single index.

The last one seems to be the preferred option in general. What is routing? The Elasticsearch blog has a good overview and documentation. The idea lies in the way Elasticsearch handles indexing and searching – it splits data into shards (each shard is a separate Lucene index and can be replicated on more than one node). A shard is a logical grouping within a single Elasticsearch node. When no custom routing is used, and an index request comes, the ID is used to determine which shard is going to be used to store the data. However, during search, Elasticsearch doesn’t know which shards have the data, so it has ask multiple shards and gather the results. Related to that, there’s the newly introduced adaptive replica selection, where the proper shard replica is selected intelligently, rather than using round-robin.

Custom routing allows you to specify a routing value when indexing a document and then a search can be directed only to the shard that has the same routing value. For example, at LogSentinel when we index a log entry, we use the data source id (applicationId) for routing. So each application (data source) that generates logs has a separate identifier which allows us to query only that data source’s shard. That way, even though we may have a thousand clients with a hundred data sources each, a query will be precisely targeted to where the data for that particular customer’s data source lies.

This is key for horizontally scaling multitenant applications. When there’s terabytes of data and billions of documents, many shards will be needed (in order to avoid large and heavy shards that cause performance issues). Finding data in this haystack requires the ability to know where to look.

Note that you can (and probably should) make routing required in these cases – each indexed document must be required to have a routing key, otherwise an implementation oversight may lead to a slow index.

Using custom routing you are practically turning one large Elasticsearch cluster into smaller sections, logically separated based on meaningful identifiers. In our case, it is not a userId/customerId, but one level deeper – there are multiple shards per customer, but depending on the use-case, it can be one shard per customer, using the userId/customerId. Using more than one shard per customer may complicate things a little – for example having too many shards per customer may require searches that span too many shards, but that’s not necessarily worse than not using routing.

There are some caveats – the isolation of customer data has to be handled in the application layer (whereas for the first two approaches data is segregated operationally). If there’s an application bug or lack of proper access checks, one user can query data from other users’ shards by specifying their routing key. It’s the role of the application in front of Elasticsearch to only allow queries with routing keys belonging to the currently authenticated user.

There are cases when the first two approaches to multitenancy are viable (e.g. a few very large customers), but in general the routing approach is the most scalable one.

The post ElasticSearch Multitenancy With Routing appeared first on Bozho's tech blog.

Is It Really Two-Factor Authentication?

Post Syndicated from Bozho original https://techblog.bozho.net/is-it-really-two-factor-authentication/

Terminology-wise, there is a clear distinction between two-factor authentication (multi-factor authentication) and two-step verification (authentication), as this article explains. 2FA/MFA is authentication using more than one factors, i.e. “something you know” (password), “something you have” (token, card) and “something you are” (biometrics). Two-step verification is basically using two passwords – one permanent and another one that is short-lived and one-time.

At least that’s the theory. In practice it’s more complicated to say which authentication methods belongs to which category (“something you X”). Let me illustrate that with a few emamples:

  • An OTP hardware token is considered “something you have”. But it uses a shared symmetric secret with the server so that both can generate the same code at the same time (if using TOTP), or the same sequence. This means the secret is effectively “something you know”, because someone may steal it from the server, even though the hardware token is protected. Unless, of course, the server stores the shared secret in an HSM and does the OTP comparison on the HSM itself (some support that). And there’s still a theoretical possibility for the keys to leak prior to being stored on hardware. So is a hardware token “something you have” or “something you know”? For practical purposes it can be considered “something you have”
  • Smartphone OTP is often not considered as secure as a hardware token, but it should be, due to the secure storage of modern phones. The secret is shared once during enrollment (usually with on-screen scanning), so it should be “something you have” as much as a hardware token
  • SMS is not considered secure and often given as an example for 2-step verification, because it’s just another password. While that’s true, this is because of a particular SS7 vulnerability (allowing the interception of mobile communication). If mobile communication standards were secure, the SIM card would be tied to the number and only the SIM card holder would be able to receive the message, making it “something you have”. But with the known vulnerabilities, it is “something you know”, and that something is actually the phone number.
  • Fingerprint scanners represent “something you are”. And in most devices they are built in a way that the scanner authenticates to the phone (being cryptographically bound to the CPU) while transmitting the fingerprint data, so you can’t just intercept the bytes transferred and then replay them. That’s the theory; it’s not publicly documented how it’s implemented. But if it were not so, then “something you are” is “something you have” – a sequence of bytes representing your fingerprint scan, and that can leak. This is precisely why biometric identification should only be done locally, on the phone, without any server interaction – you can’t make sure the server is receiving sensor-scanned data or captured and replayed data. That said, biometric factors are tied to the proper implementation of the authenticating smartphone application – if your, say, banking application needs a fingerprint scan to run, a malicious actor should not be able to bypass that by stealing shared credentials (userIDs, secrets) and do API calls to your service. So to the server there’s no “something you are”. It’s always “something that the client-side application has verified that you are, if implemented properly”
  • A digital signature (via a smartcard or yubikey or even a smartphone with secure hardware storage for private keys) is “something you have” – it works by signing one-time challenges, sent by the server and verifying that the signature has been created by the private key associated with the previously enrolled public key. Knowing the public key gives you nothing, because of how public-key cryptography works. There’s no shared secret and no intermediary whose data flow can be intercepted. A private key is still “something you know”, but by putting it in hardware it becomes “something you have”, i.e. a true second factor. Of course, until someone finds out that the random generation of primes used for generating the private key has been broken and you can derive the private key form the public key (as happened recently with one vendor).

There isn’t an obvious boundary between theoretical and practical. “Something you are” and “something you have” can eventually be turned into “something you know” (or “something someone stores”). Some theoretical attacks can become very practical overnight.

I’d suggest we stick to calling everything “two-factor authentication”, because it’s more important to have mass understanding of the usefulness of the technique than to nitpick on the terminology. 2FA does not solve phishing, unfortunately, but it solves leaked credentials, which is good enough and everyone should have some form of it. Even SMS is better than nothing (obviously, for high-profile systems, digital signatures is the way to go).

The post Is It Really Two-Factor Authentication? appeared first on Bozho's tech blog.

Хронология на липсващата електронна идентификация

Post Syndicated from Bozho original https://blog.bozho.net/blog/3627

Електронна идентификация (по-конкретно националната схема за електронна идентификация), която е и кокошката, и яйцето на електронното управление, все още я няма. Ето кратка хронология:

  1. В края на 2016 г. е готово всичко – има закон, правилник, осигурено европейско финансиране, техническа спецификация и документация по ЗОП (Закона за обществените поръчки).
  2. Процедурата е пусната… и спряна в края на лятото на 2017 г (в следствие на няколко фалшиви обжалвания пред КЗК от фирми, чиято дейност няма нищо общо с поръчката).
  3. Август 2018 (1г по-късно) електронната идентификация е пусната като част от голямата поръчка за личните карти.
  4. Поради избора на усложнена процедура свързана с класифицирането на части от поръчката (на две стъпки – одобрение на кандидати, и след това поръчка), изпълнител е избран в края на април тази година. Към момента доколкото знам тече процедура по обжалване на решението.
  5. Очаква се до края на годината (ако обжалванията паднат) да бъде сключен договор с изпълнителя и той да започне работа
  6. Сроковете за eID по спомен са около 18 месеца, т.е. в края на 2022 г. ще имаме система. Чиято спецификация е писана 6 години и половина по-рано и вече не е напълно актуална (напр. вече е достатъчно сигурно да се записва частен ключ в мобилен телефон с Android или iOS; през 2016 г. не беше).

Защо е толкова важна електронната идентификация (за която съм писал доста)? Дългият отговор е в тази 40-минутна презентация от 2016г. Краткият отговор е: защото гражданите нямат налично и удобно средство да се идентифицират онлайн пред държавата. Електронните подписи, които в преходния период (удължен от „2 години“ на „докато стане“) трябва да вършат тази работа имат редица проблеми.

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

Второ – струват пари и поради това (без значение колко са евтини), не може да се постигне масовост сред гражданите. Така дори да има е-услуги, хората няма с какво да ги ползват. Пример – опашките пред НОИ през март, след като НОИ пусна доста услуги онлайн, но хората трябваше да се наредят, за да си вземат ПИК. При електронната идентификация положението е „апетитът идва с яденето“. И трябва критична маса хора просто да разполагат със средството за идентификация в джоба си, за да потеглят нещата. Примери за това много, като любимият ми е Естония срещу Финландия. Естония дава на всички безплатна електронна идентификация, Финландия я прави опционална и платена. 15 години по-късно Естония „изнася“ електронно управление за Финландия, които изостават значително (опростявам историята, но е горе-долу така).

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

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

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

Така при напълно готова документация и финансиране, цял мандат не стига дори да се започне работа по най-ключовата система за електронното управление. Всички останали институции (вкл. ЦИК за пилотното дистанционно електронно гласуване) пък се оправдават „ами тя е в МВР системата, ние нищо не можем да направим“.

Та така за управленския капацитет, визията и стратегическите проекти за модернизация на страната. Кой щял да дойде след оставката.. ‘де да знам, дано някой, дето да може за един мандат поне договор да сключи.

Материалът Хронология на липсващата електронна идентификация е публикуван за пръв път на БЛОГодаря.

Наръчник за правилно протестиране

Post Syndicated from Bozho original https://blog.bozho.net/blog/3618

Протестите са хубаво нещо по принцип, обаче… тия точно не! Сега ще ви обясня как е правилно да се протестира, така че всички да са доволни.

Правилно протестиращият не иска просто оставка, защото така не е достатъчно ясно какво точно иска. Правилно протестиращият трябва да си носи в джоба лист А4 със законодателни изменения, които преди това е синхронизирал с всички останали на площада. Иначе за какво протестира?

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

Правилно протестиращият трябва да каже кой ще дойде след оставката. Нали е там с много хора – да съберат пари за социология и да имат готов отговор. После изборите ще са проформа.

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

Правилно протестиращият няма предварително подготвен плакат, защото това значи, че някой му плаща. Най-вероятно някой олигарх, то кой друг има пари у нас.

Правилно протестиращият не пие бира. Бира се пие само на маса, а не като тия пропадняци на крак. Това е признак на много ниска култура и липса на национално самосъзнание.

Правилно протестиращият протестира стриктно извън работно време. Противното би значело, че е безработен лентяй.

Правилно протестиращият знае как е било на протестите 90-та година и знае как се прави. Но в същото време трябва да е млад, за да може премиерът да каже една хубава дума за него.

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

Правилно протестиращият не се разхожда, защото с разходки нищо не се постига.

Правилно протестиращият не прави пърформанси. Не свири на пиано, не се облича театрално, не прави флашмобове. С пърформанси властта няма да падне!

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

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

Правилно протестиращият не се намира в радиус от 100 метра с някой неправилно протестиращ, защото носи отговорност за действията му.

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

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

Общо взето, правилно протестиращият трябва да отиде в 18:30 пред някоя сграда, да поздрави полицията, да надуе свирка десетина пъти, да викне „Оставка“, да си тръгне към 21 ч., преди да са дошли провокаторите, а на другия ден да напише писмо на управляващите какви точно промени иска. Всичко друго е напълно недопустимо и дискредитира и омаскарява иначе легитимния граждански протест, който всички бихме подкрепили!

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

Пък и защо да пада легитимно избрана власт? Никакви корупционни скандали, зависимости на премиера, нарушаване на законови и етични стандарти, не могат да са достатъчен аргумент срещу демократично избрана власт. Милион и двеста хиляди избиратели са казали, че искат тези управляващи да дават поръчки и влияние на Пеевски, Доган и други обръчи и да пратят правилните хора във ВСС, които да изберат Гешев. Тези хора на площада са по-малко от милион и двеста хиляди!

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

Bulk vs Individual Compression

Post Syndicated from Bozho original https://techblog.bozho.net/bulk-vs-individual-compression/

I’d like to share something very brief and very obvious – that compression works better with large amounts of data. That is, if you have to compress 100 sentences you’d better compress them in bulk rather than once sentence at a time. Let me illustrate that:

public static void main(String[] args) throws Exception {
    List<String> sentences = new ArrayList<>();
    for (int i = 0; i < 100; i ++) {
        StringBuilder sentence = new StringBuilder();
        for (int j = 0; j < 100; j ++) { 
          sentence.append(RandomStringUtils.randomAlphabetic(10)).append(" "); 
        } 
        sentences.add(sentence.toString()); 
    } 
    byte[] compressed = compress(StringUtils.join(sentences, ". ")); 
    System.out.println(compressed.length); 
    System.out.println(sentences.stream().collect(Collectors.summingInt(sentence -> compress(sentence).length)));
}

The compress method is using commons-compress to easily generate results for multiple compression algorithms:

public static byte[] compress(String str) {
   if (str == null || str.length() == 0) {
       return new byte[0];
   }
   ByteArrayOutputStream out = new ByteArrayOutputStream();
   try (CompressorOutputStream gzip = new CompressorStreamFactory()
           .createCompressorOutputStream(CompressorStreamFactory.GZIP, out)) {
       gzip.write(str.getBytes("UTF-8"));
       gzip.close();
       return out.toByteArray();
   } catch (Exception ex) {
       throw new RuntimeException(ex);
   }
}

The results are as follows, in bytes (note that there’s some randomness, so algorithms are not directly comparable):

Algorithm Bulk Individual
GZIP 6590 10596
LZ4_FRAMED 9214 10900
BZIP2 6663 12451

Why is that an obvious result? Because of the way most compression algorithms work – they look for patterns in the raw data and create a map of those patterns (a very rough description).

How is that useful? In big data scenarios where the underlying store supports per-record compression (e.g. a database or search engine), you may save a significant amount of disk space if you bundle multiple records into one stored/indexed record.

This is not a generically useful advice, though. You should check the particular datastore implementation. For example MS SQL Server supports both row and page compression. Cassandra does compression on an SSTable level, so it may not matter how you structure your rows. Certainly, if storing data in files, storing it in one file and compressing it is more efficient than compressing multiple files separately.

Disk space is cheap so playing with data bundling and compression may be seen as premature optimization. But in systems that operate on large datasets it’s a decision that can save you a lot of storage costs.

The post Bulk vs Individual Compression appeared first on Bozho's tech blog.