Posts tagged with 'Crypto'

Crypto Easter Eggs in Software

  • Posted on May 27, 2015 at 12:59 am

The Logjam paranoia is spreading. After decades of using software with cryptographic features, every couple of months researchers discover features and code from the dawn of communication over the Internet. DES, 40/56/64 bit keys, RC4, 16 bit primes (yes, you read that right), and a lot more legacy cruft is still in memory on computer systems all over the world. Unless the code bases get cleaned up LibreSSL-style, there will be more of these ghosts from the past.

Delete these lines of code, remove the dependencies. No excuses.

CryptoParty Observations

  • Posted on October 11, 2013 at 10:23 pm

The CryptoParty phenomenon is past its first anniversary. The interest in cryptography and secure communication has always been there. The existence of CryptoParty before Edward Snowden leaked the criminal practices of secret services around the world is a good indicator for that. The questions is if crypto flash mobs of tutors and students can make a difference. Cryptography has deep roots in mathematics (which can and have to be reduced to a minimum when explaining, remember that every formula in an article for a wide audience halves your readership). In addition most tools used for encryption are not point-and-click capable (which is partly due to the user interface, but the real reason is the fact that secure communication doesn’t feature an on/off switch). Too bad. Despite these difficulties CryptoParty events work somehow. At almost all local events here participants learned something, tutors did too.

A couple of days ago someone asked me for a „mini crypto handbook with just the essentials“. I have given this idea some thoughts, but I doubt that you can improve your data’s and communication’s security by a short laundry list of things to do or not to do. You might get to the point of encryption quite fast, but managing the keys and verifying the identity of your communication partner(s) is the most important aspect. Then there is the problem that once data is decrypted it tends to leave residue in clear text. Unless you use encrypted storage all of the time and everywhere there is a chance that traces of data will leak and stay without cryptographic protection. It’s a bit like dealing with radioactive material – always use secure containers and equipment.

Give the extra effort of security all of our lives will still have an „unencrypted component“. You cannot securely communicate with partners who do not support secure communication. Calling a taxi, ordering pizza, phone calls with friends & family, even communication with companies or public authorities are probably easy to intercept. Observing the communication of an individual or an organisation as a whole can therefore be very informative if the pattern of encrypted and unencrypted information is analysed. If you only use cryptography when important, then you betray the fact that something interesting is going on. Using cryptography indiscriminately would be better – if it were possible with every communication end-point. Intelligence services know this, so does everyone else.

There are not short-cuts, it seems.

Mißbrauch von Crypto durch Marketing

  • Posted on August 10, 2013 at 9:53 pm

Die Deutsche Telekom, Web.de und GMX schalten nun die Transportverschlüsselung (nennt sich SSL/TLS) für versendete und empfangene E-Mails ein. Ganz toll. Andere verwenden diese Technologie schon seit etlichen Jahren. Die Branche feiert also eine Selbstverständlichkeit, die andere schon längst praktizieren. Fein, es gibt ja sonst keine guten Neuigkeiten über Telekommunikationsanbieter, die in den Wolken schweben. Zwei Dinge leistet SSL/TLS allerdings nicht.

  • Eine versendete E-Mail kann durch SSL/TLS nicht vor Dritten geschützt werden.
    Einem E-Mail-Server in der Zustellungskette stehen nach wie vor die Inhalte einer E-Mail zur Verfügung. Deswegen nennt sich die eingesetzte Verschlüsselung auch Transportverschlüsselung. Während des Transports wird die E-Mail verschlüsselt übertragen. An allen beteiligten Stationen liegt sie im Klartext vor. Transportverschlüsselung macht nur Sinn, um Dritten, die nur den Transport der E-Mails sehen (wie beispielsweise die Leute am Nebentisch im Internet-Café, der BND, GCHQ oder ein korrupter Mitarbeiter). Genau dafür war sie auch gedacht, nicht mehr und nicht weniger. Das jetzt als Schutz vor Überwachung zu feiern, speziell von Wolken- und Kommunikationsanbietern, die auf kompromittierter Infrastruktur sitzen, ist bestenfalls ein schlechter Witz.
  • SSL/TLS kann den Absender einer E-Mail nicht authentisieren.
    E-Mails können auch bei Transportverschlüsselung nach wie vor einen gefälschten Absender haben. Der Transportverschlüsselung ist es herzlich egal wer sie verwendet.

De-Mail ist übrigens auch nicht besser, egal was man einem da einreden möchte. Die Industrie folgt also der Politik und lügt Kunden an. Schöne neue Welt.

Wer sich für die Hintergründe interessiert oder wer auch mal große Firmen beim Lügen ertappen will, der/die/das schaue bitte zur nächstgelegenen CryptoParty.

Es gibt keine leichten Auswege aus dem Überwachungswahn

  • Posted on July 7, 2013 at 8:58 pm

Seit Bekanntwerden des weltweiten Überwachungsskandals grassieren zwei konträre Ansichten durch das Internet. Die Eingeweihten und Paranoiker sagen: „Wir haben es immer schon gewußt.“ Man liebt es ja, wenn eine Verschwörungstheorie an Wahrheit gewinnt. Dem gegenüber stehen diejenigen, die den Rechthabern vorwerfen: „Ihr habt versagt.“ Den Satz gibt es auch als Selbsterkenntnis. Man kann sich jetzt eine der Seiten aussuchen und damit den eigenen Grad der Unglücklichkeit bestimmen. Das ist der einfache Weg. Es gibt noch einen differenzierten Ansatz, den niemand interessiert.

Dass man Kommunikation an natürlichen Engpässen überwachen kann, ist kein Geheimnis. Das ganze wird noch leichter, wenn man Klartext verwendet oder keine eigenen Schlüssel hat. Man kann nun lang und breit über dezentrale Systeme, Kryptographie, Schlüssellängen, supertolle Apps zu Abhilfe, eigene Infrastruktur und die Rettung der Welt durch Bits, Bytes und Mathematik reden. Man kann auch viel an den derzeit bekannten Lösungen für bestimmte Probleme herumkritisieren. Natürlich ist vieles Da Draußen™ nicht mit genial intuitiven Oberflächen versehen (dazu zählen aber auch Videorekorder). Wenn nur Eingeweihte Eingeweihtes bedienen und entwickeln, dann wird sich am bedienungsunfreundlichen Status Quo kaum etwas ändern. Es bedarf weiterer Dialoge zwischen den Kennern und den, die es benutzen, um diese Pattsituation aufzulösen. Dazu Bedarf es gegenseitigem Respekt zwischen denen, die etwas wissen, und denen, die etwas wissen – und etwas benutzen – wollen. Elitäres Herumgehampel (auf beiden Seiten wohlgemerkt) hilft nur den Geheimdiensten.

Dasselbe gilt für die Beschwerden über TOR und andere Anonymisierungsnetzwerke. Ich finde es toll, dass auch anderen die Langsamkeit von TOR auf die Nerven geht. Die langsamen Geschwindigkeiten liegen aber nicht nur am Code, sondern sie liegen auch daran, dass es einfach nicht genug TOR Nodes gibt. Der Grund dafür liegt wiederum daran, dass manche Internetanbieter den Betrieb von TOR Nodes untersagen und gleichzeitig Behörden prinzipiell den Betreibern von TOR Nodes das Leben schwer machen. Möchte man da Abhilfe schaffen, so bedarf es keiner Programmierarbeit. Man greife zum Telefon, Stift oder Drucker und verleihe dem Wunsch nach mehr TOR Nodes bei seinem Internetanbieter oder seinem Abgeordneten etwas Nachdruck. Internetanbieter könnten ja irgendwann TOR Dienste ins Portfolio aufnehmen (ja, man wird ja noch träumen dürfen).

Wer mehr TOR Nodes braucht, der kann auch welche kaufen. Torservers.net betreibt welche und bittet im Gegenzug um Unterstützung. Es gibt auch andere Organisationen, die dieses tun. Wieso nicht der Großmutter einfach einen TOR Node schenken und auf die Geburtstagskarte „Liebe Oma, dieser Betrag sorgt dafür, dass die Gestapo nicht wieder kommt.“ schreiben? Die (aussterbende) Kriegsgeneration freut sich sicherlich über eine solche Geste. Man kann ja auch notfalls Blumen oder Pralinen dazulegen.

Code, Apps and Design Principles

  • Posted on November 17, 2012 at 4:13 pm

You probably know the term eye candy or dancing pigs. It applies to applications („apps“) running on computing platforms. It especially applies to apps running on devices that can be thrown easily. Widgets, nice colours and dancing pigs beats a sound security design every time. Since this posting is not about bashing Whatsapp (it’s really about sarcasm), here’s a list of advice for app „developers“.

  • If you in need of unique identifiers (UIDs), please always use information that can never be guessed and are very hard to obtain. Telephone numbers, names, e-mail addresses and device identifiers are closely guarded secrets which will never be disclosed, thus this is a very good choice.
  • If you are in the position of having to use easily guessable information for unique identifiers, make sure you scramble the information appropriately. For example you can use the MAC address of network devices, you just have to use an irreversible function on it. MD5(MAC) yields a result that can never be mistaken by a MAC address and cannot be reversed, so it is totally safe.
  • Everything you cannot understand is very safe. This is why you should never take a closer look at algorithms. Once you understand them, the attacker will do so, too. Then your advantage is lost. Make sure you never know why you are selecting a specific algorithm regardless of its purpose.
  • Always try to invent your own protocols. Since every protocol in existence was invented by amateurs with too much time on their hands, you can always do better.
  • Never reuse code. Libraries are for lazy bastards who cannot code. Rewrite every function and framework from scratch and include it into your software.
  • Put the most work into the user interface. If it looks good, the rest of the code automatically becomes very secure and professional. This goes for encryption as well. Most encryption algorithms can be easily replace by the right choice of colours.
  • Getting reverse engineered is never a problem if you explicitly forbid it in the terms of usage. Everyone reads and accepts this.
  • Aim for a very high number of users. Once you hit the 100,000 or 1,000,000 users, your software will be so popular that no one will ever attack it, because, well,  it’s too popular. Accept it as a fact, it’s too complicated to explain at this point.

Go and spread the word. I can’t wait to see more apps following these simple principles to be available in the app stores all over the world.

 

Cryptographically celebrating Samhain

  • Posted on October 30, 2009 at 9:45 pm

What better way is there to celebrate Samhain than to create a new Certificate Authority? The old CA has passed away, harvested by the flow of time. The new CA is ready and a computer is currently generating new RSA keys. This calls for a celebration. Let there be longer keys!

Top