Tag: aes

Nov 14

KeySweeper – Un keyloggeur pour les claviers sans fils de Microsoft – Korben

Samy Kamkar est un chercheur en sécurité de talent qui a mis au point un keyloggeur capable d’intercepter tout ce qu’une personne tape sur un clavier Microsoft sans fil (signal radio proprio sur 2,4 GHz pas chiffré ou avec un truc antérieur à l’AES). Avec de l’Arduino, planqué dans un chargeur USB qui se branche > Lire la suite

Source: KeySweeper – Un keyloggeur pour les claviers sans fils de Microsoft – Korben

Jan 21


This addon allows you to encrypt and decrypt the text: selected or manually entered text, as well as whole site

The encryption process is based on the US military standard Advanced Encryption Standard (AES)


via CryptoData.

Jul 11


The Gostcrypt project has been launched at the end of 2013 as fork of the (late) Truecrypt project. Snowden’s leaks have made clear more than ever that the massive use of encryption by citizens must become a reality. This is possible only if there is a vast, rich offer of trusted, open source products like Truecrypt, with the strong support of the hacker community. However, at that time we did not foresee the unprecedented upheaval of terrible shock with the recent Truecrypt disappearance. More than ever we all need more and more projects to replace it. Gostcrypt is one among (we hope) many others. The variety and richness of encryption solutions is THE solution.

But with Gostcrypt, we intend to go farther than ever. Since the late 70s, most of the algorithms used (not to say all) are UKUSA encryption systems that have been chosen, promoted and standardized under the control of the USA and its minions. It is more than likely that among the different levels of control, mathematical trapdoors are part of the game. We thus decided to used strong encryption systems (as far as we know and despite a few recent “manipulation papers” that have nothing to do with science and which are mistaken operational security with fantasy and which have been rejected recently again as non valid [Babenko & Maro, 2014]) which moreover were not invasive as UKUSA ciphers are (mostly AES) by now. The Gost cipher and hash functions are not everywhere, have not invaded our systems and have been designed by the former USSR for its own need. Aside the fact that it is indeed a very strong cipher (when correctly implemented and a suitable key management), this feature of non-aggressive technological expansion is a key point. GOST algorithms have never sought to spread and to impose on anyone. It has even been rejected from the ISO standardization process in 2012 as a consequence of fallacious, non-reproducible allegations of weakness.

Whatever may be the quality and features of a security project, it can be valid in the long run with trust only. Trust is only possible with open source code and above all with the active support of the hacking community, which will analyze the security, report bugs, make comments and contribute to the project. So welcome on board to everybody.

via GostCrypt.

Jul 08

50. Android (DRD) – java – CERT Secure Coding Standards

The following rules and guidelines are specific only to the Android platform. These do not apply to the development of Java or C programs for non-Android platforms. (The full set of Android -relevant rules and guidelines are here.) The term sensitive incorporates the Java glossary definition of sensitive data, as well as the Android concept of permission-protected.

DRD00-J. Do not store sensitive information on external storage (SD card) unless encrypted first

DRD01-J. Limit the accessibility of an app’s sensitive content provider

DRD02-J. Do not allow WebView to access sensitive local resource through file scheme

DRD03-J. Do not broadcast sensitive information using an implicit intent

DRD04-J. Do not log sensitive information

DRD05-J. Do not grant URI permissions on implicit intents

DRD06-J. Do not act on malicious intents

DRD07-J. Protect exported services with strong permissions

DRD08-J. Always canonicalize a URL received by a content provider

DRD09-J: Restrict access to sensitive activities

DRD10-J. Do not release apps that are debuggable

DRD11-J. Ensure that sensitive data is kept secure

DRD12-J. Do not trust data that is world writable

DRD13-J. Do not provide addJavascriptInterface method access in a WebView which could contain untrusted content. (API level JELLY_BEAN or below)

DRD14-J. Check that a calling app has appropriate permissions before responding

DRD15-J. Consider privacy concerns when using Geolocation API

DRD16-J. Explicitly define the exported attribute for private components

DRD17-J. Do not use the Android cryptographic security provider encryption default for AES

DRD18-J. Do not use the default behavior in a cryptographic library if it does not use recommended practices

DRD19-J. Properly verify server certificate on SSL/TLS

via 50. Android (DRD) – java – CERT Secure Coding Standards.

Jul 02



Jan 29

Seminar: Liran Lerman “A machine learning approach against a masked AES” (February 4, 2014)

February 4, 2014 – 12.45 – Computer Department Seminar Room – NO Building, 8th floor (Rotule)

Speaker : Liran Lerman (ULB)

Title : A machine learning approach against a masked AES

Nov 21

Seminar: Liran Lerman “A machine learning approach against a masked AES” (November 25, 2013)

November 25, 2013 – 13.00 – Computer Department Seminar Room – NO Building, 7th floor (NO7.07)

Speaker : Liran Lerman (ULB)

Title : A machine learning approach against a masked AES

Dec 07

AVOTE : Principaux résultats du projet

Principaux résultats du projet

Le vote électronique offre de nombreux avantages comme le vote à distance ou l’automatisation de la phase de dépouillement. Cependant, la moindre faille dans un système de vote électronique pourrait conduire à une fraude à grande échelle. L’objectif général du projet était de concevoir des techniques pour analyser la sécurité des protocoles de vote. Nos résultats s’articulent sur quatre principaux plans.

  • Formalisation de propriétés: Nous avons identifié et formalisé les propriétés souhaitées: correction du résultat, confidentialité des votes, impossibilité pour un votant de révéler son vote, vérifiabilité du processus de vote. Nous avons défini formellement ces propriétés dans des modèles symboliques, souvent sous la forme de propriété d’équivalence. (, )
  • Procédures de décision:
    Nous avons développé des techniques pour déterminer si un protocole de vote assure ou non les propriétés souhaitées comme par exemple la confidentialité d’un vote. D’un point de vue technique, cela revient à décider des propriétés d’équivalence sur des algèbres de processus. Nos travaux ont porté sur deux principaux types d’équivalence: équivalence statique (pour un intrus observateur) et équivalence observationnelle (pour un intrus pleinement actif). Dans les deux cas, les propriétés des primitives cryptographiques (chiffrement, ou exclusif, …) sont axiomatisées par des théories équationnelles. Nous avons obtenu de nombreux résultats de décision aussi bien pour l’équivalence statique que pour l’équivalence observationnelle, et cela pour différentes théories équationnelles. (, , , [CD10], , )
  • Outils:
    Nous avons réalisé quatre prototypes pour analyser automatiquement des propriétés d’équivalence de protocoles, et en particulier la confidentialité dans les protocoles de vote. Nos quatre prototypes sont KiSs et , pour un attaquant observateur, ainsi que aKiSs et ADECS/Datep, pour un attaquant pleinement actif.
  • Études de cas:
    Nous avons validé nos résultats sur plusieurs études de cas issues de la littérature dont le protocole FOO, qui est à la base de nombreux protocoles utilisant les signatures en aveugle et le protocole JCJ implémenté en tant que CIVITAS. Nous avons également analysé Helios, un protocole de vote réel, développé récemment par Ben Adida et le Crypto Group de l’Université Catholique de Louvain (UCL). Ce protocole a été utilisé plusieurs fois pour des élections grandeur nature, par exemple en 2009 pour l’élection du recteur de l’UCL avec plus de 5000 votants et aussi en 2010 par l’association internationale de cryptographie (IACR) pour élire son conseil. Nous avons mis à jour une faille dans le protocole Helios permettant de mettre à mal la confidentialité des votes. Nous avons proposé une correction, ainsi qu’une preuve de confidentialité pour la nouvelle version ainsi obtenue. Nous avons également montré qu’Helios assurait la vérifiabilité individuelle et la vérifiabilité universelle, permettant une transparence du scrutin. ([DKR09b], , [KSR10])
    Une autre étude de cas pratique fut le protocole de vote à distance (bulletins imprimés avec codes à barre) utilisé par le CNRS dans le cadre d’élection au CAES (comité d’entreprise du CNRS). Nous avons montré comment il était possible de « bourrer les urnes » et notifié le CNRS . Un correctif a été apporté par la société prestataire, pour le scrutin suivant. ()

L’ensemble des publications du projet est disponible iciSuite du projet: Une partie des thèmes de recherche du projet ANR AVOTÉ a été reprise dans le projet ERC ProSecure (Provably secure systems: foundations, design, and modularity) et dans le projet ANR VIP (Programme JCJC) (Verification of Indistinguishability Properties). Le projet ProSecure a pour but de développer des techniques modulaires et génériques pour analyser de nouvelles familles de protocoles de sécurité, et notamment les protocoles de vote. Le projet VIP s’intéresse plus particulièrement à l’analyse de propriétés du type “respect de la vie privée” qui jouent un rôle important dans de nombreuses applications (dont les protocoles de vote). Une variante d’Helios, appelée Helios-C, est en cours de développement. Cette variante permet d’être conforme aux recommandations de la CNIL (le nom des électeurs ne doit pas être public), tout en garantissant toujours la confidentialité des vote et la vérifiabilité du scrutin, même vis-à-vis d’une urne hébergée sur un serveur malhonnête.

Analyse formelle de protocoles de vote électronique (AVOTÉ).

Oct 01

Seminar: Stephane Fernandes Medeiros “The Schedulability of AES As a Countermeasure Against Side Channel Attacks” (October 4, 2012)

October 4, 2012 – 13.00 – Computer Department Seminar Room – NO Building, 8th floor (2NO8.08)

Speaker : Stephane Fernandes Medeiros (ULB)

Title : The Schedulability of AES As a Countermeasure Against Side Channel Attacks

Jul 03


Duplicati is a free backup client that securely stores encrypted, incremental, compressed backups on cloud storage services and remote file servers. It works with Amazon S3, Windows Live SkyDrive, Google Drive (Google Docs), Rackspace Cloud Files or WebDAV, SSH, FTP (and many more).

Duplicati has built-in AES-256 encryption and backups can be signed using GNU Privacy Guard. A built-in scheduler makes sure that backups are always up-to-date. Last but not least, Duplicati provides various options and tweaks like filters, deletion rules, transfer and bandwidth options to run backups for specific purposes.

Duplicati is licensed under LGPL and available for Windows and Linux (.NET 2.0+ or Mono required). The Duplicati project was inspired by duplicity. Duplicati and duplicity are similar but not compatible. Duplicati is available in English, Spanish, French, German, Danish, Portugese, Italian, and Chinese.

via Duplicati.