Re: [cryptography] Scrypt hardware optimized miner
On 6/30/15 9:12 AM, Ryan Carboni wrote: Yes, until this specific combination becomes widespread enough that there's sufficient incentive to produce ASICs for it. YesCrypt is more modern. Use that. Give me as a gift a Javascript based implementation of Yescrypt and i'd love to use it! :-) Fabio ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Scrypt hardware optimized miner
Now that Scrypt has been used by cryptocurrency a new generation of hardware optimized miner (that can be converted to password-cracking) went out https://www.hashcoins.com/buy-scrypt-miners/ . The questions are: a) Is scrypt always safe enough? b) Which scrypt parameters should be tweaked in order to make it *much more* difficult to the hardware minire? c) Is the approach of chaining multiple hashing systems (to require the attacker to implement multiple hardware-specialized system) valuable like done by some crypto-currency? The assumption is that if i need to buy 10 different specialized-ASIC to attack a specific crypto, it's obviously going to cost more. -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] OpenPGP in Python: Security evaluations?
On 6/12/15 6:05 AM, Michael Greene wrote: Hello there, I am the author of PGPy - I figured I’d chime in here, even though I have clearly noticed this discussion a little bit late. When I decided that taking up the project of building a pure-Python OpenPGP implementation would be worthwhile, I did so after evaluating all of the existing Python libraries I could manage to find. The main reason I started the project was because very nearly all of the Python libraries for working with PGP were either wrappers around the gpg binary, or GPGME bindings (which itself is a wrapper around the gpg binary, but written in C). I'm a fan of PGPy approach, because it rely on native crypto but implement the OpenPGP packets formats in pure python enabling full application control without having to do dirty stuff (such as python-gnupg relying on gpg making executing gpg in /dev/shm/ leading to tons of issues). The integration of third party security software based on execution of cmdline is very dirty, architectually speaking, and most gpg and Tor library must do that. Regarding GPGME, is it really exec()uting the gpg binary or is it calling directly the gpg as a library? We're considering switching the server-side operations of GPG of GlobaLeaks to PGPy or OpenPGP-Python, given proper streaming support (for memory/buffering reasons) and a public security audit that can be arranged. For PGPy i really suggest to make a wrapper API to facilitate replacement of python-gnupg with PGPy. -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Designing a key stretching crypto that maximize use of WebCrypto?
On 5/14/15 2:29 PM, Jeffrey Walton wrote: Just bike shedding, but I don't think that's fair to WebCrypto. WebCrypto provides a standard set of primitives, like hahses. But the selected hashes are designed to be fast, and not slow or memory hard. So comparing a WebCrypto PBKDF based on SHA-X is akin to comparing apples and oranges. I agree, i understand, but my point is as that given a specific constraint (ie: waiting 10s for number crunching in a browser with some JS code to do key-stretching) what's best? a) an entirely non-native javascript based scrypt for 10s b) design something new re-using existing fast native-webcrypto-primitives with some non-native javascript code running for the same 10s achieve a better security strength improvement ? For example, can we achieve an scrypt-like approach re-using for the most computational intensive operations the existing native-crypto-primitives available from webcrypto? Also see https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0706.html. Lovely, but that sounds like to be a long path. I will subscribe to the mailing list and support it! Fabio ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Javascript scrypt performance comparison
On 5/8/15 2:34 AM, Solar Designer wrote: On Mon, May 04, 2015 at 11:48:25AM +0200, Fabio Pietrosanti (naif) - lists wrote: Also for upcoming implementation extending scrypt concept, like yescrypt/yescrypt-lite it would be very interesting to think how to make it faster in the context of the browser/javascript/html5. Taylor Hornby might try implementing yescrypt-lite with SIMD.js this summer as part of his GSoC project. https://hacks.mozilla.org/2014/10/introducing-simd-js/ Unfortunately, SIMD.js is lacking 64-bit integer vector elements, so they will have to be emulated with 32-bit ones (perhaps across pairs of SIMD vectors), yet this might provide some speedup over scalar code. Obviously, this version will be less portable. That's quite interesting! Did you considered also extending asmcrypto.js with SIMD.js, then using asmcrypto.js library? That way the low-level optimized crypto primitives will stay self-contained. We are in an implementation phase of end-to-end crypto in GlobaLeaks and we're on-boarding scrypt-async-js as per your suggestion, collaborating on improving that library (we introduced automated CI testing, webworkers, small performance optimizations). Do you think that yescrypt-lite in JS will be a reasonable substitute of scrypt within a defined amount of time (we're open and interested to integrate latests crypto)? Did you ever evaluated to try to design a yescrypt-lite in a way to leverage at maximum the existing WebCrypto API other than SIMD.js (that's a cool stuff!)? For GlobaLeaks we're sacrificing compatibility as we need WebWorkers, Promise, WebCrypto API, so we'll be focusing e2e release only for latests browsers. But is SIMD going to be part of latests browsers? Fabio ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Designing a key stretching crypto that maximize use of WebCrypto?
Hi all, testing the lovely slowness of a pure scrypt implementation in javascript running into the browser, i was wondering anyone ever tried to think/design an cryptosystem for key stretching purposes that leverage only existing webcrypto API (https://www.chromium.org/blink/webcrypto) with the goal to use let's say 80% of cpu time on native-crypto-code rather than JS code? In the browser native crypto code trough WebCrypto API works obviously much faster than JS crypto code (how much?)! Fabio ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Javascript scrypt performance comparison
Hi all, does anyone ever made a performance comparison of existing JS scrypt implementation? Currently there are those three: - scrypt-async-js https://github.com/dchest/scrypt-async-js/ - js-scrypt (emscripten compiled) https://github.com/tonyg/js-scrypt - webgl-scrypt https://github.com/Kukunin/webgl-scrypt Anyone ever analyzed/compared them? Also for upcoming implementation extending scrypt concept, like yescrypt/yescrypt-lite it would be very interesting to think how to make it faster in the context of the browser/javascript/html5. Being able to exploit fully WebCrypto/WebGL to deliver quasi-native performance in the browser would be cool. -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] OpenPGP in Python: Security evaluations?
Hi all, for any developer willing to use OpenPGP with a python developed application currently the main choice is to go with python-gnupg, that's a wrapper on top of GnuPG binary (https://pythonhosted.org/python-gnupg/). That's architecturally a very bad choice, plenty of constraint (for example you need to enable /bin/sh execution under apparmor sandboxing profile of a python application under Linux). Currently there are only two pure-python OpenPGP implementation: * PGPy: https://github.com/SecurityInnovation/PGPy * OpenPGP-Python: https://github.com/singpolyma/OpenPGP-Python Both stacks rely on Python Cryptography for Cryptographic primitives implementations https://pypi.python.org/pypi/cryptography . We're considering switching away from GnuPG for the server-side PGP processing and would like to ask an opinion to the list about those implementations. Are there anyone engaging in metrics to evaluate the security of an OpenPGP implementation and/or already evaluated PGPy/OpenPGP-Python ? -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Mixing multiple password hashing: Crypto Blasphemy or Useful approach?
On 3/16/15 1:58 AM, grarpamp wrote: Is this not the old chained crypto argument? Well, no, the old chained crypto argument try to argue that if a crypto A is broken, then crypto B will save the cryptosystem . Instead i'm specifically brainstorming (but i maybe perfectly wrong!) w.t.r. providing better resiliency against massive parallelization trough specifically designer hardware such as ASIC/FPGA . Let me better elaborate: The logical assumption for the adversary is to be interested to build a SHA1 cracking super computer because PKDF2-SHA1 is very diffused. So i'd assume that the adversary is going to build up cracking super computer with ASIC/FPGA that focus on specific algorithms that are widely diffused, investing a shit load of money in cryptanalytic research trying to optimize the cracking. The assumptions i'm testing in this email are that if the adversary will build the same cracking super computer for a less diffused algorithm: - it will be a smaller cracking super computer because of the smaller user-base using the less diffused algorithm - it will be less optimized because he will have invested less money in optimizing the cracking process trough cryptanalytic research. IF that assumptions are true, leveraging multiple cryptographic primitives, would wave the adversary from the ability in trying to crack my stuff on super powerful and super optimized crypto-cracking-cluster, requiring him to work over multiple less powerful and less optimized cracking machine. On an IRC discussion i've been told that security strength of key stretching improve logarithmically, so between 500.000 PKDF2 and 1.000.000 PKDF2 iterations, there's not such a big improvement. If the adversary build a PKDF2-optimized cracking machine (because PKDF2 is widely diffused), i expect it will be better for him to attack a 1.000.000 PKDF2 iterations, rather than (for example): * 500.000 PKDF2 * 100.000 Whirpool * 100.000 Blake2 * 100.000 Keccak * 100.000 SHA512 * 100.000 HKDF Because, from the assumption discussed above (maybe wrong eh, i'm testing it!), the adversary, with the regards to all those others 5 crypto: - Does not yet own a super-powerful cracking machine (or the cracking machine are small in size/power) - The level of cracking optimization are not that big However the amount of computational power required on a general purpose computer maybe more or less the same . So the basic question, following those explanation, should be: Given that a cryptosystem is strong/good enough, by adding additional computation trough multiple cryptographic primitives, it's reasoable to affirm that this approach is going to put more difficulties on the adversary given his inability to build a single-hardware-highly-optimized ASIC/FPGA cracking cluster, compared to the same amount of additional computation by using a single cryptographic primitive? -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Javascript Password Hashing: Scrypt with WebCrypto API?
On 3/15/15 12:45 PM, stef wrote: Check the Threat Model link on https://globaleaks.org in the footer to get a better insight. i now understand why you did not link this directly: https://docs.google.com/document/d/1niYFyEar1FUmStC03OidYAIfVJf18ErUFwSWCmWBhcA/pub seriously on google? your threatmodel seems indeed quite limited. you should be much more open about your limits. Stef, don't troll! :-) In most places in the world Whistleblowing is done by sending email over gmail, that's the reality you have to live with. To be more realistic, from several investigative journalism groups we've been told that many sources use directly Facebook over the Facebook Pages as a preferred way to share confidential information. When you look at the reality, you need to *fly down from the moon to the earth* and be realistic on what can be done, finding the right tradeoff. That's what real-world security is, a tradeoff between what can be acceptable to achieve a Safe Enough level compared to the current situation. If you only think techy and only think radical, then you'll not achieve any security and safety improvement. If you understand real-life context of use, focusing on bringing the best security that they can effectively leverage for their context of operation, then you're making them safer. Perfectly safe? No. But it's just hypocrisy to think that technology can gives perfect safety, as technology it's only part of the picture. -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Mixing multiple password hashing: Crypto Blasphemy or Useful approach?
Hi all, i've been brainstorming on the different way to apply a KDF in a strong enough way and i see that each approach has it's advantage and disadvantages in terms of speed, in terms of FPGA/ASIC protection, in terms of crypto primitives being used. I'm wondering if it's smart or stupid to think/apply a password-hashing system that apply multiple password-hashing schema based on different cryptographic primitives in sequence, as a way to force the attacker willing to FPGA/ASICize the bruteforcing process, to need to implement multiple cracking infrastructure. I don't have the cryptographic knowledge to design something on my own, but i'm asking if this approach make sense. Let's assume something like that, assuming that could take 10-20s on a modern computer: step0: 3s of scrypt step1: 10.000 round of SHA256 step2: 10.000 round of SHA512 step3: 10.000 round of Whirpool (even if broken) step4: 10.000 round of Blake2 step5 10.000 round of Keccak (SHA3) step7: 10.000 round of HKDF (In WebCrypto API) step6: 10.000 round of PKDF2 (in WebCrypto API) Each single hashing algorithm and KDF functions provide a specific set of protection against specific set of attacks. An adversary that want to build ASIC or FPGA cluster, would really require to build many specialized clusters rather than one very focused cracking-cluster (ie: to attack SHA256). A Meta KDF function like that could bring much more complexity on the attacker side by requiring the attacker to employ multiple attack vectors to attack the cryptosystem. The approach previously described, from a real world attack scenario perspective, does make sense as a on steroid key-stretching approach? -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SRP 6a + storage of password's related material strength?
On 3/13/15 3:11 PM, Solar Designer wrote: Because SRP protocol is cool, but i'm really wondering if the default methods are strong enough against bruteforcing. They are not. That was my concern. Does anyone ever tried to make SRP authentication protocol extensions/specs to work with server-side storage of hashes based on scrypt? From my umble understanding of crypto, it would be like leveraging the best properties of SRP authentication protocol and scrypt password hashing. But yet, my poor-math brain have difficulties understanding if that's feasible or it's just a stupid consideration. Fabio ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] SRP 6a + storage of password's related material strength?
Hi all, SRP is a very cool authentication protocol, not yet widely deployed, but with very interesting properties. I'm wondering how strong is considered the storage of the password's related material strength? I mean, from a passive/offline brute forcing perspective, how can be compared scrypt vs. SRP's server-side storage of passwords? Does anyone ever considered that kind of problem? Because SRP protocol is cool, but i'm really wondering if the default methods are strong enough against bruteforcing. -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Javascript Password Hashing: Scrypt with WebCrypto API?
Hi all, at GlobaLeaks we're undergoing implementation of client-side encryption with server-side storage of PGP Private keys. Obviously the hashing to be used for storing such PGP private keys has to be strong enough, with valuable key-stretching approach. We're now considering using Scrypt with some finely tuned parameters, but we've concern regarding it's performance in the browser as a JS implementation. PBKDF2 is available from WebCrypto API and, as far as i read and understand but i'm not that low-level-crypto expert, is used internally to scrypt. Does anyone know of any scrypt implementation that try to leverage the WebCrypto API? -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Javascript Password Hashing: Scrypt with WebCrypto API?
On 3/11/15 1:10 PM, stef wrote: GlobaLeaks it's designed to be a Whistleblowing framework that can be used in very different context, from WildLife Crime Activism up to Anticorruption in Serbia up to PubLeaks-like Journalism in Netherland, keeping the maximum level of security achievable for a specific context of use. serbia sounds like a state level actor, and i heard that the publeaks people also get attention from the local services. The reality is that each scenarios have it's own peculiarities, really, it would be a very long and complex discussion that require few hours to analyze each scenarios details. PubLeaks in the Netherland has been deployed with Tails as Leaktops for the journalists for end-point security, with GlobaLeaks being hosted by a well-known third party within the activists community (GreenHost), with servers deployed in a geo-political smart way, with service contract done with the PubLeaks Foundation (a legal entity created on purpose) to be resilient against certain kind of legal threats. OCCRPLeaks do require instead, in Bosnia and balkan-area, to leverage plausible deniability by embedding GlobaLeaks within existing HTTPS site (https://occrp.org) because plausible deniability has been considered, after threat-modelling with the stakeholders, more relevant than just saying Hey, use Tor to access this .onion site . In Africa for AfriLeaks we're considering that, in certain country, it's better to avoid using any Tails or Tor stuff, but better implement deception strategies. When you work supporting the many initiatives you'll just realize that many time, the cryptographic/technical implementation side of a Whistleblowing initiative's security, is a minor part and shall be considered in a broader Security threat model. Given that the picture is complex and variegate enough, we are providing such a differentiated set of security levels, from a technical and procedural point of view. Consider that in most situation, when you consider significant threats, only opsec procedures and stakeholder organization can provide some degree of protection (or at least detection), with technology playing a little role. The way you work in a place where The rule of law is effective, it's very different from working in a place where having an encrypted usb stick with you can lead to Tortures. Hope to have provided a broader view on how complex and complicated can be our threat model, so that we must choose individual security choices that enable use to provide a graduated/configurable level of security (that could go up, being very strong, or go down, being more flexible). Btw, that's not the goal of this thread, but i loved to articulate an answer! :) -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Javascript Password Hashing: Scrypt with WebCrypto API?
On 3/11/15 12:42 PM, stef wrote: On Wed, Mar 11, 2015 at 11:53:35AM +0100, Fabio Pietrosanti (naif) - lists wrote: at GlobaLeaks we're undergoing implementation of client-side encryption with server-side storage of PGP Private keys. i didn't get the memo, that js in browsers is now the way to best mitigate against state level actors. i mean globaleaks clearly has state-level actors in their threat-model, right? No, GlobaLeaks doesn't consider in it's threat model an NSA-like actor. GlobaLeaks it's designed to be a Whistleblowing framework that can be used in very different context, from WildLife Crime Activism up to Anticorruption in Serbia up to PubLeaks-like Journalism in Netherland, keeping the maximum level of security achievable for a specific context of use. Some deployment scenario is Safe Enough, some other is Super Paranoid, but we're bound to the reality of real-wold uses, that are differentiated as the risks scenario are. Check the Threat Model link on https://globaleaks.org in the footer to get a better insight. This email thread is specifically addressing the issue of using a strong client-side password hashing methods, such as scrypt (or maybe the upcoming winner of https://password-hashing.net/report1.html), in a way that could exploit the WebCrypto API primitives. Today with WebCrypto API you can only do hashing with PBKDF2 with tons of iterations, but i haven't found/seen an scrypt that leverage WebCrypto API or something similar to enable key-stretching client-side with a decent time-waiting/key-stretching-crypto-improvement ratio. -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] EU ENISA guidelines on Cryptographic solutions
http://www.enisa.europa.eu/media/press-releases/securing-personal-data-enisa-guidelines-on-cryptographic-solutions + algorithms, key size and parameters report 2014: http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-size-and-parameters-report-2014/ -naif ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Preventing Timing Correlation Attacks on XMPP chats?
Hi, XMPP networks are now going to be default secured with TLS in their client-to-server and server-to-server communications by 22th Feb. Most IM client support end-to-end encryption with OTR by default. The Federated Architecture make it very scalable and distributed. With all that goods of COMSEC in place, we are missing a timing correlation protection schema for XMPP traffic, to avoid an adversary monitoring your internet communication line to know when you have written something. POND is a super technology to prevent timing correlation attacks (https://pond.imperialviolet.org/tech.html), unfortunately it's a closed network so i don't think it would ever get diffused (it's also written in GO and my religion does not let me use anything written in GO). So i've been thinking that we need a method to achieve protection against time traffic correlation attacks on XMPP chat. It's possible that, by having a traffic-generator-robot (behaving like an XMPP buddy you connect to), and an XMPP client plug-in it would be possible to create some kind of constant traffic timing pattern to avoid an adversary being able to make timing correlation attacks. Something like that would be relatively easy to be implemented. This would bring timing correlation attack protection to the already existing security stack of XMPP: - Client TLS encrypted login - Server-to-Server TLS encrypted communication - end-to-end encrypted communication with OTR - Federated architecture -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email is unsecurable
Il 11/27/13, 10:01 PM, Jeffrey Walton ha scritto: The problem with DANE is the lack of DNSSEC. If we had both [...] When I refer to DANE, I also mean that DNSSEC must be there. We're getting there. Isn't the key distribution problem being pushed into DNS? The underlying problem still exists. To fix massive interception, that's passive, we do not need authenticated encryption. We just need to have a widely used and diffused opportunistic encryption with unauthenticated TLS on SMTP-to-SMTP communications. Authenticating keys with DNSSEC/DANE or TOFU, is imho a nice additional feature, but it's not required to fix the massive interception, that's passive. -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email is unsecurable
I'm strongly against most the ideas to abbandon current email systems, because the results will be to create wallet garden. We need something interoperable with existing systems or the system will just be used by a bunch of paranoid people or fostered by the marketing of few cryptography company acquiring customers, not user. So we need IETF standards, interoperable with existing email standard protocols (SMTP, IMAP, MIME). I'm just very disappointed that many of us look at the moon, trying to invent something new, when there are so many improvements to be done on existing interoperable platforms. Let's first cut-off the massive passive traffic analysis, then improve current systems to provide some added protection against metadata, focusing in a far future, when the new system got already wide adoption, make it perfect. Fabio Il 11/25/13, 7:20 PM, Natanael ha scritto: Say hello to Bote mail on I2P. I2P provides encrypted anonymizing networking, Bote mail provides DHT based serverless encrypted mailing with public crypto keys as addresses (ECDSA or NTRU). http://i2p2.de and i2pbote.i2p (if you don't have I2P installed, add .us to visit it via an inproxy). There is also I2P Messenger that is encrypted P2P IM within I2P also using public keys as addresses. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Quality of HAVEGE algorithm for entropy?
Greetings, i found such a very nice piece of software that's said to provide added entropy using HAVEGE algorithm: http://www.issihosts.com/haveged/ http://www.irisa.fr/caps/projects/hipsor/ Any opinion on the usefulness of that kind of tool as an additional entropy source for crypto operations on a Linux system? -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Opportunistic encryption of modern web application without https
Hi, the idea is to deploy TLS with DHE cipher to achieve PFS unauthenticated (JS, no plugin) or with a TOFU trust model (JS with plugin) in any browsers, with the implementation model as follow: - a JS library to be hooked to Ajax xhr request in javascript application - a browser plugin that automatically hook xhr requests of certain application - a server gateway application to convert this data flow (over websocket) to be forwarded to a https server in localhost with self-signed digital certificate The brief discussion is at https://github.com/digitalbazaar/forge/issues/84 What do you think? -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Dissentr: A High-Latency Overlay Mix Network
Hi Eugen, did you evaluated about leveraging existing Tor network properties by running Dissentr over Tor network by default, to achieve some better security properties? -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org Il 9/24/13 4:52 PM, Eugen Leitl ha scritto: https://github.com/ShaneWilton/dissentr Note: This project was created as part of a 36-hour hackathon - and primarily as a proof of concept. While the ideas may be sound, and the prototype may work as designed, the protocols involved in this specific project have not been peer-reviewed, and so I cannot recommend that the network be used for anything requiring serious privacy. Dissentr A High-Latency Overlay Mix Network ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] It's time for a Whistleblowing / Leaking Initiative for Cryptographer ?
http://threatpost.com/uk-cryptographers-call-for-outing-of-deliberately-weakened-protocols-products/102301 -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
Il 9/17/13 12:10 AM, Tony Arcieri ha scritto: On Mon, Sep 16, 2013 at 4:45 AM, Marco Pozzato mpodr...@gmail.com mailto:mpodr...@gmail.com wrote: I'm looking for an asynchronous messaging protocol with support for forward secrecy There's also Nitro, which is a CurveCP derivative: http://gonitro.io/ Unfortunately they didn't implement the full CurveCP handshake, which provides both passive and active forward secrecy. It's unfortunate :( It's plenty of custom solution and custom technologies to achieve those goals. I am wondering why we don't just extend OpenPGP standard, by using OpenPGP/Mime envelope, to include procedures to achieve Forward Secrecy? Internet Standard are the bibble and saint text specification to look for. Shouldn't we first try to improve Internet Standard, and only after look for custom (and usually not interoperable) implementation? -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Forward Secrecy Extensions for OpenPGP: Is this still a good proposal?
Hi all, i just read about this internet draft Forward Secrecy Extensions for OpenPGP available at http://tools.ietf.org/html/draft-brown-pgp-pfs-03 . Is it a still good proposal? Should it be revamped as an actual improvement of currently existing use of OpenPGP technology? -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Preventing Time Correlation Attacks on Leaks: Help! :-)
Hey Peter, thanks for your analysis! I think we need to provide some additional input! In the context of GlobaLeaks where, stating from our Threat Model at https://docs.google.com/document/d/1niYFyEar1FUmStC03OidYAIfVJf18ErUFwSWCmWBhcA/pub , the Whistleblower can also be NON anonymous but approach a submission with Confidential level (over HTTPS over the internet) . No anonymity, but forced disclaimer ( https://github.com/globaleaks/GlobaLeaks/issues/260) and acceptance to take the risk. So, let's say that whistleblower is already in a bad position, but he accepted this condition. We are not considering in any way to add actions/protection on Whistleblower-Side but only on Receiver-Side that is where the bad guy would be able to read Notification information sent and apply Time Correlation on the Whistleblower-Action. Today if a Whistleblower make a submission, the system immediatelly send a notification to the Receiver. That's bad, because it leave a trace that allow time correlation. Who can read Receiver's email and traffic, can make a correlation on other data source where the whistleblower may leave traffic-traces (like a proxy, but also internet traffic dump, phisical badge/access logs, surveillance camera, etc) . Which kind of logic / algorithm to apply on the Receiver's notification timing in order to prevent / reduce the likelihood that a time correlation pattern is possible? A random delay between a lower bounday and an upper boundary seems like the most simple and effective approach to defeat this kind of correlation. However this does not work on very low-traffic globaleaks node. What do you think? -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org Il 8/21/13 4:17 AM, Peter Maxwell ha scritto: Hi Fabio, While I don't mean to be dismissive, I suspect your threat model is flawed for the following reasons: i. Most mid to large companies would not permit the use of Tor within their infrastructure and even if the hypothetical company did, it doesn't take a whole lot of effort to track down the handful of users within a company using Tor/stunnel/ssh/VPN. For that matter, I understand some companies even install private CA certificates into the browsers on company computers and decrypt outgoing SSL/TLS traffic at their web-proxy/firewall... in that situation, you're WB is going to stand out like a sore thumb as they'll be the only TLS connection that isn't being decrypted (because it's Tor). So unless you want your whistle-blowers to literally advertise their presence as worthy of attention, they aren't going to do the leak from an company system directly. ii. So, presuming i. is valid - and I suspect anyone who has worked within a competent security operations team will tell you the same - then you must assume the whistle-blower will do the leak from either their personal systems, a burn computer or a public system. If we make the assumption that the WB has taken the data out of the company/organisation on removable media or otherwise made it available to themselves outside the company infrastructure in a secure manner (while sometimes difficult, that is still far easier than i.) then your attacker can only see the WB's traffic if they are actively monitoring the WB's use of computers outside the company, in which case said WB has far bigger problems to worry about. If the attacker cannot monitor the timing of the leak, your problem is not framed in the manner you've presented. iii. Even if your model was realistic, you cannot adequately defend against traffic analysis for such a low-traffic network: you need other traffic to hide in, lots of it, from other users within the same company - it's not realistic for this type of service. iv. There are more subtle problems you are going to come across, not least of which are issues such as document tagging/water-marking/document versioning and the ability for the attacker - your hypothetical manager - to correlate leaked documents against the access rights and access patterns of potential whistle-blowers. For that matter, simple forensic analysis of staff computers is usually more than sufficient (and yes, organisations do this). It's also Isle of Man that people like hiding their ill-gotten-gains in, not Island of Mann ;-) Interestingly, I think anyone who has used Isle of Man accounts for tax avoidance are scuppered as the HMRC has signed an agreement with the authorities there for automatic disclosure. Anyway, as far as I can see it, you have two different scenarios to consider with one being significantly more difficult to solve than the other: A. The scenario where the whistle-blower is able to take the data out the company on removable media or paper-copy. This is the easy one to solve. Personally I would favour a combination of asymmetric encryption
[cryptography] Preventing Time Correlation Attacks on Leaks: Help! :-)
Hi all, at GlobaLeaks we are going to implement a feature that want to mitigate time correlation attacks between a Whistleblower submitting something and a Receiver, receiving a notification that there's a new leak outstanding to be accessed. We already had a internal discussion and received some valuable suggestions and comments available here https://github.com/globaleaks/GlobaLeaks/issues/264 . However being the argument possibly tricky, we would like to subject to suggestion, criticism and review the proposal. That's a summary of the context: Overview When a whistleblower submits to a globaleaks node all receivers that they have selected as recipients for their submission will receive a notification informing them that a new submission has occurred. Other whistleblower interactions also trigger a notification (that should therefore be protected from timing attacks) and such interactions are: * A new comment is added to an existing submission by a WB * A new comment is added to an existing submission by a Receiver * A new file is uploaded to an existing submission by a WB Goals We are interested in mitigating correlation attacks based on the dispatching of notifications for interactions performed by a whistleblower. It should not be possible (or harder) for an attacker to determine which person is a whistleblower for a certain submission based on their capabilities (more on that below). Adversary model A Their goal is to find which user has performed a certain submission on a globaleaks node. This adversary has the following capabilities: * They can read the content of notification messages. * They can perform a new submission to a globaleaks node and therefore trigger notifications (i.e. they are capable of doing a /flooding/ /blending/ attack) * A log of traffic from N users they suspect to have blown the whistle. This log includes the timestamp of when the request was made, the response was received and the size of the payload. * The log of the notification traffic. This includes the timestamp of when the notification was dispatched and the size of it. The content of the notification will be either encrypted (model A) or plaintext (model B). Adversary model B This adversary has all the capabilities of the above adversary, but they do not have the ability of reading the content of the notification messages. Adversary model C All of the above except the receiver is not trusted: their goal is to de-anonymise the WB. Is this any different from Adversary A, that is an adversary that has the ability to read the notification emails because they are not encrypted? Example real world scenario The GL node is a GL node for a private company. The adversary is a Manager of The Company that wants to find out who blew the whistle on the fact that he is recycling money through a shell company in the island of mann. Since they are on the receiver list, because the globaleaks node was configured to have a plurality of receivers, they will be able to read the content of the notification emails. The whistleblower decided to blow the whistle on from their office and the office network has a proxy that logs every HTTP request being done. When the Manager receives a notification that a new submission has been done to the globaleaks site they take the timestamp of such notification and look at the traffic logs for that period of time to see who was generating traffic during that period of time and based on this they should not be able to distinguish normal Tor user (or people loading the cover traffic widget) from the whistleblower. Thanks in advance for opinion! -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] open letter to Phil Zimmermann and Jon Callas of Silent Circle, re: Silent Mail shutdown
Il 8/17/13 7:08 PM, Jon Callas ha scritto: On Aug 17, 2013, at 2:41 AM, ianG i...@iang.org wrote: So back to Silent Circle. One known way to achieve some control over their closed source replacement vulnerability is to let an auditor into their inner circle, so to speak. One correction of fact: Our source is not closed source. It's up on GitHub and has an non-commercial BSD variant license, which I know isn't OSI, but anyone who wants to build, use, and even distribute their verified version is free to do so. It would be important to have a semi-automatic allignment of the Github's source code code base to each SilentCircle application's release. Now Github code is 6 months old. This would allow inspection of code before upgrade, additionally improving the transparency. -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DeCryptocat
Il 7/5/13 5:29 AM, Nadim Kobeissi ha scritto: Rest assured we're working on it as an extra precaution (as mentioned in the blog post). Also, our services use SSL forward secrecy. NK What's about embeding Tor binary (build as library) within the CryptoCat plugin and abbandon internet/SSL issues by going trough Tor Hidden Services? It does not seems quick easy to be implement from software engineering point of view, but definitely doable: Binary in Chrome Plugin trough NPAPI: http://developer.chrome.com/extensions/npapi.html Binary in Mozilla Plugin: https://wiki.mozilla.org/Mozilla_2/XPCOM_and_Binary_Embedding -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DeCryptocat
Il 7/5/13 8:34 PM, Jacob Appelbaum ha scritto: Module ngx_http_ssl_module supports the following built-in variables: $ssl_cipher returns the cipher suite being used for the currently established SSL/TLS connection $ssl_protocol returns the protocol of the currently established SSL/TLS connection — depending on the configuration and client available options it's one of SSLv2, SSLv3 or TLSv1 As a mid-term move for CryptoCat server side it would be nice to make it's own minimal and secure XMPP Server, to be installed without any configuration burden, be secure by design and not necessarily by configuration Doing so, would facilitate the integration with Tor to easily let anyone startup it's own CryptoCat server (also on windows/macappstore), running over TorHS, making the architecture more distributed and SSL-free. A nice set of technology to do it could be: - Wokkel, XMPP Server based on Twisted http://wokkel.ik.nu/ - TxTorCon, to manage Tor process https://github.com/meejah/txtorcon - Pyinstaller to make windows/macosx package http://www.pyinstaller.org/ - Cyclone, to make web interface to manage it easily https://github.com/fiorix/cyclone -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Potential funding for crypto-related projects
Il 7/1/13 1:32 PM, Tom Ritter ha scritto: I'm not saying GlobaLeaks+Tor is safe. I'm saying I think our current remailer network is wildly unsafe. (Now what I think about fixing it... that's a whole other story, for a whole other time.) While it's outside the scope of GlobaLeaks to provide a wide and complete solution to those kind of problems, in our pipelines there are a set of features that will provide some help in making certain time correlations attacks slightly more difficult. Prevent Time Correlation Attack on Notification https://github.com/globaleaks/GlobaLeaks/issues/264 Widget to create Cover Traffic to Tor2web sites exposing GlobaLeaks https://github.com/globaleaks/GlobaLeaks/issues/263 PGP Encryption of Email Notification https://github.com/globaleaks/GlobaLeaks/issues/187 -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
