[ Full list of blog posts ]
Watched more talks...
So much bad 'secure' code. You shouldn't expect much from normal programs, hehe.
Bootstrapping a slightly more secure laptop - Amazing talk about how deep exploits and malware go in the hardware. As expected, current systems are littered with different serious attack vectors.
Law Enforcement Are Hacking the Planet - Yep, USA can 'legally' hack any computer, anywhere. Let's watch the World Police again! As well as they can decoy sites, while committing actual serious crimes while doing it. It also makes it very clear that there's no "cyber virtual world", it's actually very real and physical.
Shut Up and Take My Money! - This pretty much proves the point I've been raising repeatedly. As long as user authentication sucks, there's no way to make things secure. Almost all 2FA schemes I've seen are more or less bad. Good ones are extremely rare. It's not ok to give generic authentication token. It's just as stupid as using static password. The token should naturally be 'command / action' specific at specific time. Aka cryptographic signature for that particular transaction now. Otherwise the user can 'authorize' anything at all, without even knowing it. Most of 2FA schemes are just like 'signing blank contract'. Fill in whatever you want to later. - Real-time Transaction Manipulation and user / automation system misleading is very real and works great. Awesome talk, no hammering protection, trivial brute force attacks in minutes etc. Totally laughably fun talk, I mean in terms of security fails. But truth is that security is usually totally amazingly bad. "Banking by design", laughable security. Hahaha. I'm clapping too, great! N26 Security. Only amazing thing is that when the issues were reported, they seemed to understand that there is an problem. Often they don't. Which makes it even more fun. This was absolutely great talk.
Pegasus internals - Neat espionage software payload, vulnerabilities and exploits. Kernel exploit on each boot.
A Data Point Walks Into a Bar - Wonderful talk about data visualizations. Data driven design.
Make the Internet Neutral Again - EU net neutrality rules and laws. Hmm, I don't know if zero rating is a real problem. I can see many benefits for it too. These are complex questions. European commission regulation.
Untrusting the CPU - Secure Access Module (SAM) -
What's It Doing Now? - The Role of Automation Dependency in Aviation Accidents - Interesting talk, how systems can confuse, disinform and mislead users.
Dieselgate – A year later - Interesting talk about Volkswagen and court cases & differences between American (US) and European (EU, Germany) justice systems. Europe lacks class action law suits.
Make Wi-Fi fast again - Nice talk, 802.11n comparison included. Beam forming, QAM, BPSK, QPSK. Multi-User MIMO (MU-MIMO). Beam forming. Phased Array Antenna. Multiple data streams. Measuring Radio Channel. Limited WiFi / WLAN bandwidth. 80 & 160 MHz channel widths basically unavailable.
Lockpicking in the IoT - Bluetooth Low-Energy (BLE / BTLE) might be dangerous. - Security hardware & software, is ridiculous. So full of absolutely laughable fails. I love talks which really make you laugh. Because security is just so laughable. Nothing new. But the BTLE putton pusher made me laugh. It's "IoT" kit for any device with button(s) to make it IoT and Internet compatible. Decompiling applications. Downloading firmware. Modifying firmware, hacking locks. Totally awesome talk. Hard coded fixed encryption keys. That 8 months to fix simple issues, typical. Laugh! And the final magnet part, omfg and lulz rotfl. Great, that's just great. Really loved this talk. The NDA comments were really true too. Why they want to ship shitty vulnerable products. How about fixing those and not worrying someone spilling the secret sauce?
There will be more stuff later, on subsequent posts.
Generic background information for this post and SHA-1 being broken can be found from this site: Shattered.iokw: Mozilla Thunderbird Enigmail, GnuPG, PGP, GPG, SHA1, SHA256, SMIME, S/MIME, hash, digest, signature, signatures, configuration, settings, set, configure, algorithm, preference, preferred, preference, security, privacy, email encryption, signing, data, email, configuring enigmail to use sha256, configuring GnuPG to use SHA256.
Simply put: Well, they've done it. SHA1 collision generated on purpose.
SHA1 has been on way out for a decade. But now it's finally time to retire it on cases where security matters. It still can be used as hash algorithm, as long as you just remember it isn't secure one. I'm using often some extremely simple algorithms like adler32 or crc32 to generate 'hashes'. Point is just to generate short version of data, which is highly likely to produce another outcome if data is being changed.
As happened with MD5, it's probable that massive increase in attack strength expected in near future. So if it's now considered to be broken, soon it will be much more broken.
It stands for SHA256. Note that the = is just indicating key and value separation. The equal sign shouldn't be used.
These tests were made from command-line / shell.
Only when digest-algo SHA256 option is enabled then output will be using
As you can notice I've tested everything using GnuPG v1 and GnuPG v2.
Now the command line --clearsign produces right output. Yet interestingly that won't affect Enigmail.
Also my own default key sets SHA256 as preference. But that won't clearly affect signing by default with that key. Which would have been nice?
Just to make sure that the recipient preferences do not affect the outcome. I've disabled the digest-algo option and tried using -r when clear signing.
GnuPG just warns that -r without -e doesn't encrypt the message. But still the digest-algo preferences set by -r user's preferences won't affect the digest algorithm. Hmph.
So, just go and add digest-algo SHA256 in your gpg.conf if it isn't there already.
But how do I specify the hash algorithm for Enigmail?
Quote from Enigmail Wiki documentation:
"Enigmail relies by default on GnuPG for selecting the hash (digest) algorithm. From GnuPG, the hash algorithm can be specified in the file gpg.conf using the parameter digest-algo hash_algorithm."
Yet for some interesting reason, the digest-algo setting didn't actually affect Enigmail.
Other values for mimeHashAlgorithm with Enigmail:
0: Automatic selection, let GnuPG choose (default, recommended)
After changing the settings, I sent email to myself and verified that the setting actually affects the mesages being sent out:
If settings aren't correct it'll say:
And when using S/MIME:
Link: ZeroNet.ioSo nothing much, I'll hope bright future for Zeronet. I've been huge fan of peer-to-peer (P2P) technologies. As well as anonymous & freedom of speech platforms. So, future will tell how Zeronet is going to do. Based on history, it's not going to do well. P2P technology history is pretty bleak. Just like with web sites. Only extremely, really extremely small portion will make any success. Others will be forgotten so that nobody remembers or cares about those after a few years.
First I played a bit with ZeroNet and yes, it seems to be practically working. In some cases the response times are even surprisingly low. It's much more responsive than what you would expect from such system. So it works nicely after the initial synchronization.
Some of the opening statements sound really dubious, from practical point of view. Let's not yet condemn them.
Distributed approach, caching, censorship free, incremental updates and Tor support are really nice concepts. Of course the synchronization can be made in very efficient or inefficient way. That remains to be seen.
Easy zero configuration setup is wonderful. I personally dislike programs which require complex setup.
I'm really curious about the SQL database support. But I'll hope I'll find more out about that bit later. Generally data updates have been exactly the problem with distributed systems. It wasn't documented in detail. I guess they're at least trying to do it reasonably efficiently. Yet there are of course spam issues etc, probably. But those are concerns with any site which allows user content.
"No torrent-like, file splitting for big file support" - This is bit confusing. I thought it was using BitTorrent? So why multi peer parallel downloads wouldn't work? Or do they mean downloading 'individual files' from larger bundle? Don't know.
They also mentioned they're not trying to compete with Freenet and I2P and they're not going to replace the current client - server based model. Which are just joyfully sane conclusions.
It seems that the OVH doesn't know how IPv6 address zero compression works.Zero compression can be only used once per address. So if there are addresses like
I'll recommend that they'll read RFC 5952 section 2.1 - and RFC 4291 section 2.2.
Leading Zeros in a 16-Bit Field and Text Representation of Addresses.
Zero compression allows compression one more full zero blocks to :: .
Lead zero compression allows dropping leading zeros within address block.
Example of full address:
Only addresses 16 bytes aka 128 bits, are full addresses.
Full blocks of 0's have been omitted, with :: .
Lead zero compression:
Leading zeros within each block have been omitted.
Both methods combined, most compact representation:
Examples above are all structurally correct.
That address seems to be ok above? Yet it isn't. Why? Because it seems that guys at OVH do the zero compression incorrectly.
The address is shown as above, even if it's supposed to be uncompressed:
And as compressed:
That's right, for some unknown reason they're taking one trailing zero from that 3100 block and omitting it with :: structure. That lost zero is high lighted with red color. I suspect they've got buggy code or something dealing with the address compaction. This mistake seems to be systematic in their management console portal, in different views. I got rid of all IPv6 issues so far, by adding that one missing zero to configurations manually. Same mistake applies to the host IP address as well as the default gateway address. Earlier OVH used uncompressed addresses in the management console, but they implemented the address compression incorrectly. - Lulz.
This interestingly shows the 'standard it security & reliability concepts'. Nobody gives a bleep, if it's working or if the information is correct. Unfortunately I see this happening daily, in all kind of situations. Disinformation is extremely wide spread and nobody cares about the fact, that facts are completely wrong.
Other funny remarks: I also found several sites advertising IPv6 address expansion to full 128 bit notation. Yet even that site worked incorrectly. It seems that they'll only expand the zero compression, and do not correctly expand the lead zero compression. Yet Python does all that correctly.
OVH - Thank you for providing disinformation to your customers and wasting my time for pointless troubleshooting and blog posts. You know, it took me a while to figure out WTF is wrong. And then you complain that the HD is overloaded? Well, it is. If you disinform and mislead customers, it's quite natural that most customers don't get what's wrong.
Edit: Continued three days after noticing the issue. They haven't even bothered to fix the issue yet. OVH's JSON API does give correct (uncompressed / exploded / expanded) address information. But the management console still compresses addresses incorrectly. Other people have confirmed the issue on Twitter as well as I've confirmed it using several different OVH accounts. It's just as I said and nobody bothers even to care about that. - Also added color highlighting. To examples.
Made up IPv4 example to clarify things
It also seems that the IPv6 example is hard to grasp for several people. Let's make IPv4 example if it would be more familiar for everyone. This is made up example, but shows the concept.
JSON API would show full address:
And the management console would show compressed address:
Python & IPv6
This is also reason why using Python standard library ipaddress and similar functions are very nice and get the job done correctly.
kw: OVH, IPv6, fail, addressing, zero compression, won't work, no Internet, issue, problem, fix, connectivity, can't ping gateway, no route to host, default gateway unreachable, IPv6, Internet address addressing, python, representation, human readable, spacing, colon, encoding, ASCII, 85, networking, issues.
What could possibly go wrong with <insert x86 instruction here>? - ASLR, CPU cache layers, cache line, cache attacks, covert channels, flush+reload attack, prime+probe attack, SSH connection over CPU cache covert channel. Awesome. Crypto side-channel attack using cache timings. T-Tables, Bouncy Castle, Android. Flush+Flush attack. Timing leakage. Pre-fetch, Address Translation, Page Directory. Kernel Addres Space Layout Randomization (KASLR). Virtual address space -> Physical memory direct-physical map. Translation-level oracle. Rowhammer / Row hammer - attacks on privileged addresses.I'll be posting 33C3 notes as long as I've finished watching all the interesting talks. These will be probably posted before the normal weekly post.
The Global Assassination Grid: Espionage, Killing, National Security. Sounded like the Drone Operations Team is actually very well informed, compared to situation where you just turn up with gun in some random site and have to make decisions without all that background & analytical information. Doesn't sound that bad at all. Of course mishaps happen at times, but in general. That's much better than what it could be. DDS Sometimes media makes it seem like they would be just picking random targets from video feed. But that's not true, there' much more background intelligence behind it. Where, What, Why, etc. Intelligence Surveillance & Reconnaissance (ISR) network. Target Identification & Acquisition. Wide-band Global Satellites (WGS). Autonomous systems. Counter-surveillance, Transparency. Loitering weapon systems. Weaponized Drones. - Documentary movie about this topic is coming out and that's what I'm going to watch for sure when it's out.
Reverse Engineering Outernet - Outernet @ Wikipedia. That's pretty much legacy tech, but interesting project still.
Everything you always wanted to know about Certificate Transparency - HTTPS, Certificate Authority (CA), Online Certificate Status Protocol (OCSP), Vulnerabilities, ENISA, Implementation issues, Deployment issues, HTTPS / TLS / Drown Attack, CipherSuite mess, Signed Certificate Timestamp (SCT). Hash tree with signed tree head (STH). History proves that Certificate Authorities can't be trusted! /ct/v1/get-sth - crt.sh - Cert Watch
The Fight for Encryption in 2016 - Crypto fight in the Wake of Apple v. FBI. - The Encryption Debate. - Defend Encryption / EFF - Privacy vs Security vs Security - This is actually extremely intersting talk. This is what we've (at least I'm) been waiting for. - Hacking & Cracking mobile phones with several different attack vectors and exploits. Mythical "Secure Golden Key". - UK Snooper's Charter. - European Court of Justice. - Gag Orders. - Investigatory Powers Act - Everyone's should use strong encryption all the time.
Predicting and Abusing WPA2/802.11 Group Keys - Tornado Attack WPA-TKIP session key recovery - Broadcast group frame encrypted using Group Keys. - Flawed RNG - Weakening encryption using MITM to force RC4 encryption during handshake - Hidden terminal problem - Group Temporal Key (GTK) - Following bad standard, is bad practice. It's better to implement your own than follow the standard. - "random enough", that's well said. - Group Master Key (GMK) - Nice, the demo worked also. - Hole 196 check - Classic ARP poison - RC4 NOMORE - Don't put extremely bad example code in specification. - AP should ignore group-addressed frames.
My own comment about previous talk 802.11n prevents use of TKIP, probably to prevent just this attack.
The DROWN Attack - Additional information at DrownAttack.com - Funny, people still usign and loving SSLv2. Well, not a real surprise at all. Nobody cares. - PreMasterSecret (PMS) - TLS RSA handshake - Bleichenbacher's Attack - Shared Key Among Protocols / Ports, that's really bad. Generating new keys isn't that expensive after all. Ciphersuite selection bug. It's also obvious that crappy code is just everywhere, even in the most critical code sections. Special DROWN. Lol, ridiculusly bad bugs. Generig DROWN 2^40. Special DROWN requires only 15 probe connections and on average 15*128=1920 trial encryptions. That's just like awww and it works with older versions of OpenSSL. Ancient SSLv2 breaks current TLS. Totally amazing talk.
Some personal random thoughts about easycrypt.co .
If not using EasyCrypt App / Webmail, then you don't (of course) see the encrypted message content. That's something which is natural and totally expected.
Limited to specific email service provider? - They say you can use any provider. But that's not probably true. I assume they'll be using IMAP and other protocols, which aren't actually provided by "any" provider. Of course you can use copy-paste methodology, it works. But it's annoying. Yet it's universal.
Ok, PGP / OpenPGP support, that's clear and I were kind of waiting to see it. Because they said 'external' users, it sounded like they would be using some common technology like S/MIME or OpenPGP 'internally' too.
Now they said it, IMAP required, yep. I guessed it too. So service can't be practically used with email providers which do not provide IMAP / SMTP support.
EasyCrypt plugin for popular email clients. Ok, now it's interesting, how's that different from standard PGP features integrated in many existing email apps already?
Tor / .onion support, nice.
Secret key is stored by them, and protected using a passphrase. Meaning that they've got access (if required) to everything required to decrypt the data. That's naturally a very weak spot. Even if they wouldn't store the data, they'll have it temporarily. And therefore also have access to it + encryption information, if required.
You can import your private key to PGP client. That's clear, so basically EasyCrypt is just 'alternate user interface' for 'Cloud integrated PGP'. Clear, check.
'Disclose my keys', well. Technically you're not unable. You can modify code to store unencrypted data or to store data required for decrypting data, or encrypt data for multiple recipients, etc. This is just why any single service provider claiming to make secure applications is usually bad idea. There's no way for normal users to know, what happens when they give their pass phrase to an app, is it native or a webapp doesn't really make any difference. Both can be covertly modified by powerful attacker or the authors, if and when required.
Previous things also mean that the metadata claim was isn't totally solid. Because message is transmitted over normal SMTP / email delivery platform, which means that the metadata is available, at least partially.
Time when emails are sent and the size, ahem. Maybe you forgot to mention source and destination. Those aren't directly available, but probably can be statistically correlated later by powerful advisory if required.
Next bullet is interesting. They claim that no email addresses, no IP addresses or other data / metadata will be leaked. This is something which probably will be answered in the Under the Hood section. At his point my guess is that the messages will be sent to some kind of a gateway taking care of the processing, so there's metadata but it's pretty useless. I'm curious to find out the rest. - I'll keep reading.
The OpenPGP statement sounds correct. That's just what I were kind of expecting. 'Full' metadata leak, when using OpenPGP alone.
Using a pseudonym with existing address. This is probably related to the gateway concept. Let's see.
Anonymous statement is interesting. Waiting to see the Under the Hood section. - When they say 'identity' will be hidden. It's a great question what's defined as 'identity'.
They talk about SSL, how about talking about TLS, not about SSL. PFS is good, but that's not alone probably enough. Also mentioning the CA doesn't really matter, because the problem isn't the CA alone, but it's the whole mess of certificate authorities. This is something which is widely covered and known. And I've written about it several times earlier.
Some of my questions weren't addressed, but they made me really interested to read the next section.
Ok, Tor is also a fundamental part of how EasyCrypt works.
Encryption: '4096 bit encryption', ehh... It doesn't mean anything. Ok ok, of course I know in this case it means 4096 RSA (because of OpenPGP), but in general. I don't ambiguous like statements like that. I've blogged about that earlier too.
Yes, keys can be decrypted on any device, as long as you know the password or able to guess or bruteforce it. Also as said, there's no way for the user knowing, if the data is properly encrypted or not, and or if the encryption key / password is being leaked.
Yet I like their option for external public key registration, I could do that right now. There's nothing wrong with it. Yet for something I would really need OpenPGP for, I wouldn't probably use EasyCrypt for. But that's totally personal paranoid tinfoil hat opinion. Nor I would use any of my regular workstations or phones.
This should be the interesting part.
Wow, the first sentence / paragraph is cool and confusing at the same time.
Minimization of metadata is always good.
Several terms are bit ambiguous. 'Email pseudonym', 'Anonymous Cryptographic proof'. More details plz. I of course do understand the concepts, but details would be very interesting to see.
Sending data over Tor network indicates participation to Tor network as well as mount of data transferred and timings, which is metadata. Yet of course it's not as bad as the usual email metadata.
Yet again, being anonymous might make blocking different kind of content, abuse & attacks lot harder.
Appending recipient information to the encrypted message, leaves it open if the recipient information is encrypted. From the text it seems that it isn't. Yet Tor does encrypt data for transport. Are additional layers necessary, or being used. I don't know. I personally might wrap that data with EasyCrypts public key and additional OpenPGP encryption, before transferring over Tor. Probably that's just overkill, but it wouldn't hurt too much.
As we're talking about metadata. Also the amount of data and timing information is obviously known to EasyCrypt.
bcrypt isn't recommended to be used. Yet scrypt is also pretty new. Generally it seems that using scrypt over bcrypt should be preferred.
Here's also the weak link, yes, password is processed in browser. It can be stolen from browser, or it can be sent without protecting it properly before transmission, plus countless other issues by real hackers. Like the end device security etc. Yet those apply to all encryption applications. These were just the extremely simple obvious attack vectors.
It's not defined exactly how the private key is encrypted / protected, except that it's using the users password. I would assume it's the OpenPGP standard protection, which should be ok.
To sum it up, the users password is the weak link on multiple levels. If and when required, it's trivial to break system security totally transparently, so that nobody likely notices anything.
Omitting information is sometimes a blessing, sometimes it makes things hard to follow. I often like very compact documents. Questions which follow from the reader, also usually clearly indicates how well they've understood the (purposefully) missing obvious parts.
Mixing practical solution: With nerd cypherpunk tech, free and anonymous is usually a hard mix to get right. - Problems are almost inherently guaranteed. - No this doesn't mean it wouldn't work. But it could be very hard or practically impossible to get it right and manage the system and abuse.
Just as a remark, I haven't never ever received PGP, OpenPGP, GnuPG, GPG encrypted spam. Even if my public key(s) are widely and publicly available.
Without seeing the user interface, it's hard to know if the key management provides enough visibility to the end user about the keys being used. It might be really good, or bad. Who knows.
Sometimes I wonder if the whole concept of services like this is to gather 'confidential' data, and then cash out intelligence services and others 'trusted wealthy entities' to pay for accessing the data, or directly blackmail users. Yet, I just wish that would be my personal sick thought.
This writing is based on their web site's information on 2017-02-06. I'm not cryptography professional. These are just my nerd hobby random ramblings about the topic. - Sorry about that.
1-10 of 460