John Young | 1 Jul 23:47 2015
Picon

The Intercept Releases ~1,264 pages of NSA Docs

Mostly Xkeyscore and more.

http://cryptome.org/2015/07/nsa-xks-more-intercept-15-0701.7z (643MB)

List of files:

https://pbs.twimg.com/media/CI3AatNUsAExiNV.jpg:large
Picon

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
Alexander Klimov | 17 Jun 14:12 2015
Picon

chromium: unconditionally downloads binary blob

<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909>

After upgrading chromium to 43, I noticed that when it is running and 
immediately after the machine is on-line it silently starts 
downloading "Chrome Hotword Shared Module" extension, which contains a 
binary without source code. There seems no opt-out config.

that extension:
- doesn't appear in the extension list;
- is apparently used to provide an “ok google” voice activation stuff.

The fact that Audio Capture Allowed is set to yes, and that both the
extension and the shared module are marked as “enabled” are definitely
bothering me.

[...]

We believe that the bug you reported is fixed in the latest version of
chromium-browser, which is due to be installed in the Debian FTP 
archive.

[...]

Shouldn't we see a DSA [Debian Security Advisory] following this 
incident?

Since no one really know which binaries have been downloaded there and
what they actually do, and since it cannot be excluded that it was
actually executed, such systems are basically to be considered
compromised.
(Continue reading)

Moti | 16 Jun 00:46 2015
Picon

LastPass have been hacked, so it seems.

I always had my doubts about keeping my passwords in the cloud.
Let's hope for LastPass users that their data is as secure as LastPass claims it is.
No reason to think otherwise of course, but still. If i read correctly between the lines, some people's (sensitive) data maybe on the wrong hands.
I mean, what if Chinese hackers got it? (Yeah, it feels like i sound a bit Paranoid, but in this day and age, Chinese hackers are actually a thing:)
are we sure that the Chinese government don't have enough computing power to unhash whatever was taken?
just saying...
_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
John Young | 13 Jun 19:37 2015
Picon

Reporter-USG Exchanges on Snowden Docs

Italian reporter Stefania Maurizi has published her exchanges with NSA,
DoJ and State about publishing Snowden documents (an exemplary
model for others to follow):

http://www.stefaniamaurizi.it/images/email_exchange_NSA.pdf
http://www.stefaniamaurizi.it/images/email_exchange_DoJ.pdf
http://www.stefaniamaurizi.it/images/email_exchange_State_Dept.pdf

She also said she has published all the Snowden documents she
had access to (another exemplar for those still withholding 93%
of the Snowden full dump for the public, or 99.98% of the 1.7M
USG claims was taken).
Ron Garret | 12 Jun 22:28 2015

SC4 has completed its first security audit

SC4 is a PGP replacement based on tweetnacl-js that runs in a browser.  It has completed its first security
audit, conducted by Cure53:

https://github.com/Spark-Innovations/SC4/blob/master/audit-report.pdf

The TL;DR version:

"Our verdict is that SC4 has developed from a proof-of-concept to an edgy and unconventional yet reliable
crypto tool. If certain limitations and constraints are respected by its users, SC4 indeed fills a
formerly unpopulated gap in the world of browser crypto.”

I’m actively seeking beta testers and people to help me turn this into a real product to make strong crypto
accessible to a non-technical audience.

rg
Michael Greene | 12 Jun 06:05 2015

Re: OpenPGP in Python: Security evaluations?

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).

To be honest, I’m not sure if calling PGPy “pure-Python” is necessarily 100% correct. Although PGPy itself is 100% implemented in Python, I did not implement any of the actual crypto myself - that is handled by the Cryptography library, which uses cffi to invoke methods from existing libraries (the default currently being OpenSSL, but the possibility to plug into alternate backends exists as well)

So basically, practically the only way to be able to use PGP in Python was, one way or another, to call out to the GPG binary (and as it turns out, platform portability in that context is a difficult proposition - the largest category of related StackOverflow questions I happened across while searching for as many of these libraries as I could were questions from people who were having difficulty getting them to work on different platforms - often Windows, but probably not all of them. That particular issue was not something we were necessarily gunning for, but it might be nice for a handful of people, at least.)

The main problem we were interested in solving here was to be able to keep key management tasks within a single memory address space, to avoid the problems relating to securely sending passphrases to other processes, and to be able to use the keys without the additional disk IO involved in needing to import the key into an on-disk keyring before being able to use it for anything.

As a bonus, it turns out that doing the parsing natively in Python and not having to incur the additional overhead of spinning up an external process and communicate with it over pipes is actually tangibly faster, especially when repeating relatively quick operations (like signing a number of separate things in a row).

We did an internal security audit of PGPy 0.3.0 shortly before releasing it, but I would definitely be grateful for additional eyes on the code, maybe when 0.4.0 comes out (which I am working toward). If anyone is interested, wants to share concerns, etc, I would welcome the discussion.
--
Michael Greene
Software Engineer

Attachment (smime.p7s): application/pkcs7-signature, 4457 bytes
_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
John Young | 11 Jun 16:08 2015
Picon

Re: Helmholtz Tubes, CRT Signals (Was: Sigint Dumps)

We're tweeting these posts. Blowback: is any evidence available to
support the narrative? Sample of the data, say, for close examination,
with credible provenance, not the GG secret pact bloviation.

Mild critique: is this sci-fi or legit or both, advancing the literary-video
prize winning breaking news big screen Hollywood Neal Stephenson
spirit of the Snowden "NSA disclosures."

At 09:54 AM 6/11/2015, you wrote:
>More specifics on the sigint system:
>
>This looks like a "Growth Industry" ...
>
>Access to the beam is not restricted, anyone can pull signals out of
>the reconaissance loop from any of its exposed vectors.***
>
>Viable areas:
>Terrestrial:
>a: Spurrious emissions from tubes or conduit, beam deflection from
>interior particles
>b: Stray beams passing through field coils but not redirected
>c: Direct access to tubes or conduit (any variety of methods)
>Orbital:
>d: Geo-Magnetic Shift (downlinks)
>e: Refractive / deflection (downlinks)
>
>As the rate of geo-magnetic shift continues to deform the containment
>of the projected fields used to shape and steer the beams (which may
>also have something to do with the sensor itself?), wider areas will
>be accessible which are hit with the rogue spot beam from orbital (and
>projected field electro-magnetic) guides.
>
>This means almost anyone with a sensor can gather data from the downlinks.
>
>Additionally, spurrious radiation from the terrestrial system is
>available around endpoints and field coils, especially from damaged
>conduit or particles in the tubes.
>
>Time to raid the libraries for antique books about 1800s-1980s X-Ray
>EM physics and electromagnetic wave guides!
>
>It would not be rational to encode the carrier signal unless it was
>certain that the encoding would not disrupt signals quality, however
>raw X-Rated signals might have been too risky?
>
>[There are Thz ring oscillators, detectors, and various photonic
>rings, but properly implemented field-effect lenses, EM field vector
>control circuitry and coils(/phased array) (abstract field
>projection), and optimal tube design are all that should
>theorhetically be needed once a rogue beam is identified. X-Ray
>Materials and interference fields must be researched and made common
>knowledge.]
>
>Hopefully the data source is not too easily found and the dumps get
>out, this is extremely relevant for "civil liberties", human rights,
>and reconstructing your own personal history and records where your
>data is otherwise mising.
>
>
>
>On Thu, Jun 11, 2015, Wilfred Guerin <wilfred@...> wrote:
> > Helmholtz Tube, Beam Steering, EM field interaction, simple field
> > dynamics, (and your oscilliscope) are all you need to create complex
> > EM signals processors.
> >
> > No different than your antique crypto cracker, which uses an abstract
> > field to solve complex pre-defined systems. "56-bit" https cracker was
> > mass implemented as a 300mhz backplane EM field solver about the size
> > of your desktop computer.
> >
> > Using the same technology, resolution, and methods, BTC Bitcoins are
> > around 8m^3 of field to solve.
> >
> > No doubt the access and decoding to these sigint signals requires
> > similar proessing before being steered to the digitiser.
> >
> > (Maxwell Tube, Helmholtz Tube, typical of high school physics classrooms)
Krisztián Pintér | 27 May 13:19 2015
Picon

Re: Enranda: 4MB/s Userspace TRNG

On Wed, May 27, 2015 at 2:54 AM, Stuart Christmas
<stuart.christmas@...> wrote:
> the answers to all your questions are in the blog - you just have to have
> the patience to read it.

no, the right place for this information is on the front page, with
super big sans-serif typeface. trust me, i spent some 5 minutes to
find information, the five minutes it deserves. this is the service
you are providing. thank you, i can write software. i can even write
cryptographic entropy whitener. i don't care about your whitening
algorithm. i also don't care about your software. what i do care about
is an in-depth analysis on why do yo think there is so much entropy,
and what is the actual source of that entropy. if you indeed have a
document about these, give us a direct link.

> Also, you say "if your proposed method comes with a complex extractor, it is
> bullshit".... how so?

as i have explained, whitening is easy. not only easy, already done.
it is not market-worthy. i can write a much slimmer, cheaper, more
general and more secure and robust whitener in no time. i only need a
proper estimate on entropy content.
Michael Nelson | 26 May 23:28 2015
Picon

Timeline graphic of hacking attacks


This new site has a timeline of hacking attacks (Target, Sony, Tesla, etc.).  You can click on an attack and see a summary.  It starts early 2013.  Though it's a new site, I find it surprisingly useful -- both to recall what an attack was, and to get a feel for the range of attacks out there.  Built by security jock Paul Chen.

Mike

_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography
Russell Leidich | 26 May 05:01 2015
Picon

Enranda: 4MB/s Userspace TRNG

As annouced here in the original Jytter blog:

http://jytter.blogspot.com

It has been a long 3 years since Jytter was released. Enranda is now available for download, analysis, and criticism. It's open source with awesome licensing terms, courtesy of Tigerspike:

http://tigerspike.com

Enranda is a cryptographically secure (in the postquantum sense) true random number generator requiring nothing but a timer (ideally, the CPU timestamp counter). It produces roughly 4 megabytes of noise per second, which puts it in the same bandwidth league as physical quantum dot entropy sources (from camera pixel noise). It would be easy to reach much higher bandwidths by reading the timer in a tight loop while feeding it into a PRNG, but probably not safely so. The documentation goes to considerable lengths to explain this assertion.

If you can demonstrate that Enranda is biased in a measurable way, or simply buggy, then you rock.

You can get the commandline demo, the documentation, and even a text capture of the live demo at:

http://enranda.blogspot.com

By the way, Enranda's hardness is based in part on Dyspoissometer, a new statistical analysis package focussed on measuring dyspoissonism, that is, the extent to which a discrete set deviates from what we would asymptotically consider to be a Poisson distribution. You can get the demo, the documentation, and a demo capture at:

http://dyspoissonism.blogspot.com

May your ideas be random!

Russell Leidich

_______________________________________________
cryptography mailing list
cryptography@...
http://lists.randombit.net/mailman/listinfo/cryptography

Gmane