From laanwj at gmail.com  Mon Sep  1 01:25:23 2014
From: laanwj at gmail.com (Wladimir)
Date: Mon, 1 Sep 2014 10:25:23 +0200
Subject: [Bitcoin-development] Testing and reviewing requested for work on Bitcoin Core wallet
Message-ID: <CA+s+GJD_sKjJ52dA6W0aj1tPNV8bTCqX9H0iuQ56bpi6w3s7wg@mail.gmail.com>

Hello,

Cozz Lovan has been doing great work on Bitcoin Core's wallet code lately.

If anyone cares about Bitcoin Core's wallet, for example its
performance, do help testing and reviewing these improvements so that
they can make it into 0.10:

Subtract fee from amount
https://github.com/bitcoin/bitcoin/pull/4331

[Wallet] Improve ReorderTransactions(..)
https://github.com/bitcoin/bitcoin/pull/4697

[Wallet] Replace OrderedTxItems(..) with in-memory map
https://github.com/bitcoin/bitcoin/pull/4702

[Qt] Call checkBalanceChanged() periodically instead for every updated tx
https://github.com/bitcoin/bitcoin/pull/4712

Move g_signals.SetBestChain(..) below SyncWithWallets
https://github.com/bitcoin/bitcoin/pull/4798

[Wallet] Call SetBestChain before and after rescan
https://github.com/bitcoin/bitcoin/pull/4800

[Wallet] Do not flush the wallet in AddToWalletIfInvolvingMe(..)
https://github.com/bitcoin/bitcoin/pull/4805

Wladimir

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

----- End forwarded message -----




From eugen at leitl.org  Mon Sep  1 02:55:52 2014
From: eugen at leitl.org (Eugen Leitl)
Date: Mon, 1 Sep 2014 11:55:52 +0200
Subject: [tt] NYT: Hal Finney, Cryptographer and Bitcoin Pioneer, Dies at 58
Message-ID: <20140901095552.GK13138@leitl.org>

----- Forwarded message from Frank Forman <checker at panix.com> -----


From eugen at leitl.org  Mon Sep  1 02:58:03 2014
From: eugen at leitl.org (Eugen Leitl)
Date: Mon, 1 Sep 2014 11:58:03 +0200
Subject: [Bitcoin-development] Testing and reviewing requested for work on
 Bitcoin Core wallet
Message-ID: <20140901095803.GM13138@leitl.org>

----- Forwarded message from Wladimir <laanwj at gmail.com> -----


From grarpamp at gmail.com  Mon Sep  1 10:54:25 2014
From: grarpamp at gmail.com (grarpamp)
Date: Mon, 1 Sep 2014 13:54:25 -0400
Subject: [Cryptography] cryptography Digest, Vol 16, Issue 26
In-Reply-To: <CAC9sZLdjG=E0QhbUNtSK=YXXmpVA3joHFJDtE5rfkxqYJRx=qA@mail.gmail.com>
References: <mailman.1.1409155201.22342.cryptography@metzdowd.com>
 <CAC9sZLdjG=E0QhbUNtSK=YXXmpVA3joHFJDtE5rfkxqYJRx=qA@mail.gmail.com>
Message-ID: <CAD2Ti2_pRhU7qUamuiibKAjQY=pzUAD3cw3zh_X4ROQ_Ja=GJA@mail.gmail.com>

On Wed, Aug 27, 2014 at 3:21 PM, Peter Trei <petertrei at gmail.com> wrote:
> On 26 Aug 2014 21:28:49 -0000 "John Levine" <johnl at iecc.com> wrote:
>
> Subject: Re: [Cryptography] toll bills, was Encryption opinion
>
>>> I've not been on any of those
> ?>roads, but I've gotten three e-mailed bills in the last two weeks
>>>that to the unskeptical eye look fully legitimate, which also
>>>indicates that the phishers know that my geolocation makes driving
>>>such roads plausible.
>
>> It's not geolocation, everyone is getting E-ZPass spam this month.  I
>> have an E-ZPass account, and can report that it looks nothing like the
>> real mail they send, which just tells you to look at their web site
>> for a statement or other message.  This is aimed at the same kinds of
>> suckers who fall for 419.
>
>> I also got an actual e-mail this month from an actual toll road
>> telling me about an actual charge due to actually driving on it.  It
>> was the 407 in Toronto, not E-ZPass, and I knew they'd be billing me
>> so I set up an account so they'd e-mail me instead of the default
>> paper bill, but still ...
>
>> John
>
>> PS: So is there any crypto on toll transponders, or could I
>> skim them from the side of the road and make clones?
>
> Apparently some do, most don't. EZ Passes are made by
> Kapsch (Kapsch.net), which has data sheets available, and has
> made their protocols open source.
>
> You can easily modify one to inform you of when its queried:
> http://www.popsci.com/article/diy/ezpass-hack-covert-scanning

" Bear <bear at sonic.net>
Aug 28 (4 days ago)
I've got one.  It's an envelope lined with copper foil. I get
the pass out when approaching a toll booth, and put it back
(and put the 'chip clip' back on the envelope to ensure that
the foil makes good electrical contact) as I pull away from
the toll booth.
A toggle switch would be nice, but we can be fairly confident
that a Faraday cage is working as designed. Bear. "

> ...and it turns out they're queried all over the place, not just at
> tolls. There have been proposals for a 'kill switch' which would
> allow you to disable it except when approaching a toll, but I
> haven't seen that.
>
> But its moot, anyway. Transponders are being replaced by
> license plate scanning. This is yet another case where we
> accepted something (permanently visible LPs) on the basis
> that no one could track every plate, everywhere, all the time.
> Technology moved on, and invalidated that promise of
> privacy-unless-they-really-really-need-to-violate-it.

So you need active defense of plate masks/obfuscation
mechanichs... flip down blanking devices, character cards,
mask films on a loop roll motor, OLED plates. DIY 007. Drive masked,
reveal as needed. Worst case, you don't notice the cop car
near you and get a paper ticket for no plate or a hacked random
nonspec plate. $100+... better than daily loss of privacy to
intersection/roadside cams, google robot cars, etc.

Next battle... killing all the manufacturer supplied transponders
in your car...

Then your cell phone.




From grarpamp at gmail.com  Mon Sep  1 14:15:03 2014
From: grarpamp at gmail.com (grarpamp)
Date: Mon, 1 Sep 2014 17:15:03 -0400
Subject: If you ran a Bitcoin related service before the thing hit $100
 you prolly ought to be somewhat concerned and/or prepared
In-Reply-To: <CAJVRA1REPfttKPuVzfasaV-T7rhW1hpJJAGxo_Ozp9R2iqX1MA@mail.gmail.com>
References: <20140826110556.GC26986@leitl.org>
 <CAJVRA1REPfttKPuVzfasaV-T7rhW1hpJJAGxo_Ozp9R2iqX1MA@mail.gmail.com>
Message-ID: <CAD2Ti2-tUK0p+7o33CQVy12Hg5F5S1orQwFbf21xbZfsi51y7Q@mail.gmail.com>

On Tue, Aug 26, 2014 at 3:01 PM, coderman <coderman at gmail.com> wrote:
> On 8/26/14, Eugen Leitl <eugen at leitl.org> wrote:
>> ... Under the impression the two gentlemen at my door step might be
>> some sort of process servers or collections agents visiting about my
>> substantial student loan debt I begrudgingly inquire as to what is going
>> on.
>> They inquire as to who I am, and I inquire as to who they are...
>> 1 When they
>> show badges I offer confirmation that I am indeed the person referred to
>> frequently by the slave name2 they used...
>> ... [keeps on talking] ...

> doing it right -^

Not necessarily... he doesn't indicate being detained (per RS) and subsequently
asked, so he has no obligation (in US) to respond in confirmation. And
unbelievably,
he keeps on talking. He even lets them engineer themselves into becoming his
'friends' and talking yet more... "A notable thing that kept coming up was an
incredulity...". The blog is probably not the full recount and this
guy should review
situation with a lawyer. Always good to discern who's knocking and why though.
And there's always a careful and amiable balance to be made, but
still, trolls at
your door be trolling...
https://www.youtube.com/watch?v=6wXkI4t7nuc
https://www.youtube.com/watch?v=eCVa-bmEHuQ
https://www.youtube.com/watch?v=ATlf5A2Qwpo

>> If they are asking about BTCPak now, who knows how long the backlog of
>> sites and ventures they are working through is.

With so many bitcoin ventures, players and events... probably much
longer than can be fit within time limits.




From coderman at gmail.com  Mon Sep  1 20:42:37 2014
From: coderman at gmail.com (coderman)
Date: Mon, 1 Sep 2014 20:42:37 -0700
Subject: If you ran a Bitcoin related service before the thing hit $100
 you prolly ought to be somewhat concerned and/or prepared
In-Reply-To: <CAD2Ti2-tUK0p+7o33CQVy12Hg5F5S1orQwFbf21xbZfsi51y7Q@mail.gmail.com>
References: <20140826110556.GC26986@leitl.org>
 <CAJVRA1REPfttKPuVzfasaV-T7rhW1hpJJAGxo_Ozp9R2iqX1MA@mail.gmail.com>
 <CAD2Ti2-tUK0p+7o33CQVy12Hg5F5S1orQwFbf21xbZfsi51y7Q@mail.gmail.com>
Message-ID: <CAJVRA1SrG2hO5ribx7R8Lxj1pAX3UUMt+b7e5XZXWm7Dyz4_aA@mail.gmail.com>

On 9/1/14, grarpamp <grarpamp at gmail.com> wrote:
> ...
> Not necessarily... he doesn't indicate being detained (per RS) and
> subsequently asked, so he has no obligation (in US) to respond in confirmation.

you don't have to be detained per Reasonable Suspicion for RS to
apply. so if there was RS refusing to identify could get you arrested
by itself. [0][1]  i imagine you'd only discover you were detained if
you tried to leave the premises?

presumably the "use of bitcoin for anonymous pre-paid payments
associated with other known criminal activity" or similar bullshit was
bravely painted "reasonable".

i am not a lawyer, of course, but this is my understanding of how one
explained it to me. it also seems this guidance may be very state
specific.



>  And unbelievably, he keeps on talking.

it went bad from there ...

get their badges and names before identifying yourself.  then let your
very next words be "i demand legal counsel be present for any further
inquiry."

best regards,



0. "Hiibel v. Sixth Judicial District Court of Nevada"
 - http://supreme.justia.com/us/542/177/case.html

1. "Stop and identify statutes"
 - https://en.wikipedia.org/wiki/Stop_and_identify_statutes




From coderman at gmail.com  Tue Sep  2 00:54:40 2014
From: coderman at gmail.com (coderman)
Date: Tue, 2 Sep 2014 00:54:40 -0700
Subject: =?UTF-8?B?UmU6IOKAmEZha2XigJkgY2VsbHBob25lIHRvd2VycyBmb3VuZCBpbiBVLlMu?=
In-Reply-To: <1409638191.2386451.162536281.412A63DC@webmail.messagingengine.com>
References: <1409638191.2386451.162536281.412A63DC@webmail.messagingengine.com>
Message-ID: <CAJVRA1Rzw=si=uRs1V8LJQ2-2g=77wdr=wMtKzv9RBx1aLY7rA@mail.gmail.com>

On 9/1/14, Alfie John <alfiej at fastmail.fm> wrote:
> ...
>   "The fake ‘towers’ – computers which wirelessly attack cellphones via
>   the “baseband” chips built to allow them to communicate with their
>   networks, can eavesdrop and even install spyware,...
>
>   "What we find suspicious is that a lot of these interceptors are
>   right on top of U.S. military bases."


this is a classified "data loss prevention" mechanism, if you will.
rather than deny cell use on sensitive locations (some locales demand
no digital electronics) a happy middle ground of surreptitious deep
inspection on demand is applied.

what was once foreign battlefield only, is now plentiful lawful access, locally.

don't be fooled; no less malicious in re-purpose. these are war
weapons aimed at all of us...




From alfiej at fastmail.fm  Mon Sep  1 23:09:51 2014
From: alfiej at fastmail.fm (Alfie John)
Date: Tue, 02 Sep 2014 01:09:51 -0500
Subject: =?utf-8?Q?=E2=80=98Fake=E2=80=99=20cellphone=20t?=
 =?utf-8?Q?owers=20found=20in=20U.S?= =?utf-8?Q?.?=
Message-ID: <1409638191.2386451.162536281.412A63DC@webmail.messagingengine.com>

If you've never considered the threat of baseband attacks to be
real, but considered them more of a speculative possibility,
speculate no more:

  http://www.welivesecurity.com/2014/08/28/android-security-2/

  "The fake ‘towers’ – computers which wirelessly attack cellphones via
  the “baseband” chips built to allow them to communicate with their
  networks, can eavesdrop and even install spyware, ESD claims. They are
  a known technology - but the surprise is that they are in active use.

  "Interceptor use in the U.S. is much higher than people had
  anticipated,” Goldsmith says.  “One of our customers took a road trip
  from Florida to North Carolina and he found eight different
  interceptors on that trip.  We even found one at South Point Casino in
  Las Vegas."

  "What we find suspicious is that a lot of these interceptors are
  right on top of U.S. military bases."

Alfie

-- 
  Alfie John
  alfiej at fastmail.fm




From coderman at gmail.com  Tue Sep  2 01:25:32 2014
From: coderman at gmail.com (coderman)
Date: Tue, 2 Sep 2014 01:25:32 -0700
Subject: going double cryptome at DEF CON 22
In-Reply-To: <20140730153941.GR26986@leitl.org>
References: <CAJVRA1SbY1P3mAi7m4etQ8cwHu1LW0_tJAR_5OF-GG9UX-oUxw@mail.gmail.com>
 <20140730153941.GR26986@leitl.org>
Message-ID: <CAJVRA1TFWLQE2o-8OCL1LGpY+EZqmELtr=PgucvtXH_coOutMQ@mail.gmail.com>

On 7/30/14, Eugen Leitl <eugen at leitl.org> wrote:
> ...
> Can you keep up the docs for a while? I forgot to mirror them.

plans to provide a mirror of the DEF CON media archive indefinitely
delayed.  also redundant now that media.defcon.org is populated...

in case you did not hear already, they canceled drive #3 from the
media set, which was to include the cryptome mirror.

alas, my copies also corrupted for the two volumes that were provided.
perhaps prominently labeling them "GAY PR()N vol 0x0A:", and "...
0x0B" causing unintended consequence?

.
.
.

at any rate, the onion mirrors will be up for another month, but maybe
not much longer...


best regards,




From coderman at gmail.com  Tue Sep  2 01:30:40 2014
From: coderman at gmail.com (coderman)
Date: Tue, 2 Sep 2014 01:30:40 -0700
Subject: =?UTF-8?B?UmU6IOKAmEZha2XigJkgY2VsbHBob25lIHRvd2VycyBmb3VuZCBpbiBVLlMu?=
In-Reply-To: <54057B5F.2090300@cathalgarvey.me>
References: <1409638191.2386451.162536281.412A63DC@webmail.messagingengine.com>
 <54057B5F.2090300@cathalgarvey.me>
Message-ID: <CAJVRA1QbsYW+9sKtaypvzQt6nVgkTZR2Quzq4PrQJ2QgexiXWw@mail.gmail.com>

On 9/2/14, Cathal Garvey <cathalgarvey at cathalgarvey.me> wrote:
>...
> ..based on the word of a company that markets "firewalled baseband
> phones" and cites personal research in undisclosed locations instead of
> releasing actual data.
>
> Don't get me wrong, basebands are probably swiss cheese and they are
> often (or usually?) masters to the mobile OS.


this is totally marketing oriented, as the traditional "baseband"
attack is arbitrary code execution within the baseband processor
embedded system rather than opportunistic advantage of inherent
signaling and authentication weaknesses in protocol implementations.

the latter can be "weaponized" by nearly anyone with a full duplex
SDR. the former is usually accomplished with insider access or
painstaking expertise - the opposite of accessible.

if you read between the lines you can see how they classify any tower
aggressively peering stations in range as "baseband intercept attack"
for their maximal PR purposing.


best regards,




From coderman at gmail.com  Tue Sep  2 03:36:08 2014
From: coderman at gmail.com (coderman)
Date: Tue, 2 Sep 2014 03:36:08 -0700
Subject: =?UTF-8?B?UmU6IOKAmEZha2XigJkgY2VsbHBob25lIHRvd2VycyBmb3VuZCBpbiBVLlMu?=
In-Reply-To: <54059264.3010005@cathalgarvey.me>
References: <1409638191.2386451.162536281.412A63DC@webmail.messagingengine.com>
 <54057B5F.2090300@cathalgarvey.me>
 <CAJVRA1QbsYW+9sKtaypvzQt6nVgkTZR2Quzq4PrQJ2QgexiXWw@mail.gmail.com>
 <54059264.3010005@cathalgarvey.me>
Message-ID: <CAJVRA1Qemk1VDe=zbkWctjpL8byCocB9SnM5d5P_uYdq7aRfkg@mail.gmail.com>

On 9/2/14, Cathal Garvey <cathalgarvey at cathalgarvey.me> wrote:
> ...
> Also, that nameless towers are assumed to be government intercepts. I
> can imagine (though I don't know much, if I'm honest) situations in
> which backup towers brought in for events (concerts, public gatherings,
> etc.) might be contracted from third parties and present apparently
> aberrant nomenclature, if any. These backup cells might be brought into
> otherwise quiet areas for normal maintenance, or to back up faulty
> towers, etc.;

a legitimate roaming association when out of normal coverage areas is
different from what could be called an "intercept attack".  that is to
say, actively placing an intercept channel in front of a station when
that station is able to associate with legitimate carrier towers is an
active attack against carrier networks, while a roaming association
when out of range of carrier is a desired function and not malicious.

to complicate matters, a number of years back i reported on active
MitM attacks on 4G networks by interfering with existing associations
to force a roaming hand-off to attacker endpoint.  thus a
determination of what is "normal" perspective to carrier towers
requires a span of time combined with local observation. (snapshots
not sufficient)

also, the new broadband back-haul'ed femtocells that some carriers are
distributing may or may not appear as an impersonating interceptor,
exhibiting the usual properties of a rogue tower while actually being
carrier provisioned capacity.


> ... on the other hand, why would the
> US feds need to roll out a nationwide cell tower network to spy on
> everyone when..they already have one? :)

this is an interesting question.  presumably there are two reasons: a)
that the usual intercepts require judicial approval and logistic
delays, and b) manipulating the local link and signaling channel
affords deep "enabling" of the target via means not cleared to transit
untrusted networks.

fun questions, encourage more research!
 :P




From coderman at gmail.com  Tue Sep  2 04:57:14 2014
From: coderman at gmail.com (coderman)
Date: Tue, 2 Sep 2014 04:57:14 -0700
Subject: If you ran a Bitcoin related service before the thing hit $100
 you prolly ought to be somewhat concerned and/or prepared
In-Reply-To: <CAD2Ti2_p5yQC8csoM_WF+cOp33pDrWyLqGt4WefyOQcto5O8Gw@mail.gmail.com>
References: <20140826110556.GC26986@leitl.org>
 <CAJVRA1REPfttKPuVzfasaV-T7rhW1hpJJAGxo_Ozp9R2iqX1MA@mail.gmail.com>
 <CAD2Ti2-tUK0p+7o33CQVy12Hg5F5S1orQwFbf21xbZfsi51y7Q@mail.gmail.com>
 <CAJVRA1SrG2hO5ribx7R8Lxj1pAX3UUMt+b7e5XZXWm7Dyz4_aA@mail.gmail.com>
 <CAD2Ti2_p5yQC8csoM_WF+cOp33pDrWyLqGt4WefyOQcto5O8Gw@mail.gmail.com>
Message-ID: <CAJVRA1QWKAqHs_Do+PeFR6E_LpLsyqnmaVPAFAe6iGCL9X0gqQ@mail.gmail.com>

On 9/2/14, grarpamp <grarpamp at gmail.com> wrote:
> ...
> Federal minimum is in Hiibel. States may be more intrusive,
> at risk of unconstitutionality. There may still be an untested claim
> to the Fifth at 542:177:190,191.

is anyone pursuing this in any other states? the ACLU seems to list
just Hiibel. ..


> If you read this stuff you'd change that 404 to
> http://www.supremecourt.gov/opinions/slipopinions.aspx?Term=03
> http://www.supremecourt.gov/opinions/03pdf/03-5554.pdf
> http://www.supremecourt.gov/opinions/boundvolumes/542bv.pdf

those are better. thanks :)




From grarpamp at gmail.com  Tue Sep  2 04:19:56 2014
From: grarpamp at gmail.com (grarpamp)
Date: Tue, 2 Sep 2014 07:19:56 -0400
Subject: If you ran a Bitcoin related service before the thing hit $100
 you prolly ought to be somewhat concerned and/or prepared
In-Reply-To: <CAJVRA1SrG2hO5ribx7R8Lxj1pAX3UUMt+b7e5XZXWm7Dyz4_aA@mail.gmail.com>
References: <20140826110556.GC26986@leitl.org>
 <CAJVRA1REPfttKPuVzfasaV-T7rhW1hpJJAGxo_Ozp9R2iqX1MA@mail.gmail.com>
 <CAD2Ti2-tUK0p+7o33CQVy12Hg5F5S1orQwFbf21xbZfsi51y7Q@mail.gmail.com>
 <CAJVRA1SrG2hO5ribx7R8Lxj1pAX3UUMt+b7e5XZXWm7Dyz4_aA@mail.gmail.com>
Message-ID: <CAD2Ti2_p5yQC8csoM_WF+cOp33pDrWyLqGt4WefyOQcto5O8Gw@mail.gmail.com>

On Mon, Sep 1, 2014 at 11:42 PM, coderman <coderman at gmail.com> wrote:
> On 9/1/14, grarpamp <grarpamp at gmail.com> wrote:
>> ...
>> Not necessarily... he doesn't indicate being detained (per RS) and
>> subsequently asked, so he has no obligation (in US) to respond in confirmation.
>
> you don't have to be detained per Reasonable Suspicion for RS to
> apply. so if there was RS refusing to identify could get you arrested
> by itself. [0][1]  i imagine you'd only discover you were detained if
> you tried to leave the premises?

Detainer is only permissible via specific and articulable facts and rational
inference therefrom leading to RS [Terry]. Only when detained are you
required to name yourself if asked/ordered [Hiibel]. If you're 'being detained',
you may leave when you're 'free to go'. Otherwise you may keep on walking
[past your 'casual' encounter]. Detainer is different from arrest (per PC).

> state specific

Federal minimum is in Hiibel. States may be more intrusive,
at risk of unconstitutionality. There may still be an untested claim
to the Fifth at 542:177:190,191.

http://www.papersplease.org/
http://www.papersplease.org/hiibel/
https://en.wikipedia.org/wiki/Reasonable_suspicion
https://en.wikipedia.org/wiki/Probable_cause

> 0. "Hiibel v. Sixth Judicial District Court of Nevada"
>  - http://supreme.justia.com/us/542/177/case.html

If you read this stuff you'd change that 404 to
http://www.supremecourt.gov/opinions/slipopinions.aspx?Term=03
http://www.supremecourt.gov/opinions/03pdf/03-5554.pdf
http://www.supremecourt.gov/opinions/boundvolumes/542bv.pdf




From jya at pipeline.com  Tue Sep  2 04:35:25 2014
From: jya at pipeline.com (John Young)
Date: Tue, 02 Sep 2014 07:35:25 -0400
Subject: "Fake" Comsec Found Everywhere
Message-ID: <E1XOmMN-0000TS-ED@elasmtp-masked.atl.sa.earthlink.net>

Anxiety and fears about loss of privacy through surreptitious
and ubiquitous technology, with concomintant rise of advocates
of defenses, parallels the age-old scam of the devil inside
humans attacking faith in god(s) requiring constant remediation
by religion, in particular by buying into costly, elaborate edifices,
ceremonies, couture, sermons, damnations, excommunications,
informants, behavior police, burning of witches, celebrations
of saints. Remind of the crypto wars still raging?

Comsec might be seen as a cult of fetishistic technology,
crypto its sacred text of salvation and protection from
demons forever being publicized by the preachers of
how to hide your sins from the sin spies, the main sin
being apostasy about national security armed to the max
with weapons of mass punishment of disbelievers of
of one's own faith against that of competitors, especially
competitiors setting up subversive storefronts of alternative
faiths.

Worse of all, the crypto-rebels writing their own code of
sin and salvation, defying authorities, seducing youngsters,
leaking secrets of the official corruption, mocking official
old gods in favor or new ones home-brewed on the
electronic frontier.

Snake oil is as old as snakes whispering to naked apes
once happy copulating without devils or gods hurling
sand into the amply lubricated in and out to make new
copulants free of imaginary fears and anxieties that
pleasure is bad, don't seek it without permission,
don't do it unless paid in advance, don't dream of
it or the devil wins, don't self-satisfy or narcissism
destroys. Right here are some helpful aids to control
your urges by allowing experts to tell you what's right
and wrong. You will need this protection inside
and outside, everywhere, all the time. Let us
pray. Your wallet please.





From cathalgarvey at cathalgarvey.me  Tue Sep  2 01:10:07 2014
From: cathalgarvey at cathalgarvey.me (Cathal Garvey)
Date: Tue, 02 Sep 2014 09:10:07 +0100
Subject: =?UTF-8?B?4oCYRmFrZeKAmSBjZWxscGhvbmUgdG93ZXJzIGZvdW5kIGluIFU=?=
 =?UTF-8?B?LlMu?=
In-Reply-To: <1409638191.2386451.162536281.412A63DC@webmail.messagingengine.com>
References: <1409638191.2386451.162536281.412A63DC@webmail.messagingengine.com>
Message-ID: <54057B5F.2090300@cathalgarvey.me>

> If you've never considered the threat of baseband attacks to be
> real, but considered them more of a speculative possibility,
> speculate no more:

..based on the word of a company that markets "firewalled baseband
phones" and cites personal research in undisclosed locations instead of
releasing actual data.

Don't get me wrong, basebands are probably swiss cheese and they are
often (or usually?) masters to the mobile OS. On my model of phone IIRC
they even directly share some RAM, so they can read/write willy-nilly
the Android RAM. So the idea of baseband attacks overwhelming the OS is
perfectly sound and something to bear in mind.

All that said, this is a glorified marketing campaign for the company in
question, with surprising complicity from people like Cory Doctorow (who
even uncritically describes their "patent pending" technology, somewhat
out of character for a usually pretty freedom-minded person). The
correct response, in my opinion, is "Show us the proof and the fake
tower locations or STFU".

On 02/09/14 07:09, Alfie John wrote:
> If you've never considered the threat of baseband attacks to be
> real, but considered them more of a speculative possibility,
> speculate no more:
> 
>   http://www.welivesecurity.com/2014/08/28/android-security-2/
> 
>   "The fake ‘towers’ – computers which wirelessly attack cellphones via
>   the “baseband” chips built to allow them to communicate with their
>   networks, can eavesdrop and even install spyware, ESD claims. They are
>   a known technology - but the surprise is that they are in active use.
> 
>   "Interceptor use in the U.S. is much higher than people had
>   anticipated,” Goldsmith says.  “One of our customers took a road trip
>   from Florida to North Carolina and he found eight different
>   interceptors on that trip.  We even found one at South Point Casino in
>   Las Vegas."
> 
>   "What we find suspicious is that a lot of these interceptors are
>   right on top of U.S. military bases."
> 
> Alfie
> 

-- 
Twitter: @onetruecathal, @formabiolabs
Phone: +353876363185
Blog: http://indiebiotech.com
miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x988B9099.asc
Type: application/pgp-keys
Size: 6176 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140902/213fd297/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140902/213fd297/attachment.sig>

From grarpamp at gmail.com  Tue Sep  2 13:14:08 2014
From: grarpamp at gmail.com (grarpamp)
Date: Tue, 2 Sep 2014 16:14:08 -0400
Subject: Privacy Law [Hiibel, Terry, ID, etc] [was: Run Bitcoin,
 be concerned/prepared]
Message-ID: <CAD2Ti28y3ChOh0qXiJb=o=SvfTCdLkj=M3mZYg-dM4u43sqYig@mail.gmail.com>

On Tue, Sep 2, 2014 at 7:57 AM, coderman <coderman at gmail.com> wrote:
> is anyone pursuing this in any other states? the ACLU seems to list
> just Hiibel. ..

I don't know, someone could write ACLU and ask.
https://www.aclu.org/technology-and-liberty/hiibel-v-sixth-judicial-district-court-state-nevada

> those are better. thanks :)

Now with Nevada, number 38876...
http://caseinfo.nvsupremecourt.us/public/caseView.do?csIID=4764

Oral args multimedia...
http://www.oyez.org/cases/2000-2009/2003/2003_03_5554

Epic flavor...
http://epic.org/privacy/hiibel/

Cornell 'legal resources' section is pretty good.
http://www.law.cornell.edu/

https://www.aclu.org/organization-news-and-highlights/supreme-court-ends-term-reaffirmation-rule-law-during-times-nationa

[Subject updated, gmail dethreaded, refer back for earlier links.]




From grarpamp at gmail.com  Tue Sep  2 15:12:27 2014
From: grarpamp at gmail.com (grarpamp)
Date: Tue, 2 Sep 2014 18:12:27 -0400
Subject: =?UTF-8?B?UmU6IOKAmEZha2XigJkgY2VsbHBob25lIHRvd2VycyBmb3VuZCBpbiBVLlMu?=
In-Reply-To: <CAJVRA1Qemk1VDe=zbkWctjpL8byCocB9SnM5d5P_uYdq7aRfkg@mail.gmail.com>
References: <1409638191.2386451.162536281.412A63DC@webmail.messagingengine.com>
 <54057B5F.2090300@cathalgarvey.me>
 <CAJVRA1QbsYW+9sKtaypvzQt6nVgkTZR2Quzq4PrQJ2QgexiXWw@mail.gmail.com>
 <54059264.3010005@cathalgarvey.me>
 <CAJVRA1Qemk1VDe=zbkWctjpL8byCocB9SnM5d5P_uYdq7aRfkg@mail.gmail.com>
Message-ID: <CAD2Ti2-MVGZshstu8QiQXnLA2--hJtszzOeMxFDoHNir0ud95w@mail.gmail.com>

On Tue, Sep 2, 2014 at 6:36 AM, coderman <coderman at gmail.com> wrote:
> delays, and b) manipulating the local link and signaling channel
> affords deep "enabling" of the target via means not cleared to transit
> untrusted networks.
>
> fun questions, encourage more research!

With SDR you can be both tower and phone. So take
your rig out traveling and start decoding the traffic you
dump off these enablers. Post their actions and means.
Play spot the rootshell over the air.




From grarpamp at gmail.com  Tue Sep  2 23:17:25 2014
From: grarpamp at gmail.com (grarpamp)
Date: Wed, 3 Sep 2014 02:17:25 -0400
Subject: UWB Time Domain SDR Radio
Message-ID: <CAD2Ti29ccOdvr9ZD8T_YfG+Ujvw-6roQBMYh6csEiKggaSpSUg@mail.gmail.com>

On Tue, Aug 19, 2014 at 10:50 AM, Troy Benjegerdes <hozer at hozed.org> wrote:
> On Tue, Aug 19, 2014 at 02:37:35PM +0200, Eugen Leitl wrote:
>> > > In unrelated vein, I've recently read that it was the spooks
>> > > that killed the digital pulse radio star, by limiting licensend
>> > > power to toy levels. Apparently they were very unhappy with a
>> > > radio that's hard to look for.
>> http://www.cringely.com/2014/05/15/nsa-help-kill-uwb/

" Rather than using specific frequencies UWB transmitted on all
frequencies at the same time. The key was knowing  when and where in
the frequency band to expect a bit to appear. Two parties with
synchronized clocks and codebooks could agree that at 10 nanoseconds
after the hour at a certain frequency or range of frequencies a bit
would appear if one was intended. The presence of that signal at that
time and place was a 1 and the absence was a 0. But if you didn’t know
when to listen where — if you weren’t a part of the conversation — it
all looked just like noise."

> UWB is a great idea in theory, until you build an antenna, or you
> avoid the antenna and the UWB noise floor ends up as a DDOS attack
> on all your existing communications channels.

I'm interested in further links to papers regarding this
ultra wide band UWB, pulse position modulation PPM,
time domain TD scheme as it applies to radio spectrum.
Especially any links to hack work being done under software
defined radio SDR.




From grarpamp at gmail.com  Tue Sep  2 23:28:37 2014
From: grarpamp at gmail.com (grarpamp)
Date: Wed, 3 Sep 2014 02:28:37 -0400
Subject: Fwd: [cryptography] JackPair Voice Encryption Dongle
In-Reply-To: <CA+cU71mh-DkaP+wECaMNS_ke9AoHZTKVPrKAnSWZMWk9ogq0Qw@mail.gmail.com>
References: <CA+cU71mh-DkaP+wECaMNS_ke9AoHZTKVPrKAnSWZMWk9ogq0Qw@mail.gmail.com>
Message-ID: <CAD2Ti283XBgEYwk4hsfuETNAGdt9Z8=Exro+f1HHHoSWpKbOpg@mail.gmail.com>

---------- Forwarded message ----------
From: Tom Ritter <tom at ritter.vg>
Date: Mon, Aug 18, 2014 at 9:58 AM
Subject: [cryptography] JackPair Voice Encryption Dongle
To: Randombit List <cryptography at randombit.net>


https://www.kickstarter.com/projects/620001568/jackpair-safeguard-your-phone-conversation
https://www.youtube.com/watch?v=rh6yF79FkAA

DH with a 'Pairing Code' (ala ZRTP) to prevent MITM. Light on exact
details, but they say it will be open source.

"we think 10-12 digits [for a pairing code] is probably good enough,
and more friendly for human reading"

"We are using Diffie-Hellman at this point, and working on Elliptic
curve Diffie-Hellman."

"Synchronous stream cipher is used, with XOR'ed key-stream resulted
from pseudo random number generator using OTSK as seed, and periodic
marker flag for re-synchronization."

"JackPair uses audio codec from Codec2, which has reasonable good
sound quality at 1.2kbps. We have tested JackPair on top of GSM AMR
4.75 (Adaptive Multi-Rate, 4.75kbps) and HR (Half-Rate, 6.5kbps)."

"Unlike traditional fax-modem technologies, our modem is designed from
scratch to fight off the optimization done by GSM codec, including
memory-less codec, voice activity detection (VAD)., automatic gain
control (AGC) etc.. Basically we have to use synthesized voice to make
mobile phones & media servers believe our signal is human voice, not
just modulated waves."

-tom
_______________________________________________
cryptography mailing list
cryptography at randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography




From iang at iang.org  Wed Sep  3 01:57:16 2014
From: iang at iang.org (ianG)
Date: Wed, 03 Sep 2014 09:57:16 +0100
Subject: [Cryptography] stories from the real life MITM book
Message-ID: <5406D7EC.2030603@iang.org>

Evidence of MITMs is so rare it has to be trumpeted.  Snippets only.



http://www.popsci.com/article/technology/mysterious-phony-cell-towers-could-be-intercepting-your-calls


http://venturebeat.com/2014/09/02/who-is-putting-up-interceptor-cell-towers-the-mystery-deepens/

To show what the CryptoPhone can do that less expensive competitors
cannot, he points me to a map that he and his customers have created,
indicating 17 different phony cell towers known as “interceptors,”
detected by the CryptoPhone 500 around the United States during the
month of July alone. (The map below is from August.)  Interceptors look
to a typical phone like an ordinary tower.  Once the phone connects with
the interceptor, a variety of “over-the-air” attacks become possible,
from eavesdropping on calls and texts to pushing spyware to the device.



http://venturebeat.com/2014/09/02/who-is-putting-up-interceptor-cell-towers-the-mystery-deepens/
Who is putting up ‘interceptor’ cell towers? The mystery deepens

The discovery “appears to confirm real-world use of techniques that have
been highlighted by researchers for years,” said Stephen Ellis, manager
of cyber threat intelligence at security firm iSIGHT Partners. While
noting that his company “cannot confirm the accuracy of this reporting
without further information,” Ellis told us that iSIGHT is “highly
confident that we have observed real-world use of this technique in
support of another of its uses – cyber crime [for] financial gain.”

“We have observed and reported on cases in other parts of the world
where actors are known to have set up fake base stations to send spoofed
SMS messages,” Ellis said, “possibly to send spam or to direct
unsuspecting victims to malicious websites.”

The Federal Communications Commission (FCC) announced last month that it
is launching an investigation into the use of cell network interceptors
by criminal gangs and foreign intelligence.

We asked Goldsmith if he could be mistaken about the towers. Perhaps
they are just commercial ones that seem unusual?

“We can definitely tell” that they’re non-network towers, he said, by
analysis of the infrastructure. These phony towers, without names as
normal towers have, insist to your phone that they must handle the call
and then trick the phone into turning off its normal encryption.

Such a tower tells you that “none of your towers are currently
available,” Goldsmith told us. It says, “‘I’m your tower.’

“If you wanted to listen to a phone call,” he said, “this would be the
easy way.”
_______________________________________________
The cryptography mailing list
cryptography at metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

----- End forwarded message -----




From ryacko at gmail.com  Wed Sep  3 10:45:47 2014
From: ryacko at gmail.com (Ryan Carboni)
Date: Wed, 3 Sep 2014 10:45:47 -0700
Subject: [cryptography] "Godfather of Anonymity" David Chaum on BBC
In-Reply-To: <E1XPAsT-0003pK-MZ@elasmtp-scoter.atl.sa.earthlink.net>
References: <E1XPAsT-0003pK-MZ@elasmtp-scoter.atl.sa.earthlink.net>
Message-ID: <CAO7N=i1tWGM_oXhteB_d7Z=VuN+Ywi4omQaW6WukZXiwP+xYsw@mail.gmail.com>

http://z4.invisionfree.com/NSDraftroom/ar/t8777.htm

I wrote a little something four years ago for a roleplaying website.
Doesn't take much creativity to see this is inevitable in a Patriot
Act-enabled state.

The NMS has long been denied to exist in the Corporate Confederacy. However
> outside observers and analysts agree on how it functions:
>
> All citizens are monitored through the following means:
>
> -Facial recognition of video feed of CCTV cameras in public areas and of
> private security cameras (all private security companies are required to
> submit their feed to the government), identifying an individual's location,
> patterns of movement, and clothing.
> -Citizens are also monitored from the use of transit passes or identity
> checkpoints, which also aides in establishing an individual's location or
> their patterns of movement.
> -Many cities within the Corporate Confederacy have multi-story/elevated
> streets. In order to navigate these streets, many citizens buy GPS systems,
> which inform drivers which streets have the fastest traffic flow, and
> suggest the fastest routes possible. Unfortunately this information is
> cross-correlated by using a database from the government. But not too many
> drivers are complaining, happy to receive this "service."
> -Cell phone GPS tracking.
> -Purchasing patterns based upon credit card information. Citizens who make
> cash purchases are also monitored and identified via face recognition
> programs.
> -Internet browsing habits, downloads, emails forum posts, etc.
> -Conversation analysis by computer programs, which analyze the tone of how
> certain words are said, and the frequency of some words are said. The
> conversations monitored are typically from wiretapped telephone lines, but
> may also included bugged residences or offices.
> -Nonintrusive load monitoring, which monitors the devices plugged into a
> power supply, enabling officials to determine activity within a home
> without planting bugs or cameras, which could enable officials to determine
> when it would be safe to secretly plants bugs or cameras.
> -Random secret house searches, which result in the documentation of
> belongings and appliances.
>
> All this data is cataloged in a database and cross-correlated with the
> routines or actions with other possible terrorists or former terrorists.
> For example redflags would be put up if a person spoke about the government
> in a derisive tone, repeatedly visited websites which glorify terrorists,
> went to meet with a suspected member of a terrorist group repeatedly, and
> began to purchase large quantities of gasoline and fertilizer. Another
> example would be that a person fingered by an informant as a terrorist
> leader would be monitored, and so would individuals suspected of meeting
> with that person.
>
> The NMS was not the result of a concerted project, but was created over
> time as new tools were developed to combat terrorism and threats to public
> safety, and as databases were slowly consolidated. The NMS is maintained by
> an unknown and possibly secret government agency.
>
> Estimated Program Development Costs: $100-275 Billion
> Estimated Maintenace Costs: $40 Billion per annum (for a country with more
> than three and a half billion residents)



On Wed, Sep 3, 2014 at 6:46 AM, John Young <jya at pipeline.com> wrote:

> "Horizon: The defenders of anonymity on the internet"
>
> http://www.bbc.com/news/technology-29032399
>
>
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 4465 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140903/b2447d29/attachment.txt>

From harmony01 at riseup.net  Wed Sep  3 07:06:36 2014
From: harmony01 at riseup.net (harmony)
Date: Wed, 3 Sep 2014 14:06:36 +0000
Subject: [tor-talk] Tor Weekly News — September 3rd, 2014
Message-ID: <20140903140636.03c38791@riseup.net>

========================================================================
Tor Weekly News                                      September 3rd, 2014
========================================================================

Welcome to the thirty-fifth issue of Tor Weekly News in 2014, the weekly
newsletter that covers what is happening in the Tor community.

Tor Browser 3.6.5 and 4.0-alpha-2 are out
-----------------------------------------

The Tor Browser team put out two new releases of the privacy-preserving
web browser. Among the major changes, version 3.6.5 upgrades Firefox to
24.8.0esr, and includes an improved prompt to help users defend against
HTML5 canvas image fingerprinting [1], following a patch by Isis
Lovecruft [2]. Version 4.0-alpha-2 additionally includes the code for
the forthcoming Tor Browser auto-updater (switched off by default) and
“better hardening for Windows and Linux builds” [3].

As ever, you can download the new releases along with their signature
files from the Tor Project’s distribution directory [4]. Please upgrade
as soon as you can.

  [1]: https://lists.torproject.org/pipermail/tor-talk/2014-July/033969.html
  [2]: https://bugs.torproject.org/12684
  [3]: https://lists.torproject.org/pipermail/tor-qa/2014-September/000458.html
  [4]: https://www.torproject.org/dist/torbrowser/

Tails 1.1.1 is out
------------------

The Tails team released [5] version 1.1.1 of the Debian- and Tor-based
live operating system. As well as upgrading key components like Tor,
Iceweasel, and Linux, this release disables I2P by default when Tails is
booted, in response to the vulnerability recently disclosed by Exodus
Intelligence [6]. Like Truecrypt, “i2p” must now be specified as a
parameter on booting by users who wish to use it.

A number of other security fixes and routine improvements make this an
important update for all Tails users. See the full changelog in the
team’s announcement, then update from a running copy of Tails 1.1 if you
have one, or head to the download page [7] if you don’t.

  [5]: https://tails.boum.org/news/version_1.1.1/
  [6]: https://tails.boum.org/security/Security_hole_in_I2P_0.9.13/
  [7]: https://tails.boum.org/download/

Helping Internet services accept anonymous users
------------------------------------------------

Without a large and diverse network, run by thousands of dedicated
volunteers, Tor would be nowhere near as useful or popular as it
currently is. Although the current situation might at times seem
fragile, there are still many places where it is feasible to host Tor
exit nodes.

However, Tor would become much less attractive to users if they found
themselves unable to reach or interact with their favorite websites
while using it, a situation that is unfortunately growing more common as
site administrators and engineers react negatively to instances of
abusive Tor traffic by banning anonymous connections outright. Tor users
and developers, as well as members of other online communities (such as
Wikimedia [8]), have tried to address the issue before, but real
progress has yet to be made.

Roger Dingledine wrote a “call to arms” [9] explaining the problem in
detail and exploring possible paths to a solution: “Step one is to
enumerate the set of websites and other Internet services that handle
Tor connections differently from normal connections […]. Step two is to
sort the problem websites based on how amenable they would be to our
help”.

Since the problem involves humans as much as it does machines, anyone
working on it will have to be both “technical” but also ”good at
activism”. If you fit that description, OTF has expressed interest in
funding work on this issue through their Information Controls Fellowship
Program [10]. Please read Roger’s blog post in full for more details.

  [8]: https://meta.wikimedia.org/wiki/Grants:IdeaLab/Partnership_between_Wikimedia_community_and_Tor_community
  [9]: https://blog.torproject.org/blog/call-arms-helping-internet-services-accept-anonymous-users
 [10]: https://www.opentechfund.org/labs/fellowships

Monthly status reports for August 2014
--------------------------------------

The wave of regular monthly reports from Tor project members for the
month of August has begun. Damian Johnson released his report
first [11], followed by reports from Georg Koppen [12], Sherief
Alaa [13], Noel Torres [14], Kevin P Dyer [15], Nick Mathewson [16],
Lunar [17], Arthur D. Edelstein [18], Karsten Loesing [19], Andrew
Lewman [20], Arlo Breault [21], Pearl Crescent [22], and Michael Schloh
von Bennewitz [23].

Lunar also reported on behalf of the help desk [24], and Mike Perry did
the same for the Tor Browser team [25].

 [11]: https://lists.torproject.org/pipermail/tor-reports/2014-August/000626.html
 [12]: https://lists.torproject.org/pipermail/tor-reports/2014-August/000627.html
 [13]: https://lists.torproject.org/pipermail/tor-reports/2014-September/000628.html
 [14]: https://lists.torproject.org/pipermail/tor-reports/2014-September/000629.html
 [15]: https://lists.torproject.org/pipermail/tor-reports/2014-September/000630.html
 [16]: https://lists.torproject.org/pipermail/tor-reports/2014-September/000633.html
 [17]: https://lists.torproject.org/pipermail/tor-reports/2014-September/000635.html
 [18]: https://lists.torproject.org/pipermail/tor-reports/2014-September/000636.html
 [19]: https://lists.torproject.org/pipermail/tor-reports/2014-September/000637.html
 [20]: https://lists.torproject.org/pipermail/tor-reports/2014-September/000638.html
 [21]: https://lists.torproject.org/pipermail/tor-reports/2014-September/000639.html
 [22]: https://lists.torproject.org/pipermail/tor-reports/2014-September/000640.html
 [23]: https://lists.torproject.org/pipermail/tor-reports/2014-September/000641.html
 [24]: https://lists.torproject.org/pipermail/tor-reports/2014-September/000634.html
 [25]: https://lists.torproject.org/pipermail/tor-reports/2014-September/000642.html

Miscellaneous news
------------------

Yawning Angel released [26] a new set of experimental Tor Browser builds
containing the proposed obfs4 pluggable transport, along with a
changelog; “questions, comments, feedback” are welcome on the email
thread or the bug ticket tracking the deployment of obfs4 [27].

 [26]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007420.html
 [27]: https://bugs.torproject.org/12130

Arturo Filastò announced [28] the release of version 1.1.0 of
oonibackend, the tool “used by ooniprobe to discover the addresses of
test helpers (via the bouncer) to submit reports to (via the collector)
and to perform some measurements that require a backend system to talk
to (via test helpers)” [29].

 [28]: https://lists.torproject.org/pipermail/tor-dev/2014-September/007450.html
 [29]: https://pypi.python.org/pypi/oonibackend

meejah posted [30] a list of tasks to be completed in order to bring Tor
Weather to a deployable state, following the recent rewrite effort and
the Google Summer of Code project by Sreenatha Bhatlapenumarthi.

 [30]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007426.html

Israel Leiva submitted a summary [31] of work completed as part of the
“Revamp GetTor” Google Summer of Code project: “The plan for now is to
keep doing tests and deploy it asap (hopefully during September).”

 [31]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007427.html

Mike Perry posted [32] an updated version [33] of the proposal for
website fingerprinting countermeasures which he co-authored with Marc
Juarez as part of the latter’s Google Summer of Code project.

 [32]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007417.html
 [33]: https://gitweb.torproject.org/user/mikeperry/torspec.git/blob/refs/heads/multihop-padding-primitives:/proposals/ideas/xxx-multihop-padding-primitives.txt

Lunar gave a talk [34] at this year’s DebConf on the effort to build
Debian packages deterministically, which is inspired in large part by
Tor Browser’s use of the same technology [35]. Major progress was
achieved during the conference [36].

 [34]: http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/Reproducible_Builds_for_Debian_a_year_later.webm
 [35]: https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise
 [36]: http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20140901/000198.html

David Fifield submitted a breakdown [37] of the costs incurred by the
infrastructure that supports the meek pluggable transport [38] since its
introduction. The total to date from both the Google App Engine and
Amazon AWS front domains? $6.56.

 [37]: https://lists.torproject.org/pipermail/tor-dev/2014-August/007429.html
 [38]: https://trac.torproject.org/projects/tor/wiki/doc/meek

Thanks to P D [39] and Daniel Pajonzeck [40] for running mirrors of the
Tor Project website and software!

 [39]: https://lists.torproject.org/pipermail/tor-mirrors/2014-August/000653.html
 [40]: https://lists.torproject.org/pipermail/tor-mirrors/2014-August/000673.html

Also on the subject of mirrors, Roger Dingledine alerted [41] the
tor-mirrors mailing list to the fact that the Tor Project website
(specifically the distribution directory) will shortly be increasing in
size to eight or nine gigabytes, as a result of the
soon-to-be-implemented Tor Browser updater [42]. Mirror operators will
need to ensure that they can provide enough disk space to accommodate
the change.

 [41]: https://lists.torproject.org/pipermail/tor-mirrors/2014-September/000675.html
 [42]: https://bugs.torproject.org/4234

whonixqubes announced [43] the release of an integrated version of the
Whonix and Qubes operating systems: “I look forward to helping make
Qubes + Whonix integration even tighter and more seamless throughout the
future.”

 [43]: https://lists.torproject.org/pipermail/tor-talk/2014-August/034562.html

Tor help desk roundup
---------------------

The help desk has been asked if Tor can make a website visit appear to
come from China. Tor connections appear to originate from the country
where the exit relay in use is located; since Tor is blocked in China,
there are zero exit relays in China. A visualization of the different
country-locations of exit relays can be found on Tor’s metrics
page [44].

 [44]: https://metrics.torproject.org/bubbles.html#country-exits-only 

News from Tor StackExchange
---------------------------

Anony Mouse wanted to know why Facebook shows the location of the user’s
last login over Tor as Baghdad or Dhaka [45], instead of the real
location of the exit relay. qbi posted a screenshot showing this
issue [46]. According to Facebook, this information is based on an
approximation, but this approximation locates all Tor exit relays 
either in Baghdad or in Dhaka.

 [45]: https://tor.stackexchange.com/q/3364/88
 [46]: https://twitter.com/qbi/status/506550322308055040

user3500 wants to contribute to Tor and asks how this can be done as an
inexperienced developer [47]. Jens Kubieziel replied with several
possibilities, including reading the volunteer page and Tor Weekly News:
in particular, the section containing easy development tasks might be a
good start. Roya pointed out that any contribution is better than no
contribution, and encouraged user3500 to just get started. Umut Seven
recommended writing unit tests.

 [47]: https://tor.stackexchange.com/q/3961/88

Kras wants to use FoxyProxy in connection with Tor Browser Bundle and
asks if it is safe to do so [48]. At the moment, there is only an answer
saying “yes”, without any explanation. What is your experience? Is it
safe for a user to install and use FoxyProxy?

 [48]: https://tor.stackexchange.com/q/3239/88

Upcoming events
---------------

  Sep 03 13:30 UTC | little-t tor development meeting
                   | #tor-dev, irc.oftc.net
                   |
  Sep 03 19:00 UTC | Tails contributors meeting
                   | #tails-dev, irc.indymedia.org / h7gf2ha3hefoj5ls.onion
                   | https://mailman.boum.org/pipermail/tails-project/2014-August/000016.html
                   |
  Sep 05 15:00 UTC | OONI development meeting
                   | #ooni, irc.oftc.net
                   | https://lists.torproject.org/pipermail/ooni-dev/2014-August/000151.html
                   |
  Sep 08 18:00 UTC | Tor Browser online meeting
                   | #tor-dev, irc.oftc.net
                   |
  Sep 12 19:00 UTC | Tails low hanging fruit session
                   | #tails-dev, irc.indymedia.org / h7gf2ha3hefoj5ls.onion
                   | https://mailman.boum.org/pipermail/tails-project/2014-August/000024.html


This issue of Tor Weekly News has been assembled by harmony, Matt Pagan,
Lunar, qbi, and Arlo Breault.

Want to continue reading TWN? Please help us create this newsletter.
We still need more volunteers to watch the Tor community and report
important news. Please see the project page [49], write down your
name and subscribe to the team mailing list [50] if you want to
get involved!

 [49]: https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews
 [50]: https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team
-- 
tor-talk mailing list - tor-talk at lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

----- End forwarded message -----




From zen at freedbms.net  Tue Sep  2 22:15:55 2014
From: zen at freedbms.net (Zenaan Harkness)
Date: Wed, 3 Sep 2014 15:15:55 +1000
Subject: "Fake" Comsec Found Everywhere
In-Reply-To: <E1XOmMN-0000TS-ED@elasmtp-masked.atl.sa.earthlink.net>
References: <E1XOmMN-0000TS-ED@elasmtp-masked.atl.sa.earthlink.net>
Message-ID: <CAOsGNSQRUOuBeX8UTkCogNJOO0s9JoQy1SGQohX4BE+bFoY1uA@mail.gmail.com>

Well said!

And well written.

Thanks,
Zenaan


On 9/2/14, John Young <jya at pipeline.com> wrote:
> Anxiety and fears about loss of privacy through surreptitious
> and ubiquitous technology, with concomintant rise of advocates
> of defenses, parallels the age-old scam of the devil inside
> humans attacking faith in god(s) requiring constant remediation
> by religion, in particular by buying into costly, elaborate edifices,
> ceremonies, couture, sermons, damnations, excommunications,
> informants, behavior police, burning of witches, celebrations
> of saints. Remind of the crypto wars still raging?
>
> Comsec might be seen as a cult of fetishistic technology,
> crypto its sacred text of salvation and protection from
> demons forever being publicized by the preachers of
> how to hide your sins from the sin spies, the main sin
> being apostasy about national security armed to the max
> with weapons of mass punishment of disbelievers of
> of one's own faith against that of competitors, especially
> competitiors setting up subversive storefronts of alternative
> faiths.
>
> Worse of all, the crypto-rebels writing their own code of
> sin and salvation, defying authorities, seducing youngsters,
> leaking secrets of the official corruption, mocking official
> old gods in favor or new ones home-brewed on the
> electronic frontier.
>
> Snake oil is as old as snakes whispering to naked apes
> once happy copulating without devils or gods hurling
> sand into the amply lubricated in and out to make new
> copulants free of imaginary fears and anxieties that
> pleasure is bad, don't seek it without permission,
> don't do it unless paid in advance, don't dream of
> it or the devil wins, don't self-satisfy or narcissism
> destroys. Right here are some helpful aids to control
> your urges by allowing experts to tell you what's right
> and wrong. You will need this protection inside
> and outside, everywhere, all the time. Let us
> pray. Your wallet please.




From eugen at leitl.org  Wed Sep  3 07:45:00 2014
From: eugen at leitl.org (Eugen Leitl)
Date: Wed, 3 Sep 2014 16:45:00 +0200
Subject: [tor-talk] Tor Weekly News =?utf-8?B?4oCU?= =?utf-8?Q?_September?=
 3rd, 2014
Message-ID: <20140903144500.GS13138@leitl.org>

----- Forwarded message from harmony <harmony01 at riseup.net> -----


From eugen at leitl.org  Thu Sep  4 05:45:18 2014
From: eugen at leitl.org (Eugen Leitl)
Date: Thu, 4 Sep 2014 14:45:18 +0200
Subject: [Cryptography] stories from the real life MITM book
Message-ID: <20140904124518.GT13138@leitl.org>

----- Forwarded message from ianG <iang at iang.org> -----


From wilder at trip.sk  Thu Sep  4 07:17:58 2014
From: wilder at trip.sk (Pavol Luptak)
Date: Thu, 4 Sep 2014 16:17:58 +0200
Subject: Paralelni Polis Congress (cryptoanarchist conference) 9-12.10.2014
 in Prague / Central Europe
Message-ID: <20140904141758.GA5384@core.nethemba.com>

Hello,
it would be my pleasure to invite all of you to a unique cryptoanarchist 
conference - Parallel Polis Congress that will take place during 9-12.10.2014 
in Prague / Central Europe.

* Parallel Polis in theory

Parallel Polis is a theoretical concept developed by Czech dissident Vaclav
Benda (1942–1999) during the height of communist domination in Czechoslovakia
in the 1970s. It was translated into English in 1978.
Benda argues that in a repressed state, it is impossible to overturn corrupt
social, economic and political institutions. Such efforts are futile.
Instead, he suggests the creation of new "parallel institutions" that are more
responsible to human needs.

* Parallel Polis in practice

We were impressed by the concept of Vaclav Benda’s Parallel Polis and
Timothy C May’s Crypto Anarchistic Manifesto and Cyphernomicon.

Embracing the current crypto-technologies we have realized a practical
feasibility of these utopian theories and started a unique freedom think tank
focused on the promotion of digital freedom, cryptocurrencies, anonymization
networks and free markets.

For this purpose we decided to rent a big 3-floor house (with almost 1000m2)
in the center of Prague (Holešovice) - one floor dedicated to Bitcoin
coffee-house, hub and hackerspace called Institute of Cryptoanarchy. :)

* Founders of Parallel Polis

Parallel polis is 100% state-free project, based on voluntary contributions 
only of our members and donors.
Founding members are people from Czech contemporary-art group Ztohoven 
(http://ztohoven.com/), see their recent projects Moral Reform (hack of Czech 
Parliament) http://juraj.bednar.sk/blog/2013/01/06/moral-reform-by-ztohoven-an-ultimate-hack/ and Citizen K 
http://artoftheprank.com/2010/06/19/ztohoven-art-collective-launch-citizen-k-identity-swap/
and group of cryptoanarchists from Czech and Slovak hackerspaces.

* When & Where

Parallel Polis Congress takes place in Parallel Polis building 
(Dělnická 43, Prague) during 9-12.10.2014.
If you prefer to take public transport, take the tram number 1, 12, 14, 25, 
53 or 54 to the tram station Dělnická.

* Parallel Polis Congress and why we need you!

Parallel Polis Congress is an opening party of a new era of our freedom. 
If you want to participate on this event as a speaker, please let me know -
if your presentation is interesting, we can cover you all travelling and 
accommodation expenses (including plane tickets from US). 
In the case of interest, also please send me:

+ the name of your presentation
+ a short description of your presentation (you can have a 30-minutes long
presentation with 10 minutes for Q/A or 5-10 minutes lightning talk)
+ your PGP or S/MIME key if you prefer encrypted communication

* Stay in touch

http://www.paralelnipolis.cz
https://www.facebook.com/pages/Paraleln%C3%AD-Polis/690647371027036
https://twitter.com/Paralelni_polis

Thanks a lot and see you in Prague!

Pavol
-- 
______________________________________________________________________________
[Parallel Polis - Bitcoin Coffee House, Hub and Cryptoanarchy hackerspace]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140904/4aa3b02c/attachment.sig>

From coderman at gmail.com  Thu Sep  4 17:57:17 2014
From: coderman at gmail.com (coderman)
Date: Thu, 4 Sep 2014 17:57:17 -0700
Subject: =?UTF-8?B?UmU6IOKAmEZha2XigJkgY2VsbHBob25lIHRvd2VycyBmb3VuZCBpbiBVLlMu?=
In-Reply-To: <54057B5F.2090300@cathalgarvey.me>
References: <1409638191.2386451.162536281.412A63DC@webmail.messagingengine.com>
 <54057B5F.2090300@cathalgarvey.me>
Message-ID: <CAJVRA1Q_Vxx4=efR34=QbxbyCU5sDtA+YvpXhL9AdhKkwZTM=w@mail.gmail.com>

On 9/2/14, Cathal Garvey <cathalgarvey at cathalgarvey.me> wrote:
> ...
> ..based on the word of a company that markets "firewalled baseband
> phones" and cites personal research in undisclosed locations instead of
> releasing actual data.


bit more detail here:
 https://www.sba-research.org/wp-content/uploads/publications/AdrianDabrowski-IMSI-Catcher-Catcher-ACSAC2014-preprint-20140820.pdf

which clarifies that innocuous uses are indeed omitted from what they
consider a "camping catcher".

best regards,




From s at ctrlc.hu  Fri Sep  5 02:28:22 2014
From: s at ctrlc.hu (stef)
Date: Fri, 5 Sep 2014 11:28:22 +0200
Subject: =?utf-8?B?4oCYRmFrZQ==?= =?utf-8?B?4oCZ?= cellphone towers
 found in U.S.
In-Reply-To: <CAJVRA1Q_Vxx4=efR34=QbxbyCU5sDtA+YvpXhL9AdhKkwZTM=w@mail.gmail.com>
References: <1409638191.2386451.162536281.412A63DC@webmail.messagingengine.com>
 <54057B5F.2090300@cathalgarvey.me>
 <CAJVRA1Q_Vxx4=efR34=QbxbyCU5sDtA+YvpXhL9AdhKkwZTM=w@mail.gmail.com>
Message-ID: <20140905092821.GE11848@ctrlc.hu>

On Thu, Sep 04, 2014 at 05:57:17PM -0700, coderman wrote:
> bit more detail here:
>  https://www.sba-research.org/wp-content/uploads/publications/AdrianDabrowski-IMSI-Catcher-Catcher-ACSAC2014-preprint-20140820.pdf

catchercatcher has been presented in 2011:
http://events.ccc.de/congress/2011/Fahrplan/attachments/1994_111217.SRLabs-28C3-Defending_mobile_phones.pdf

-- 
otr fp: https://www.ctrlc.hu/~stef/otr.txt




From gfoster at entersection.org  Fri Sep  5 14:30:54 2014
From: gfoster at entersection.org (Gregory Foster)
Date: Fri, 05 Sep 2014 16:30:54 -0500
Subject: Patents by Harris Corporation
Message-ID: <540A2B8E.6060006@entersection.org>

I have a feeling there are some interesting things amongst these 2,996
patents filed by Harris Corporation, the maker of the Stingray and other
IMSI catchers:
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=0&p=1&f=S&l=50&Query=an%2F%22harris+corporation%22%0D%0A&d=PTXT

For example,

@USPTO (Jul 1) - "#8,768,311 - Intelligent asymmetric service denial
system for mobile cellular devices and associated methods":
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=22&p=1&f=G&l=50&d=PTXT&S1=(%22harris+corporation%22.ASNM.)&OS=an/%22harris+corporation%22&RS=AN/%22harris+corporation%22

> The system and method prevents reception of calls to a mobile cellular device within a relatively small area or zone, with minimal inconvenience to the public by also permitting outgoing transmissions. The mobile cellular device has a wirelessly settable parameter associated therewith enabling establishment of an inbound call. A selective call blocker includes a receiver, a transmitter, and a selective call blocking controller cooperating with the receiver to determine the wirelessly settable parameter. The selective call blocking controller also cooperates with the transmitter to wirelessly change the wirelessly settable parameter to selectively block an inbound call to the mobile cellular device and without defeating the capability of the mobile cellular device to establish an outbound call.

Harris Corporation is a sprawling defense contractor also dabbling in
hydrocarbons, so many of these patents will not be germane for the list.
 Please share what you find that seems relevant to the on-going
conversation re: IMSI catchers...

gf

-- 
Gregory Foster || gfoster at entersection.org
@gregoryfoster <> http://entersection.com/




From moritz at headstrong.de  Sun Sep  7 06:25:57 2014
From: moritz at headstrong.de (Moritz)
Date: Sun, 07 Sep 2014 15:25:57 +0200
Subject: =?windows-1252?Q?=91Fake=92_cellphone_towers_found_i?=
 =?windows-1252?Q?n_U=2ES=2E?=
In-Reply-To: <20140905092821.GE11848@ctrlc.hu>
References: <1409638191.2386451.162536281.412A63DC@webmail.messagingengine.com>
 <54057B5F.2090300@cathalgarvey.me>
 <CAJVRA1Q_Vxx4=efR34=QbxbyCU5sDtA+YvpXhL9AdhKkwZTM=w@mail.gmail.com>
 <20140905092821.GE11848@ctrlc.hu>
Message-ID: <540C5CE5.7050406@headstrong.de>

On 09/05/2014 11:28 AM, stef wrote:
> On Thu, Sep 04, 2014 at 05:57:17PM -0700, coderman wrote:
>> bit more detail here:
>>  https://www.sba-research.org/wp-content/uploads/publications/AdrianDabrowski-IMSI-Catcher-Catcher-ACSAC2014-preprint-20140820.pdf
> 
> catchercatcher has been presented in 2011:
> http://events.ccc.de/congress/2011/Fahrplan/attachments/1994_111217.SRLabs-28C3-Defending_mobile_phones.pdf
> 

SRLabs' works are covered and extended in the new paper by Adrian, a
very good read.

> ..based on the word of a company that markets "firewalled baseband
> phones" and cites personal research in undisclosed locations instead
> of releasing actual data.

I agree. I was asked to review and test a CryptoPhone (and I still use
it daily). The warnings err on the cautious side of things and single
events only rarely/never mean a real attack. Unless we see more data,
this is completely marketing bullshit.

As someone who tries to move forward an Open Source implementation of
something like their (quite limited) Baseband Monitor (misleadingly
called Baseband Firewall), I am pretty annoyed by their patent:
https://patentimages.storage.googleapis.com/pdfs/US20140004829.pdf --
especially given that Frank Rieger, the owner of the patent, is official
speaker for the CCC and should know better.

http://esdamerica.com/ ("Manufacturer of CryptoPhone" - which is
bullshit, since they use unmodified Samsung S3 hardware)

"ESD America’s team maintains operational security and confidentiality
for our clients. Clients include Government, Intelligence, Police,
Military, Narcotics Task Forces and Royalty. Products are centred on
intelligence gathering, surveillance, reconnaissance and encryption as
well as sourcing other specialised products and training."

*shakes head*




From l at odewijk.nl  Sun Sep  7 08:05:34 2014
From: l at odewijk.nl (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?=)
Date: Sun, 7 Sep 2014 17:05:34 +0200
Subject: =?UTF-8?B?UmU6IOKAmEZha2XigJkgY2VsbHBob25lIHRvd2VycyBmb3VuZCBpbiBVLlMu?=
In-Reply-To: <540C5CE5.7050406@headstrong.de>
References: <1409638191.2386451.162536281.412A63DC@webmail.messagingengine.com>
 <54057B5F.2090300@cathalgarvey.me>
 <CAJVRA1Q_Vxx4=efR34=QbxbyCU5sDtA+YvpXhL9AdhKkwZTM=w@mail.gmail.com>
 <20140905092821.GE11848@ctrlc.hu> <540C5CE5.7050406@headstrong.de>
Message-ID: <CAHWD2rJAKNH9MmfMz5q5Vrj2imb+b68mwu=-E_gbUcKTS5NO-Q@mail.gmail.com>

I suggested one of the Bitcoin ATM guys to use two boards. One board is
connected like normally to networks and accessories and the like. That one
board also has a custom connection to the other board. The other board
contains all the secrets and performs all the important functions. The one
board just communicates.

The advantage is that once the big bad guys crack your baseband, your
chipset, your system on a chip's trapcards, etc. your secrets are still
safe. If you sign all the packets that pass through the communication board
you can truly abstract away from almost every possible hack that both the
boards could be vulnerable for. (Do you trust your silicon?)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 734 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140907/6f763c95/attachment.txt>

From hozer at hozed.org  Sun Sep  7 18:22:12 2014
From: hozer at hozed.org (Troy Benjegerdes)
Date: Sun, 7 Sep 2014 20:22:12 -0500
Subject: "Fake" Comsec Found Everywhere
In-Reply-To: <E1XOmMN-0000TS-ED@elasmtp-masked.atl.sa.earthlink.net>
References: <E1XOmMN-0000TS-ED@elasmtp-masked.atl.sa.earthlink.net>
Message-ID: <20140908012212.GA2897@nl.grid.coop>

On Tue, Sep 02, 2014 at 07:35:25AM -0400, John Young wrote:
> Anxiety and fears about loss of privacy through surreptitious
> and ubiquitous technology, with concomintant rise of advocates
> of defenses, parallels the age-old scam of the devil inside
> humans attacking faith in god(s) requiring constant remediation
> by religion, in particular by buying into costly, elaborate edifices,
> ceremonies, couture, sermons, damnations, excommunications,
> informants, behavior police, burning of witches, celebrations
> of saints. Remind of the crypto wars still raging?
> 
> Comsec might be seen as a cult of fetishistic technology,
> crypto its sacred text of salvation and protection from
> demons forever being publicized by the preachers of
> how to hide your sins from the sin spies, the main sin
> being apostasy about national security armed to the max
> with weapons of mass punishment of disbelievers of
> of one's own faith against that of competitors, especially
> competitiors setting up subversive storefronts of alternative
> faiths.
> 
> Worse of all, the crypto-rebels writing their own code of
> sin and salvation, defying authorities, seducing youngsters,
> leaking secrets of the official corruption, mocking official
> old gods in favor or new ones home-brewed on the
> electronic frontier.
> 
> Snake oil is as old as snakes whispering to naked apes
> once happy copulating without devils or gods hurling
> sand into the amply lubricated in and out to make new
> copulants free of imaginary fears and anxieties that
> pleasure is bad, don't seek it without permission,
> don't do it unless paid in advance, don't dream of
> it or the devil wins, don't self-satisfy or narcissism
> destroys. Right here are some helpful aids to control
> your urges by allowing experts to tell you what's right
> and wrong. You will need this protection inside
> and outside, everywhere, all the time. Let us
> pray. Your wallet please.
> 
> 

Amen.

And low, the crypto-wallets did open, and bitcoins
spilled forth like a rain of blood upon the land, and
thus did the believers submit for a base58-encoded
mark of the beast.




From hettinga at gmail.com  Wed Sep 10 03:33:08 2014
From: hettinga at gmail.com (Robert Hettinga)
Date: Wed, 10 Sep 2014 06:33:08 -0400
Subject: Obituary: Hal Finney | The Economist
Message-ID: <1E8E1F04-4ADC-4768-9D9E-09A9EAB6208B@gmail.com>


http://www.economist.com/news/obituary/21615469-harold-finney-futurist-and-cypherpunk-died-august-28th-aged-58-hal-finney

Hal Finney


AS IT turned out, Hal Finney was not Satoshi Nakamoto. But for a short while, at least, some people thought he might be. “Satoshi Nakamoto” is the most famous non-person on the internet. The name is a pseudonym, meant to hide the shadowy programmer (or programmers) behind Bitcoin, a computerised currency designed to liberate money from the control of any central bank. Speculating about his true identity is a popular pastime in some of the more esoteric corners of the web.

Still, Mr Finney was a good guess. As a cryptographer and a programmer he had the skills, for Bitcoin relies on cryptography to function. Having been an early adopter (he was, with the fabled Mr Nakamoto, a partner in the world’s first ever Bitcoin transaction) he certainly had the pedigree. And he had the beliefs, too. He was one of the original “cypherpunks”, a small, influential band of cryptographers, philosophers and programmers who, in the early 1990s, helped stamp the early internet with its culture of rebelliousness, distrust of government and optimistic belief in the liberating power of technology.

Two decades before Edward Snowden put the subject on front pages the world over, the cypherpunks were discussing how the coming age of the internet would allow governments and companies to pry ever more deeply and easily into the lives of their citizens and customers. But that same computer revolution would also hand ordinary people the power to fight back against the organisations that presumed to run their lives. Until that point, good quality encryption had been something available only to spy agencies and big companies. Computers would give people the power to carve out a mathematically guaranteed refuge from the powers that be, and to have a conversation that was provably, reliably private.

For Mr Finney, who had spent his high-school years imbibing the supercharged libertarianism of Ayn Rand, and who was now earning a living writing video games, that was a heady challenge. He accepted it with gusto. “Here we are faced with the problems of loss of privacy, creeping computerisation, massive databases, more centralisation,” he wrote. “[But] the computer can be used as a tool to liberate and protect people, rather than to control them.” His aim was clear: “The work we are doing here, broadly speaking, is dedicated to this goal of making Big Brother obsolete.”

He began helping, unpaid, with a program called Pretty Good Privacy (PGP), putting in enough hours that it became a second job. It was well-named: even today, messages scrambled with it are thought to be unbreakable (Mr Snowden used PGP for his e-mail exchanges with the journalists to whom he leaked his documents). In 1991 Phil Zimmermann, PGP’s chief developer, uploaded it to the internet. America’s spies were aghast. Exporting encryption—which was classed as a weapon—was illegal. And here a group of self-proclaimed techno-liberators were proposing to just hand it over to anyone in the world—diplomat, criminal, teenager—who wanted it. When the legal kerfuffle died down, Mr Zimmermann hired Mr Finney as his new company’s second-ever employee.

Suspended animation

For a long time he ran a free “remailer”, a server designed to forward e-mail anonymously, no questions asked, to anyone in the world. Whose business was it, after all, what people wanted to send to each other, except the sender and the recipient? His interests extended beyond privacy. He was fascinated by the sorts of futures that technology might unlock, speculating about everything from how morals evolve in rich societies to when clean energy might finally displace fossil fuels. Away from the screen, he was chatty and gregarious, a keen skier and runner.

He had to stop in 2009, when he was diagnosed with motor neurone disease (MND). The illness gradually paralyses its victims, but, with characteristic logic, Mr Finney pointed out that it was not a death sentence—even when those muscles necessary for breathing gave out, life could carry on with the aid of a mechanical ventilator. He was surprised, he said, to discover that most people with the disease “chose” death instead. After all, MND robs sufferers only of their bodies, not their minds, and for him it was the mind that mattered. His interests went beyond computers and coding, to sociology, psychology and how technology might improve society. As long as there was a way to communicate with the outside world—even if it was only by having a computer interpret the twitchings of a facial muscle—he wanted to endure.

When even that became difficult, he put a final plan into action. In accordance with his wishes, he was disconnected from his ventilator. As soon as he had been declared legally dead, technicians from a firm called Alcor froze his body in liquid nitrogen. He became one of a few hundred people who have elected to have their bodies stored until medicine advances to the point where it can safely revive them and cure their original ailments. It sounds (and is) science-fictional, and Mr Finney was under no illusions about the prospects of waking up again. But placing his faith in a technology that has yet to be invented was a rational gamble for a committed techno-optimist. And besides, a slim hope is better than none at all.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140910/210c29b6/attachment.sig>

From gfoster at entersection.org  Thu Sep 11 07:03:47 2014
From: gfoster at entersection.org (Gregory Foster)
Date: Thu, 11 Sep 2014 09:03:47 -0500
Subject: DOE quantum encryption & Google quantum computation research
Message-ID: <5411ABC3.1000107@entersection.org>

GCN (Sep 10) - "DOE, Google [independently] back quantum computing
research":
http://gcn.com/blogs/pulse/2014/09/doe-google-quantum.aspx

> The Department of Energy is investing in a project to speed the development of unhackable quantum encryption technology that will protect the country's power grid from cyberattack.
>
> Under the DOE's Cybersecurity for Energy Delivery Systems program, the nation's top program for grid security, San Diego startup Qubitekk was awarded $3 million to work in partnership with Oak Ridge National Laboratory, Pacific Northwest National Laboratory, the University of Texas at Austin, Sandia National Laboratory and Pacific Gas & Electric to develop practical quantum security for the nation’s power grid.
>
> Qubitekk, founded in 2012 to commercialize technology required to speed the adoption of quantum computing, recently announced the availability of the world's first plug-and-play entangled photon generator, the QES1. Like the transistors at the hearts of classical computers, the QES1 enables the flow of information through quantum computers and quantum encryption products – both of which the company is currently developing.
>
> Meanwhile, Google is planning to build its own quantum computer. The Quantum Artificial Intelligence team at Google is launching a hardware initiative to design and build new quantum information processors based on superconducting electronics, according to a Google+ post by the lab team. Google also announced that John Martinis and his team at UC Santa Barbara will join Google in the initiative.
>
> Google has been working with D-Wave Systems, maker of the quantum computer being tested by the Quantum Artificial Intelligence Lab at NASA’s Ames Research Center. Martinis will try to make his own versions of the kind of chip inside a D-Wave machine.
>
> The Google Quantum AI team will test “new designs for quantum optimization and inference processors based on recent theoretical insights as well as our learnings from the D-Wave quantum annealing architecture,” Google said. The company will continue to work with D-Wave scientists and to experiment with the 512-qubit “Vesuvius” machine at NASA Ames that will be upgraded to a 1000 qubit “Washington” processor.

gf

-- 
Gregory Foster || gfoster at entersection.org
@gregoryfoster <> http://entersection.com/




From coderman at gmail.com  Mon Sep 15 00:21:43 2014
From: coderman at gmail.com (coderman)
Date: Mon, 15 Sep 2014 00:21:43 -0700
Subject: SpyFiles 4
Message-ID: <CAJVRA1TH6tMRfvo9cUgw6k-m5CES=c-58ASjkyOirtgSNfKPDA@mail.gmail.com>

"Today, 15 September 2014, WikiLeaks releases previously unseen copies
of weaponised German surveillance malware used by intelligence
agencies around the world to spy on journalists, political dissidents
and others."
 - https://wikileaks.org/spyfiles4/index.html

get it while it's hot!




From coderman at gmail.com  Mon Sep 15 01:02:37 2014
From: coderman at gmail.com (coderman)
Date: Mon, 15 Sep 2014 01:02:37 -0700
Subject: RC4 is dangerous in ways not yet known - heads up on near injection
 WPA2 downgrade to TKIP RC4
Message-ID: <CAJVRA1Sxg_VJ1JO2G0+fKBfcEdMEJULsrp7-Q_OcmVFHEwza0Q@mail.gmail.com>

first and foremost:
WPA2 does NOT prevent an adversary able to inject packets at you from
downgrading crypto to flawed RC4. due to odd forgotten legacy protocol
bits, every implementation of WPA2 that i have tested is vulnerable to
an active downgrade to TKIP/RC4 while still being "WPA2" and still
showing all signs of using strongest security settings.

let me re-iterate: _WPA2 only_ as a setting on router or client device
does not prevent an active RC4 downgrade when using WPA2. AES-CCMP
must be explicitly checked for, and this is not straightforward in
end-user configuration or management utilities.

RECOMMENDATION: use a wireless packet capture utility to specifically
check for and alert on the presence of TKIP in a WPA2 session. this
never happens under legitimate circumstances. [if you know of one,
please tell me!]

TKIP in WPA2 == Active injection attack by "well funded" adversary[0]

---

i missed the renewed speculation that periodically swirls around RC4, e.g.

"I feel but cannot prove that the day is coming when we learn that
everything we ever encrypted with RC4 is very practical to decrypt"
 - https://twitter.com/marshray/status/505586082461655040

"Kind of annoyed SHA-1 is a "crypto emergency" when most of the web
was encrypted with RC4 last year and almost no one cared"
 - https://twitter.com/bascule/status/509239990216163330

"This attack also applies directly to WPA/TKIP, with similar success
rates, because of its use of per-packet keys for RC4. Here, the
particular structure of WPA/TKIP keys means that a different set of
biases are obtained in the first 256 bytes of RC4 keystream... For
WPA/TKIP, the only reasonable countermeasure is to upgrade to WPA2."
 - http://www.isg.rhul.ac.uk/tls/

---

i have an advisory pending to full-disclosure with details on this
WPA2 force downgrade to TKIP attack and a rant about Kaminsky's DEF
CON 22 talk. advisory includes timeline indicating "in the wild"
discovery of this technique late 2013.  any earlier indications
welcome!

to be clear, this issue is with backwards compatibility in WPA2, and
the manner in which a local attacker (8 miles or more with power and
directional emission) can force the WPA2 protected session to use
TKIP/RC4 while appearing to both client and network management
equipment to be using WPA2 and best security configuration. (not WEP,
not WPA)

this is not about how RC4 is broken; i have no idea about the nature
of the RC4 weaknesses enabling decryption, and this as yet unknown
attack is certainly more effective than the attack described in
CVE-2013-2566:
"The attacks can only be carried out by a determined attacker who can
generate sufficient sessions for the attacks. They recover a limited
amount of plaintext. In this sense, the attacks do not pose a
significant danger to ordinary users of TLS or WPA/TKIP in their
current form. However, it is a truism that attacks only get better
with time, and we anticipate significant further improvements to our
attacks."

the attacks observed in the wild did not rely on any additional or
excessive packet creation to reach effectiveness.

best regards,



0. About TKIP with WPA2...
some tools know that TKIP is backwards compatible in WPA2, having
written to spec. E.g. airodump-ng: "Not mandatory, but TKIP is
typically used with WPA and CCMP is typically used with WPA2."

in my testing i have never seen a device that could do WPA2 but not
AES-CCMP. if you find one i'd like to know about it!  if you ever see
a device+router pair that used to speak AES-CCMP over WPA2 suddenly
using TKIP you are under active attack.

finally, i mention "advanced attacker" because utilizing this
downgrade also means applying an as yet unknown attack on the RC4
cipher to decrypt.




From coderman at gmail.com  Mon Sep 15 01:55:55 2014
From: coderman at gmail.com (coderman)
Date: Mon, 15 Sep 2014 01:55:55 -0700
Subject: Fwd: RFC 7359 on Layer 3 Virtual Private Network (VPN) Tunnel Traffic
 Leakages in Dual-Stack Hosts/Networks
In-Reply-To: <53FD5C3F.5090603@si6networks.com>
References: <20140827012300.9D31218047F@rfc-editor.org>
 <53FD5C3F.5090603@si6networks.com>
Message-ID: <CAJVRA1Qq9P8DbY6q1HVb_qd8xJaB0ROpDcxRyWUJ7+E1D=z-Cw@mail.gmail.com>

direct draft at: https://www.rfc-editor.org/rfc/rfc7359.txt

-------- Forwarded Message --------
Subject: RFC 7359 on Layer 3 Virtual Private Network (VPN) Tunnel
Traffic Leakages in Dual-Stack Hosts/Networks
Date: Tue, 26 Aug 2014 18:23:00 -0700 (PDT)
From: rfc-editor at rfc-editor.org
Reply-To: ietf at ietf.org
To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org
CC: drafts-update-ref at iana.org, rfc-editor at rfc-editor.org

A new Request for Comments is now available in online RFC libraries.


        RFC 7359

        Title:      Layer 3 Virtual Private Network
                    (VPN) Tunnel Traffic Leakages in Dual-Stack
                    Hosts/Networks
        Author:     F. Gont
        Status:     Informational
        Stream:     IETF
        Date:       August 2014
        Mailbox:    fgont at si6networks.com
        Pages:      12
        Characters: 26506
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-opsec-vpn-leakages-06.txt

        URL:        https://www.rfc-editor.org/rfc/rfc7359.txt

The subtle way in which the IPv6 and IPv4 protocols coexist in
typical networks, together with the lack of proper IPv6 support in
popular Virtual Private Network (VPN) tunnel products, may
inadvertently result in VPN tunnel traffic leakages.  That is,
traffic meant to be transferred over an encrypted and integrity-
protected VPN tunnel may leak out of such a tunnel and be sent in the
clear on the local network towards the final destination.  This
document discusses some scenarios in which such VPN tunnel traffic
leakages may occur as a result of employing IPv6-unaware VPN
software.  Additionally, this document offers possible mitigations
for this issue.

This document is a product of the Operational Security Capabilities for
IP Network Infrastructure Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor at rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC




-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From coderman at gmail.com  Mon Sep 15 02:39:15 2014
From: coderman at gmail.com (coderman)
Date: Mon, 15 Sep 2014 02:39:15 -0700
Subject: RC4 is dangerous in ways not yet known - heads up on near
 injection WPA2 downgrade to TKIP RC4
In-Reply-To: <CAJVRA1Sxg_VJ1JO2G0+fKBfcEdMEJULsrp7-Q_OcmVFHEwza0Q@mail.gmail.com>
References: <CAJVRA1Sxg_VJ1JO2G0+fKBfcEdMEJULsrp7-Q_OcmVFHEwza0Q@mail.gmail.com>
Message-ID: <CAJVRA1Tu7r+o6S=uk0g63ChDUYpW7H66A3RrAx4bdhHG53WGhA@mail.gmail.com>

On 9/15/14, coderman <coderman at gmail.com> wrote:
> ... every implementation of WPA2 that i have tested is vulnerable to
> an active downgrade to TKIP/RC4 while still being "WPA2" and still
> showing all signs of using strongest security settings.

yes, this attack does require knowing the WPA passphrase (PSK) and no
i have not looked at WPA-Enterprise mode (EAP-*).

yes, just looking for populated michael MIC authenticator fields is
probably sufficient to alarm if you've configured WPA2 only.

yes, this is all for now. :)


best regards,




From coderman at gmail.com  Mon Sep 15 03:23:08 2014
From: coderman at gmail.com (coderman)
Date: Mon, 15 Sep 2014 03:23:08 -0700
Subject: RC4 is dangerous in ways not yet known - heads up on near
 injection WPA2 downgrade to TKIP RC4
In-Reply-To: <CAJVRA1Tu7r+o6S=uk0g63ChDUYpW7H66A3RrAx4bdhHG53WGhA@mail.gmail.com>
References: <CAJVRA1Sxg_VJ1JO2G0+fKBfcEdMEJULsrp7-Q_OcmVFHEwza0Q@mail.gmail.com>
 <CAJVRA1Tu7r+o6S=uk0g63ChDUYpW7H66A3RrAx4bdhHG53WGhA@mail.gmail.com>
Message-ID: <CAJVRA1S2hTR7nvqSiyzkAEKzQm2jSkr=sLo4K37m+C0YTK_cmQ@mail.gmail.com>

On 9/15/14, coderman <coderman at gmail.com> wrote:
>...
> yes, this is all for now. :)

i lied and one last clarification before day is done:

why do you care if this assumes knowledge of the pairwise master key?
a) my poc sucks; make a better one able to manipulate EAPOL frames without PMK!
b) presumably still useful if client SNonce is missed (easier to hear
loud access points than quiet clients behind more obstacles?)

switch to WPA2-EAP-PWD, WPA2-EAP-TTLSv0|v1, WPA2-EAP-PEAP, anything
other than PSK... i can't say for sure that WPA-Enterprise is immune
to this attack, but it is certainly better in many respects
regardless.




From coderman at gmail.com  Mon Sep 15 06:46:03 2014
From: coderman at gmail.com (coderman)
Date: Mon, 15 Sep 2014 06:46:03 -0700
Subject: About STELLARWIND and other mysterious classification markings
Message-ID: <CAJVRA1T_u6XjndvEfA8QX9EgFNWvwJ_BBcHz1bckOp4+BB4+=w@mail.gmail.com>

http://electrospaces.blogspot.nl/2014/09/about-stellarwind-and-another.html

[ ... a good read; go do so now! ]

for the TL;DR crowd:
"""
In the end, it doesn't make much difference whether STELLARWIND is a
control system on its own, or a sub-system of COMINT, but it is
remarkable that for such an important program, the people involved
apparently also weren't clear about it's exact status and how to put
it in the right place of a classification line.

More important though is that the declassified documents show that
besides the STELLARWIND program, there's at least one
COMINT-compartment with at least one sub-compartment that protect
similar or related NSA collection efforts which are considered even
more sensitive, but about which we can only speculate.
"""




From eugen at leitl.org  Tue Sep 16 04:18:48 2014
From: eugen at leitl.org (Eugen Leitl)
Date: Tue, 16 Sep 2014 13:18:48 +0200
Subject: Assange AMA on Reddit
Message-ID: <20140916111848.GE10467@leitl.org>


https://www.reddit.com/r/technology/comments/2ghp54/i_am_julian_assange_ama_about_my_new_book_when/




From coderman at gmail.com  Tue Sep 16 14:55:51 2014
From: coderman at gmail.com (coderman)
Date: Tue, 16 Sep 2014 14:55:51 -0700
Subject: Fwd: [liberationtech] proof of tampering
In-Reply-To: <CAJVRA1TciAmB1Ai4b7Xxb3L9JZ63QQs1E-CWHD4CGOq=uq8J8Q@mail.gmail.com>
References: <1410884139.25950.YahooMailNeo@web162606.mail.bf1.yahoo.com>
 <CAJVRA1TciAmB1Ai4b7Xxb3L9JZ63QQs1E-CWHD4CGOq=uq8J8Q@mail.gmail.com>
Message-ID: <CAJVRA1TXADdPrZhQBtb1H7R_ycNA7wOyT3i9MA6N0KJjSPM9ow@mail.gmail.com>

---------- Forwarded message ----------
From: coderman <coderman at gmail.com>
Date: Tue, 16 Sep 2014 14:26:50 -0700
Subject: Re: [liberationtech] proof of tampering

On 9/16/14, Jonathan Wilkes <> wrote:
> ... over a year after the initial Snowden-leak stories-- I'm curious if
> anyone has references to articles or papers that have researched and
> reproduced any of these exploits to show how they are used in practice to
> steal data, surveil, etc.

it is very difficult finding detailed, public research into this
particular type of offensive reversing. public knowledge is
constrained by:

- lack of access. see list history regarding ability to even
detect/observe the most advanced attacks.  this is changing, however.
c.f.: exposure of corporate level, middle school type contract kit:
https://wikileaks.org/spyfiles4/ and the work of Morgan Marquis-Boire.
The Stuxnet/Flame/Guass/Duqu/Skywiper/Mahdi analysis are still the
only views of TAO/NSAlike campaigns. corrections welcome ;)

- lack of skills+/-experience spanning domains required to dissect the
attack across its many pivoting boundaries of enabling and transiting
through hardware, devices, networks, and systems under attack. [a
redditor could do a shiny graph showing how nearly every technologist
with the expertise for world class malware analysis ends up under
secret contract, private contract, or does something else outside of
university, to varying proportions of each.]

- lack of interest or time; the small subset left in consideration is
only human, and a thorough reverse analysis of complex stealthy code
eats your life in quarter or full years chunks. a passion for the
subject only carriers so far...



finally, to underscore the point as is so conveniently at fingertip,
your mail immediately went to the spam trap, having violated who knows
what in googbrain to indicate forgery or malicious intent.

why aggressively stamp down a narrative when you can slowly bleed it
into silent not-existing instead?



good luck, and best regards,




From coderman at gmail.com  Tue Sep 16 15:19:55 2014
From: coderman at gmail.com (coderman)
Date: Tue, 16 Sep 2014 15:19:55 -0700
Subject: Giganews Is an FBI operation - Giganews Denial Campaign Overdrive
In-Reply-To: <CAJVRA1Qc=GunK66R-yh6VKG6L1H=UdK4+Rw8SDJhVBJ=3-aG=g@mail.gmail.com>
References: <CAJVRA1Qc=GunK66R-yh6VKG6L1H=UdK4+Rw8SDJhVBJ=3-aG=g@mail.gmail.com>
Message-ID: <CAJVRA1TUTZvPshvR-X_3Z3OccKjVA_YMnzjKHDwfL4T5dsEeAQ@mail.gmail.com>

i thought the TAO catalog would be most volatile, but maybe Giganews
Golden Frog debacle will take it...

cryptome must be a hot seat!  cool jya's buns with some bitcoin...
 [ http://cryptome.org/donations.htm ]

:P

best regards,

---

http://cryptome.org/2014/09/giganews-denial.htm

16 September 2014

Giganews Denial Campaign

Orchestrated PR against every leaker is to demonize: call the leaker a
sad case who needs psychiatric help, whose life style is scrutinized
for damning behavior aided by fabricated ruses and testimonies against
the leaker.

Officials, CEOs, lawyers, co-workers are set in motion to slur,
ridicule, laugh at, scowl at, condemn, smear, pity and rage against
the leaker. Retractions and redactions are demanded to protect he
innocent. But never admit the truth of the leaks until after more
leaks, then grudingly, with shallow apologies, layer by layer as the
leaking continues.

Attacks are initiated on the leaker's outlets and supporters, accusing
them of being duped and hoaxed, demand that they too recant and admit
being taken in by a crafty operator who did not understand the full
picture, and was not a reliable worker.

This is the pattern of cover-up, and it is widespread among
malefactors working the same territory of duping the public on behalf
of the government, usually after themselves being entrapped by
officials and extorted into becoming informers and co-conspirators
with officials. And if all goes well handsome contracts are used to
cement the malefaction as a part of successful business of betrayal.

This is what Nick Caputo revealed of Giganews, this is what Giganews
must deny as formulaicly denied by Stratfor, by HG Gary, by Sabu, by
Google, by Microsoft, by NSA, by DoJ, by FBI, on and on.

---

http://cryptome.org/2014/09/giganews-fbi.htm

 15 September 2014

Giganews Is an FBI operation

Cryptome,

Let me explain my history at Giganews in Austin, Texas and how I
learned about the FBI connection. I used to be a huge fan of Usenet
and a customer of different newsgroup providers for several years, and
I started working at Giganews in 2009. I rose through the company,
being promoted to a system technician after 6 months, and became a
Giganews system engineer less than two years after that.

A huge pirate at the time, I loved the idea of helping people download
all the "rich multimedia content" they could. The porn content is not
safe on Usenet, and the groups with children being abused I find
abhorrent. Customers would write in about it all the time, so its no
secret to a Usenet employee where it is.

Data Foundry is a data center company which is interconnected to
Giganews with the same admins, nocs, etc. Their main office
headquarters is at 1044 Liberty Park Dr in Austin. But, they host most
of the Usenet content in other data centers around the world. While
talking to the CEO of the entire operation, Ron Yokubaitis, I heard
what I interpreted as his request to remove the child pornography
groups when he asked, "Would you delete child porn?" I honestly loved
the thought of removing that junk off of Usenet, and removed three cp
newsgroups soon afterwards. This happened December 11th, 2011. I
didn't remove anything related to the normal and more socially
acceptable content Usenet downloaders know about.

It turned out that that wasn't what the CEO really wanted, who then
claimed he forgot what he said. The Giganews/Data Foundry admins
Philip Molter and Mike Smith disciplined me for removing the child
porn groups and didn't trust me to keep working there afterwards. They
made subtle references to jeopardizing criminal investigations IN
PROGRESS then threatened me with a bad reference for removing the
child abuse junk. No big deal, a bad reference from them after doing
that is good, but Philip restored the cp content from a backup I
didn't have access to.

Fast forward several months, I turned into a traitor in an effort to
remove the abhorrent junk off Usenet - I broke the first and second
rules not to talk about it, and told the FBI the truth about the child
abuse groups deletion in an email. This probably wont go over well
with internet freedom lovers, but sharing what I learned in the
experience will, I promise. My seemingly traitorous act exposed the
real traitor, the biggest one, to the Usenet network.

The FBI invited me to their unlisted Austin office in a nondescript
office building at 12515 Research Blvd, Building 7, Suite 400 in late
October 2012. Two agents took notes on what I told them, then
something unexpected happened. Special Agent Scott Kibbey told me he
personally knew the Giganews / Data Foundry CEO, bragged to me about
working there, then invited me back to Giganews! I had also helped
them with a separate crime venue in Austin that Data Foundry was going
to compete with, so I had earned their trust. In addition, Kibbey
offered me a new name and identity, with a new drivers license and
everything, if I were to go back to work at Giganews.

It was then that I realized that the fed I was talking to had been my
coworker at Giganews since I started in 2009! The other agent was
actually an Austin police detective named Charles Riley helping the
FBI whom worked alternate shifts to me at the Datafoundry NOC under
alias. Riley even bragged about being a detective once at a shift
change! The thought of my fellow Usenet systech in crime being a
police detective was unthinkable at the time. I've included some of
the emails from these feds (with email headers and IP addresses) in
the link at end.

Special Agent Scott Kibbey is central to the whole Giganews operation,
including Data Foundry, but with different names. This agent is a top
exec for Data Foundry, a top admin for Giganews, the Golden Frog front
company run from the same Usenet servers for VyprVPN, and the other
Usenet fronts Usenet.net, Supernews, Rhino Newsgroups, and
Powerusenet. Another business front name they used when I was there is
Powerhouse Management. Kibbey rolled out the OS images, kernels,
patches, setup the entire VyprVPN service including the detailed
logging which is easily accessible to him and the other government
agents working there.

There were also rumors agents from other governments worked there The
Hong Kong Giganews servers were brought down in early June 2009 by a
Chinese employee, the day of the Tiananmen Square anniversary when the
Chinese government was blocking everything online. This means the
VyprVPN connecting IP addresses are accessible to the Chinese
government indirectly through this employee. Anyone using the VyprVPN
service that governments are targeting is in danger, honestly.

This is my warning - that all of the content being downloaded and
shared on the Usenet network is going through the authorities!
Giganews customers are being logged! The log file is called the
"gigauth" on their "cruncher" servers which logs every connection by
every customer, which are then archived. This means Usenet uploaders
are helping the feds monitor the distribution of Usenet content if
their newsgroup provider peers with Giganews!

I swear to you that Giganews is an operation that employs federal
agents who run most of the operation. I suggest demanding from your
newsgroup provider that they stop the peering of binary groups to
FBI's Giganews. Please understand how risky this is for me to explain
as Agent Kibbey subtly threatened my family on behalf of Data Foundry
the second time I met both agents at the Austin FBI office. The
traitors saw me as a threat and said I did not cooperate. Even with
this threat, please warn Giganews customers and other Usenet users,
and use the evidence I've linked. If the google drive link dies, email
me for a new one. Agents Kibbey and Riley did not let me photograph
them, but I did include a scan of their business cards. Riley didn't
have an FBI badge or card, but he had an fbi.gov email address, ip,
and Austin Police Department badge.

I've linked pictures of my Giganews badge and the shirts with their
red armor logo I was forced to wear when working there. I've also
linked to the Giganews/Data Foundry employee list with in-office mug
shots, phone numbers and emails they gave me. I did not agree to
return this on their employee paperwork, so it is not illegal to
share. They thought I did, though. I doubt the names and phone numbers
they used internally are all real, as many are likely aliases and
fed-routed voip proxies. Most of the emails changed to goldenfrog.com
before I left from the ones listed in the 2011 employee pdf. Some of
the mugshots are photoshopped by them, as the pictures did not match
the physical appearance of some, likely to hide in case of someone
like me exposing these traitors.

Feel free to upload this to any newsgroup that Giganews carries -
Their customers need to know.

-Nick Caputo




From grarpamp at gmail.com  Tue Sep 16 12:41:23 2014
From: grarpamp at gmail.com (grarpamp)
Date: Tue, 16 Sep 2014 15:41:23 -0400
Subject: Assange AMA on Reddit
In-Reply-To: <20140916111848.GE10467@leitl.org>
References: <20140916111848.GE10467@leitl.org>
Message-ID: <CAD2Ti28_RjSCvee6imtkFARK3uhO=HsJsgVnbMsytBmf0mVckg@mail.gmail.com>

On Tue, Sep 16, 2014 at 7:18 AM, Eugen Leitl <eugen at leitl.org> wrote:
> https://www.reddit.com/r/technology/comments/2ghp54/i_am_julian_assange_ama_about_my_new_book_when/

https://www.reddit.com/r/IAmA/comments/28js8v/i_am_julian_assange_publisher_of_wikileaks_ask_me/




From grarpamp at gmail.com  Tue Sep 16 13:54:22 2014
From: grarpamp at gmail.com (grarpamp)
Date: Tue, 16 Sep 2014 16:54:22 -0400
Subject: Apple Tim Cook re NSA etc on Charlie Rose
Message-ID: <CAD2Ti28DHTPKcK7n3Z-Tfn35xy7UP5n3Q_9j7pVnQQTJ4p0X8w@mail.gmail.com>

http://www.zdnet.com/apple-ceo-tim-cook-on-snowden-surveillance-sweatshops-and-the-threats-to-the-planet-7000033704/
http://www.zdnet.com/apple-ceo-tim-cook-on-secret-products-steve-jobs-ibm-deal-google-rivalry-and-the-screw-ups-7000033626/
http://charlierose.com/




From coderman at gmail.com  Tue Sep 16 17:58:44 2014
From: coderman at gmail.com (coderman)
Date: Tue, 16 Sep 2014 17:58:44 -0700
Subject: Unraveling NSA's TURBULENCE Programs
Message-ID: <CAJVRA1RNzOu_JDfoqBcSDUQ9R24h6MfOkWVUfztRZWNVe_bLJA@mail.gmail.com>

https://robert.sesek.com/2014/9/unraveling_nsa_s_turbulence_programs.html
'''
The NSA TURBULENCE program was first revealed in 2007 by the Baltimore
Sun for being over-budget and poorly-managed. Many documents from the
Snowden trove from the past two years reference parts of this program,
but no coherent story or overview of how these programs operate
together has been described. This is an attempt to do so, using leaked
and declassified documents...
'''




From juan.g71 at gmail.com  Tue Sep 16 17:55:45 2014
From: juan.g71 at gmail.com (Juan)
Date: Tue, 16 Sep 2014 21:55:45 -0300
Subject: Apple Tim Cook re NSA etc on Charlie Rose
In-Reply-To: <CAD2Ti28DHTPKcK7n3Z-Tfn35xy7UP5n3Q_9j7pVnQQTJ4p0X8w@mail.gmail.com>
References: <CAD2Ti28DHTPKcK7n3Z-Tfn35xy7UP5n3Q_9j7pVnQQTJ4p0X8w@mail.gmail.com>
Message-ID: <5418dc1d.c978e00a.7d75.ffffd843@mx.google.com>

On Tue, 16 Sep 2014 16:54:22 -0400
grarpamp <grarpamp at gmail.com> wrote:

> http://www.zdnet.com/apple-ceo-tim-cook-on-snowden-surveillance-sweatshops-and-the-threats-to-the-planet-7000033704/
> http://www.zdnet.com/apple-ceo-tim-cook-on-secret-products-steve-jobs-ibm-deal-google-rivalry-and-the-screw-ups-7000033626/
> http://charlierose.com/


	So, the guy is nothing but a lying sack of shit.

	Anything else? 






From jwcase at gmail.com  Wed Sep 17 07:49:26 2014
From: jwcase at gmail.com (Joshua Case)
Date: Wed, 17 Sep 2014 10:49:26 -0400
Subject: Giganews Is an FBI operation - Giganews Denial Campaign Overdrive
In-Reply-To: <CAJVRA1TUTZvPshvR-X_3Z3OccKjVA_YMnzjKHDwfL4T5dsEeAQ@mail.gmail.com>
References: <CAJVRA1Qc=GunK66R-yh6VKG6L1H=UdK4+Rw8SDJhVBJ=3-aG=g@mail.gmail.com>
 <CAJVRA1TUTZvPshvR-X_3Z3OccKjVA_YMnzjKHDwfL4T5dsEeAQ@mail.gmail.com>
Message-ID: <50AFD3EA-ECC9-40BD-BD8F-85CB944C776B@gmail.com>

hmmm…. https://www.linkedin.com/in/nickcaputo 


On Sep 16, 2014, at 6:19 PM, coderman <coderman at gmail.com> wrote:

> i thought the TAO catalog would be most volatile, but maybe Giganews
> Golden Frog debacle will take it...
> 
> cryptome must be a hot seat!  cool jya's buns with some bitcoin...
> [ http://cryptome.org/donations.htm ]
> 
> :P
> 
> best regards,
> 
> ---
> 
> http://cryptome.org/2014/09/giganews-denial.htm
> 
> 16 September 2014
> 
> Giganews Denial Campaign
> 
> Orchestrated PR against every leaker is to demonize: call the leaker a
> sad case who needs psychiatric help, whose life style is scrutinized
> for damning behavior aided by fabricated ruses and testimonies against
> the leaker.
> 
> Officials, CEOs, lawyers, co-workers are set in motion to slur,
> ridicule, laugh at, scowl at, condemn, smear, pity and rage against
> the leaker. Retractions and redactions are demanded to protect he
> innocent. But never admit the truth of the leaks until after more
> leaks, then grudingly, with shallow apologies, layer by layer as the
> leaking continues.
> 
> Attacks are initiated on the leaker's outlets and supporters, accusing
> them of being duped and hoaxed, demand that they too recant and admit
> being taken in by a crafty operator who did not understand the full
> picture, and was not a reliable worker.
> 
> This is the pattern of cover-up, and it is widespread among
> malefactors working the same territory of duping the public on behalf
> of the government, usually after themselves being entrapped by
> officials and extorted into becoming informers and co-conspirators
> with officials. And if all goes well handsome contracts are used to
> cement the malefaction as a part of successful business of betrayal.
> 
> This is what Nick Caputo revealed of Giganews, this is what Giganews
> must deny as formulaicly denied by Stratfor, by HG Gary, by Sabu, by
> Google, by Microsoft, by NSA, by DoJ, by FBI, on and on.
> 
> ---
> 
> http://cryptome.org/2014/09/giganews-fbi.htm
> 
> 15 September 2014
> 
> Giganews Is an FBI operation
> 
> Cryptome,
> 
> Let me explain my history at Giganews in Austin, Texas and how I
> learned about the FBI connection. I used to be a huge fan of Usenet
> and a customer of different newsgroup providers for several years, and
> I started working at Giganews in 2009. I rose through the company,
> being promoted to a system technician after 6 months, and became a
> Giganews system engineer less than two years after that.
> 
> A huge pirate at the time, I loved the idea of helping people download
> all the "rich multimedia content" they could. The porn content is not
> safe on Usenet, and the groups with children being abused I find
> abhorrent. Customers would write in about it all the time, so its no
> secret to a Usenet employee where it is.
> 
> Data Foundry is a data center company which is interconnected to
> Giganews with the same admins, nocs, etc. Their main office
> headquarters is at 1044 Liberty Park Dr in Austin. But, they host most
> of the Usenet content in other data centers around the world. While
> talking to the CEO of the entire operation, Ron Yokubaitis, I heard
> what I interpreted as his request to remove the child pornography
> groups when he asked, "Would you delete child porn?" I honestly loved
> the thought of removing that junk off of Usenet, and removed three cp
> newsgroups soon afterwards. This happened December 11th, 2011. I
> didn't remove anything related to the normal and more socially
> acceptable content Usenet downloaders know about.
> 
> It turned out that that wasn't what the CEO really wanted, who then
> claimed he forgot what he said. The Giganews/Data Foundry admins
> Philip Molter and Mike Smith disciplined me for removing the child
> porn groups and didn't trust me to keep working there afterwards. They
> made subtle references to jeopardizing criminal investigations IN
> PROGRESS then threatened me with a bad reference for removing the
> child abuse junk. No big deal, a bad reference from them after doing
> that is good, but Philip restored the cp content from a backup I
> didn't have access to.
> 
> Fast forward several months, I turned into a traitor in an effort to
> remove the abhorrent junk off Usenet - I broke the first and second
> rules not to talk about it, and told the FBI the truth about the child
> abuse groups deletion in an email. This probably wont go over well
> with internet freedom lovers, but sharing what I learned in the
> experience will, I promise. My seemingly traitorous act exposed the
> real traitor, the biggest one, to the Usenet network.
> 
> The FBI invited me to their unlisted Austin office in a nondescript
> office building at 12515 Research Blvd, Building 7, Suite 400 in late
> October 2012. Two agents took notes on what I told them, then
> something unexpected happened. Special Agent Scott Kibbey told me he
> personally knew the Giganews / Data Foundry CEO, bragged to me about
> working there, then invited me back to Giganews! I had also helped
> them with a separate crime venue in Austin that Data Foundry was going
> to compete with, so I had earned their trust. In addition, Kibbey
> offered me a new name and identity, with a new drivers license and
> everything, if I were to go back to work at Giganews.
> 
> It was then that I realized that the fed I was talking to had been my
> coworker at Giganews since I started in 2009! The other agent was
> actually an Austin police detective named Charles Riley helping the
> FBI whom worked alternate shifts to me at the Datafoundry NOC under
> alias. Riley even bragged about being a detective once at a shift
> change! The thought of my fellow Usenet systech in crime being a
> police detective was unthinkable at the time. I've included some of
> the emails from these feds (with email headers and IP addresses) in
> the link at end.
> 
> Special Agent Scott Kibbey is central to the whole Giganews operation,
> including Data Foundry, but with different names. This agent is a top
> exec for Data Foundry, a top admin for Giganews, the Golden Frog front
> company run from the same Usenet servers for VyprVPN, and the other
> Usenet fronts Usenet.net, Supernews, Rhino Newsgroups, and
> Powerusenet. Another business front name they used when I was there is
> Powerhouse Management. Kibbey rolled out the OS images, kernels,
> patches, setup the entire VyprVPN service including the detailed
> logging which is easily accessible to him and the other government
> agents working there.
> 
> There were also rumors agents from other governments worked there The
> Hong Kong Giganews servers were brought down in early June 2009 by a
> Chinese employee, the day of the Tiananmen Square anniversary when the
> Chinese government was blocking everything online. This means the
> VyprVPN connecting IP addresses are accessible to the Chinese
> government indirectly through this employee. Anyone using the VyprVPN
> service that governments are targeting is in danger, honestly.
> 
> This is my warning - that all of the content being downloaded and
> shared on the Usenet network is going through the authorities!
> Giganews customers are being logged! The log file is called the
> "gigauth" on their "cruncher" servers which logs every connection by
> every customer, which are then archived. This means Usenet uploaders
> are helping the feds monitor the distribution of Usenet content if
> their newsgroup provider peers with Giganews!
> 
> I swear to you that Giganews is an operation that employs federal
> agents who run most of the operation. I suggest demanding from your
> newsgroup provider that they stop the peering of binary groups to
> FBI's Giganews. Please understand how risky this is for me to explain
> as Agent Kibbey subtly threatened my family on behalf of Data Foundry
> the second time I met both agents at the Austin FBI office. The
> traitors saw me as a threat and said I did not cooperate. Even with
> this threat, please warn Giganews customers and other Usenet users,
> and use the evidence I've linked. If the google drive link dies, email
> me for a new one. Agents Kibbey and Riley did not let me photograph
> them, but I did include a scan of their business cards. Riley didn't
> have an FBI badge or card, but he had an fbi.gov email address, ip,
> and Austin Police Department badge.
> 
> I've linked pictures of my Giganews badge and the shirts with their
> red armor logo I was forced to wear when working there. I've also
> linked to the Giganews/Data Foundry employee list with in-office mug
> shots, phone numbers and emails they gave me. I did not agree to
> return this on their employee paperwork, so it is not illegal to
> share. They thought I did, though. I doubt the names and phone numbers
> they used internally are all real, as many are likely aliases and
> fed-routed voip proxies. Most of the emails changed to goldenfrog.com
> before I left from the ones listed in the 2011 employee pdf. Some of
> the mugshots are photoshopped by them, as the pictures did not match
> the physical appearance of some, likely to hide in case of someone
> like me exposing these traitors.
> 
> Feel free to upload this to any newsgroup that Giganews carries -
> Their customers need to know.
> 
> -Nick Caputo
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 10040 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140917/dd4ac9e7/attachment.txt>

From eugen at leitl.org  Wed Sep 17 02:33:42 2014
From: eugen at leitl.org (Eugen Leitl)
Date: Wed, 17 Sep 2014 11:33:42 +0200
Subject: PFS is a global, versioned, peer-to-peer filesystem
Message-ID: <20140917093342.GG10467@leitl.org>


http://ipfs.io/

IPFS is a global, versioned, peer-to-peer filesystem.

It combines good ideas from Git, BitTorrent, Kademlia, SFS, and the Web. It
is like a single bittorrent swarm, exchanging git objects. IPFS provides an
interface as simple as the HTTP web, but with permanence built in. You can
also mount the world at /ipfs.

How does it work? Read the paper http://static.benet.ai/t/ipfs.pdf




From grarpamp at gmail.com  Wed Sep 17 14:14:11 2014
From: grarpamp at gmail.com (grarpamp)
Date: Wed, 17 Sep 2014 17:14:11 -0400
Subject: [cryptography] Email encryption for the wider public
In-Reply-To: <CABU-GB37qpwUuTtK15VmykzuR4_-AVQvSFUYXO=W8VC3J2hEFA@mail.gmail.com>
References: <CABU-GB37qpwUuTtK15VmykzuR4_-AVQvSFUYXO=W8VC3J2hEFA@mail.gmail.com>
Message-ID: <CAD2Ti29NreOO75KPNE3a5P6Fg-A7+O1H4NLRRQM4t7_QAwebaA@mail.gmail.com>

On Wed, Sep 17, 2014 at 9:43 AM, Henry Augustus Chamberlain
<henryaugustuschamberlain at gmail.com> wrote:
> I propose that we use the local part of the email address to store the public key,
> ...
> my email address would be (64 random letters)@gmail.com
> ...
> Somebody not using encrypted emails could still click on your "mailto"
> link and send you an email, although it will be unencrypted

Putting keys into some_encoding at example.com might cover
some bases related to offline key lookup and message validation.
Most user and system mail tools would need changes to handle
string width and keytype, addressbooks updated, etc. Totally burying
OpenPGP, passphrase and key lookup/use behind a fully integrated
MUA GUI for grandma would work just as similarly well right now today
with no such encoding.

But in the end, all you're doing is covering the message body, and in today's
world that's clearly not enough. No one's yet solving the huge issues
with leaving mail exposed to what is essentially open-for-all-to-inspect central
storage and mail routing. The "who's IP talking to who", "From To Subject,
daemon headers, etc" metadata, when, how much/often, provider logs, someone
sending you unencrypted mail, you giving up your private keys to the
provider or running blobs they provide to you, etc. This is all unfixable with
traditional "Email" models.

This is why that to really solve anything more than the message body,
you need to go completely nextgen and turn that 'email address' into
an anonymous P2P overlay network node address, run your overlay
client [which supplies a mail/messaging front end] and send/receive
mail through that from/to your usual MTA/MUA/messaging toolchain.

The real work there is in pushing the P2P node count up...
- Research how many users globally might leave their messaging
node up 24x7 for a direct realtime overlay connection with the far
end "user at node"... 1/10/100/n*1000 million?
- Develop message storage [and forward/poll/expiry] within the
overlay for those that aren't in online mode.
- Determine any hardware limitations and thin client models.

There is an ongoing thread with the subject
 "The next gen P2P secure email solution"
that contains various people's initial thoughts/framework on this.




From grarpamp at gmail.com  Wed Sep 17 15:08:43 2014
From: grarpamp at gmail.com (grarpamp)
Date: Wed, 17 Sep 2014 18:08:43 -0400
Subject: [tor-talk] wake up tor devs
In-Reply-To: <156b8eed2e9dc784c15c238afc028330.squirrel@bitmailendavkbec.onion>
References: <156b8eed2e9dc784c15c238afc028330.squirrel@bitmailendavkbec.onion>
Message-ID: <CAD2Ti29evbkQ5vRJxkEbx=L+hKypUsVdZY7aFuCkktXU=xMpsA@mail.gmail.com>

On Wed, Sep 17, 2014 at 5:04 PM,
<BM-2cUqBqHFVDHuY34ZcpL3PNgkpLUEEer8ev at bitmessage.ch> wrote:
> Why is Tor wasting time in implementing secure hidden services? Why not
> copy from here if they are doing it right:
>
> Tor     I2P
> Cell    Message
> Circuit Tunnel
> ...
>
> Why not distributed directory authorities and hardcoded?
> Why not secure tunnels independent of guards?
> Or does Tor want to remain less secure?

Yes, there should be more comparative analysis
of approaches amongst all the current networks. Create
a dedicated group that publishes such things on a darknet wiki.
Hold not just project specific meetups as is done today, but
genuine summits amongst all such projects that puts
their specific projects aside and determines what models
might best suit the next 10-20 years. Determine whether the
community is too chained by legacy project/product entrenchment
to adopt new better approaches that have come up in research
since they themselves started their own projects. Find
any worthy new techniques and peel off interested developers
into new projects. Try to ensure that big well known
projects aren't soaking up all the fanfare/funds when
equally valid small projects, or new projects would benefit
the world the same or more than the gorilla in the room.

For example, there seems some merit in filling your
internode links with chaff padding up to the bandwidth
limit you configure in order to mask both when and
how much you are communicating.
But it does not seem any project is doing that?
Perhaps because chaff transmission/management/security
models are not well developed. Or just the 'woah, bandwidth'
reaction, which in reality of the simplest design only
affects you and what bw you were willing to purchase
or experience anyway (as when operating under a
non-chaff network with a given/high utilisation condition).

Another example... there was, or is, at least one group
accepting funds and then running some of the various
overlays equally at once... tor, i2p, freenet, cjdns, mailmix.

Take some time to step back and see what together you
can do with the big picture in all areas... research, development,
operations, marketing.




From coderman at gmail.com  Wed Sep 17 19:31:18 2014
From: coderman at gmail.com (coderman)
Date: Wed, 17 Sep 2014 19:31:18 -0700
Subject: killing RC4 in Chrome
Message-ID: <CAJVRA1SCWZmtz7EWMoyOoDM7NDBxFakxDa0gDPrKy6PnT_zZ3A@mail.gmail.com>

https://twitter.com/grittygrease/status/512328703938797568

<grittygrease> Are you planning on dropping RC4 support in Chrome anytime soon?

<sleevi_> Not until I can work with @mikewest to get our mixed content
detection improved and get @__apf__ on board for more sec-ui :)




From s at ctrlc.hu  Thu Sep 18 01:57:56 2014
From: s at ctrlc.hu (stef)
Date: Thu, 18 Sep 2014 10:57:56 +0200
Subject: [cryptography] Email encryption for the wider public
In-Reply-To: <CABU-GB2xq75NjaqV-XD25VQq8cBaQZ_cYcO9fx5NrSzM+eV6ig@mail.gmail.com>
References: <CABU-GB37qpwUuTtK15VmykzuR4_-AVQvSFUYXO=W8VC3J2hEFA@mail.gmail.com>
 <CAD2Ti29NreOO75KPNE3a5P6Fg-A7+O1H4NLRRQM4t7_QAwebaA@mail.gmail.com>
 <CABU-GB2xq75NjaqV-XD25VQq8cBaQZ_cYcO9fx5NrSzM+eV6ig@mail.gmail.com>
Message-ID: <20140918085756.GW11848@ctrlc.hu>

On Thu, Sep 18, 2014 at 09:06:53AM +0200, Henry Augustus Chamberlain wrote:
> currently able to use email encryption at all! I think both concerns
> are fair, and both are worth trying to solve.

let me summarize (and ask you to reread and understand) grapamps response to
you: email is dead.

-- 
otr fp: https://www.ctrlc.hu/~stef/otr.txt




From tedks at riseup.net  Thu Sep 18 08:10:55 2014
From: tedks at riseup.net (Ted Smith)
Date: Thu, 18 Sep 2014 11:10:55 -0400
Subject: killing RC4 in Chrome
In-Reply-To: <541AB34F.7080908@cathalgarvey.me>
References: <CAJVRA1SCWZmtz7EWMoyOoDM7NDBxFakxDa0gDPrKy6PnT_zZ3A@mail.gmail.com>
 <541AB34F.7080908@cathalgarvey.me>
Message-ID: <1411053055.21331.17.camel@anglachel>

There's sort of a chicken/egg problem here. 

You can actually just disable them in configuration; in Firefox, you can
just go to about:config and set all the security.*.rc4* to false instead
of true. 

However, this breaks a *lot* of sites, including some big ones. 

On Thu, 2014-09-18 at 11:26 +0100, Cathal Garvey wrote:
> This is what occurred to me when I saw your first few mails on this
> subject; how hard is it to just comment out the stupid algos in the
> source for FF/Chrome, and just recompile? TLS negotiates available
> algos, so there's probably a list somewhere of which algos to send to
> the server; you could change nothing but that list and the algos would
> simply never be advertised, negotiated, or used?
> 
> On 18/09/14 03:31, coderman wrote:
> > https://twitter.com/grittygrease/status/512328703938797568
> > 
> > <grittygrease> Are you planning on dropping RC4 support in Chrome anytime soon?
> > 
> > <sleevi_> Not until I can work with @mikewest to get our mixed content
> > detection improved and get @__apf__ on board for more sec-ui :)
> > 
> 

-- 
Sent from Ubuntu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140918/b45a0f76/attachment.sig>

From s at ctrlc.hu  Thu Sep 18 02:16:28 2014
From: s at ctrlc.hu (stef)
Date: Thu, 18 Sep 2014 11:16:28 +0200
Subject: [cryptography] Email encryption for the wider public
In-Reply-To: <CA+hr98FxVibKxdw6-3rYOtzt8qDWLeLo=yY8czgc0nt02bpj4Q@mail.gmail.com>
References: <CABU-GB37qpwUuTtK15VmykzuR4_-AVQvSFUYXO=W8VC3J2hEFA@mail.gmail.com>
 <CAD2Ti29NreOO75KPNE3a5P6Fg-A7+O1H4NLRRQM4t7_QAwebaA@mail.gmail.com>
 <CABU-GB2xq75NjaqV-XD25VQq8cBaQZ_cYcO9fx5NrSzM+eV6ig@mail.gmail.com>
 <20140918085756.GW11848@ctrlc.hu>
 <CA+hr98FxVibKxdw6-3rYOtzt8qDWLeLo=yY8czgc0nt02bpj4Q@mail.gmail.com>
Message-ID: <20140918091628.GX11848@ctrlc.hu>

On Thu, Sep 18, 2014 at 11:13:04AM +0200, Krisztián Pintér wrote:
> On Thu, Sep 18, 2014 at 10:57 AM, stef <s at ctrlc.hu> wrote:
> > let me summarize (and ask you to reread and understand) grapamps response to
> > you: email is dead.
> 
> email is not dead, it is a zombie that walks around for at least 20
> years.

i like your analogy :)

is there a non-zero probability that zombie analogies are the opposite to car
analogies?

-- 
otr fp: https://www.ctrlc.hu/~stef/otr.txt




From cathalgarvey at cathalgarvey.me  Thu Sep 18 03:26:23 2014
From: cathalgarvey at cathalgarvey.me (Cathal Garvey)
Date: Thu, 18 Sep 2014 11:26:23 +0100
Subject: killing RC4 in Chrome
In-Reply-To: <CAJVRA1SCWZmtz7EWMoyOoDM7NDBxFakxDa0gDPrKy6PnT_zZ3A@mail.gmail.com>
References: <CAJVRA1SCWZmtz7EWMoyOoDM7NDBxFakxDa0gDPrKy6PnT_zZ3A@mail.gmail.com>
Message-ID: <541AB34F.7080908@cathalgarvey.me>

This is what occurred to me when I saw your first few mails on this
subject; how hard is it to just comment out the stupid algos in the
source for FF/Chrome, and just recompile? TLS negotiates available
algos, so there's probably a list somewhere of which algos to send to
the server; you could change nothing but that list and the algos would
simply never be advertised, negotiated, or used?

On 18/09/14 03:31, coderman wrote:
> https://twitter.com/grittygrease/status/512328703938797568
> 
> <grittygrease> Are you planning on dropping RC4 support in Chrome anytime soon?
> 
> <sleevi_> Not until I can work with @mikewest to get our mixed content
> detection improved and get @__apf__ on board for more sec-ui :)
> 

-- 
Twitter: @onetruecathal, @formabiolabs
Phone: +353876363185
Blog: http://indiebiotech.com
miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x988B9099.asc
Type: application/pgp-keys
Size: 6176 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140918/d4077fa8/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140918/d4077fa8/attachment.sig>

From rysiek at hackerspace.pl  Thu Sep 18 03:01:39 2014
From: rysiek at hackerspace.pl (rysiek)
Date: Thu, 18 Sep 2014 12:01:39 +0200
Subject: [cryptography] Email encryption for the wider public
In-Reply-To: <20140918091628.GX11848@ctrlc.hu>
References: <CABU-GB37qpwUuTtK15VmykzuR4_-AVQvSFUYXO=W8VC3J2hEFA@mail.gmail.com>
 <CA+hr98FxVibKxdw6-3rYOtzt8qDWLeLo=yY8czgc0nt02bpj4Q@mail.gmail.com>
 <20140918091628.GX11848@ctrlc.hu>
Message-ID: <1729038.kT0ZbTlzUU@lapuntu>

Dnia czwartek, 18 września 2014 11:16:28 stef pisze:
> On Thu, Sep 18, 2014 at 11:13:04AM +0200, Krisztián Pintér wrote:
> > On Thu, Sep 18, 2014 at 10:57 AM, stef <s at ctrlc.hu> wrote:
> > > let me summarize (and ask you to reread and understand) grapamps
> > > response to you: email is dead.
> > 
> > email is not dead, it is a zombie that walks around for at least 20
> > years.
> 
> i like your analogy :)
> 
> is there a non-zero probability that zombie analogies are the opposite to
> car analogies?

Did you just implicitly make a car analogy about zombie analogies?..

-- 
Pozdr
rysiek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 411 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140918/c06d755a/attachment.sig>

From s at ctrlc.hu  Thu Sep 18 03:27:30 2014
From: s at ctrlc.hu (stef)
Date: Thu, 18 Sep 2014 12:27:30 +0200
Subject: [cryptography] Email encryption for the wider public
In-Reply-To: <1729038.kT0ZbTlzUU@lapuntu>
References: <CABU-GB37qpwUuTtK15VmykzuR4_-AVQvSFUYXO=W8VC3J2hEFA@mail.gmail.com>
 <CA+hr98FxVibKxdw6-3rYOtzt8qDWLeLo=yY8czgc0nt02bpj4Q@mail.gmail.com>
 <20140918091628.GX11848@ctrlc.hu> <1729038.kT0ZbTlzUU@lapuntu>
Message-ID: <20140918102730.GZ11848@ctrlc.hu>

On Thu, Sep 18, 2014 at 12:01:39PM +0200, rysiek wrote:
> > is there a non-zero probability that zombie analogies are the opposite to
> > car analogies?
> 
> Did you just implicitly make a car analogy about zombie analogies?..

i very carefully postulated a theory, that's semantically quite far from
analogies i believe - nice try though :P

-- 
otr fp: https://www.ctrlc.hu/~stef/otr.txt




From adi at hexapodia.org  Thu Sep 18 13:49:26 2014
From: adi at hexapodia.org (Andy Isaacson)
Date: Thu, 18 Sep 2014 13:49:26 -0700
Subject: killing RC4 in Chrome
In-Reply-To: <1411071413.21331.20.camel@anglachel>
References: <CAJVRA1SCWZmtz7EWMoyOoDM7NDBxFakxDa0gDPrKy6PnT_zZ3A@mail.gmail.com>
 <541AB34F.7080908@cathalgarvey.me>
 <1411053055.21331.17.camel@anglachel> <3763193.Z2n6Afzyi6@lapuntu>
 <1411071413.21331.20.camel@anglachel>
Message-ID: <20140918204926.GH12685@hexapodia.org>

On Thu, Sep 18, 2014 at 04:16:53PM -0400, Ted Smith wrote:
> On Thu, 2014-09-18 at 20:29 +0200, rysiek wrote:
> > Dnia czwartek, 18 września 2014 11:10:55 Ted Smith pisze:
> > > There's sort of a chicken/egg problem here.
> > > 
> > > You can actually just disable them in configuration; in Firefox, you can
> > > just go to about:config and set all the security.*.rc4* to false instead
> > > of true.
> > > 
> > > However, this breaks a *lot* of sites, including some big ones.
> > 
> > Time for a little name and shame?
> 
> This was a while ago and I've forgotten, though it was enough to be
> annoying. 
> 
> It'd be pretty easy to write a script that harvested the allowed
> ciphersuites from the top Alexa sites, if you were really interested.
> The EFF's HTTPS Observatory might also have this information.

Plenty of sites switched *to* RC4 during the BEAST attack mitigation.
Some may not have switched back.

-andy




From cathalgarvey at cathalgarvey.me  Thu Sep 18 06:08:14 2014
From: cathalgarvey at cathalgarvey.me (Cathal Garvey)
Date: Thu, 18 Sep 2014 14:08:14 +0100
Subject: Bittorrent Bleep
In-Reply-To: <CAEm6KbLXhFyCW_rkD9Lh0z-x7LS-ezd8+vx308GqZK7qocGcYQ@mail.gmail.com>
References: <CAEm6KbLXhFyCW_rkD9Lh0z-x7LS-ezd8+vx308GqZK7qocGcYQ@mail.gmail.com>
Message-ID: <541AD93E.3050102@cathalgarvey.me>

A warning, here. When BT released Sync but no source or protocol, I was
pretty incensed and decided I'd try to hack up an open Python client
that would be intercompatible. I went in armed with their fragmentary
and sometimes contradictory marketing nonsense (was it AES 128 or AES
256?), PyCrypto, and WireShark.

I never did decrypt any stuff to get their encryption protocol worked
out, so I don't have a protocol to share. I abandoned this long before
succeeding in decryption because of one critical detail I discovered,
which undermined *any* interest I had in an intercompatible app. It
became clear at this instant that the people at Bittorrent, fond as they
are of secret-sauce closed-source "encryption", hadn't a clue.

So, they were using AES256, as it turned out! Using the base32 encoded
form of a private key. So, while they were advertising 256 bits, in
actuality they had much less entropy in the key they were using than
that. I gave up; what else can be hiding in there if they didn't grasp
the basic concept of key entropy?

So now they're into P2P VoiP, and my response is DO NOT WANT. Bittorrent
Inc. have no cultural knowledge of the value of openness in software
design, especially in security or encryption, and based on my own
personal experience this leads to stupid design decisions that will
directly endanger the privacy and security of their users.

On 18/09/14 13:22,  Александр  wrote:
> http://blog.bittorrent.com/2014/09/17/bittorrent-bleep-alpha-goes-public-introduces-mac-and-android-apps/
> 

-- 
Twitter: @onetruecathal, @formabiolabs
Phone: +353876363185
Blog: http://indiebiotech.com
miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x988B9099.asc
Type: application/pgp-keys
Size: 6176 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140918/4935a96d/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140918/4935a96d/attachment.sig>

From afalex169 at gmail.com  Thu Sep 18 05:22:01 2014
From: afalex169 at gmail.com (=?UTF-8?B?INCQ0LvQtdC60YHQsNC90LTRgCA=?=)
Date: Thu, 18 Sep 2014 15:22:01 +0300
Subject: Bittorrent Bleep
Message-ID: <CAEm6KbLXhFyCW_rkD9Lh0z-x7LS-ezd8+vx308GqZK7qocGcYQ@mail.gmail.com>

http://blog.bittorrent.com/2014/09/17/bittorrent-bleep-alpha-goes-public-introduces-mac-and-android-apps/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 505 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140918/b8a22108/attachment.txt>

From x50 at fastmail.fm  Thu Sep 18 13:01:07 2014
From: x50 at fastmail.fm (x50 at fastmail.fm)
Date: Thu, 18 Sep 2014 16:01:07 -0400
Subject: More on the tor scam
In-Reply-To: <541b2c35.0614e00a.1bdf.ffffd6d3@mx.google.com>
References: <541b2c35.0614e00a.1bdf.ffffd6d3@mx.google.com>
Message-ID: <1411070467.330795.169160477.074F1647@webmail.messagingengine.com>

I'd recommend the blog post about this, if you haven't seen it already: 

https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack

It should answer some of your questions. I have only seen speculation on
why the talk was cancelled.




From juan.g71 at gmail.com  Thu Sep 18 12:02:09 2014
From: juan.g71 at gmail.com (Juan)
Date: Thu, 18 Sep 2014 16:02:09 -0300
Subject: More on the tor scam
Message-ID: <541b2c35.0614e00a.1bdf.ffffd6d3@mx.google.com>



So, whatever happened to this?


"Black Hat Cancels Presentation on Cracking Tor" 
http://www.pcmag.com/article2/0,2817,2461204,00.asp


http://freedomhacker.net/tor-project-fixing-vulnerability-that-could-expose-users/


Why was the talk cancelled? Did that happen in the Western Cesspool
where 'freedom of speech'  is oh so fucking sacred? 

And what about this 'vulnerability'? Isn't tor oh so amaazing that even
the NSA can't track tor users...except that's a stupid lie? 








From rysiek at hackerspace.pl  Thu Sep 18 07:04:23 2014
From: rysiek at hackerspace.pl (rysiek)
Date: Thu, 18 Sep 2014 16:04:23 +0200
Subject: Bittorrent Bleep
In-Reply-To: <541AD93E.3050102@cathalgarvey.me>
References: <CAEm6KbLXhFyCW_rkD9Lh0z-x7LS-ezd8+vx308GqZK7qocGcYQ@mail.gmail.com>
 <541AD93E.3050102@cathalgarvey.me>
Message-ID: <1540782.RqkvIqGjLI@lapuntu>

Dnia czwartek, 18 września 2014 14:08:14 Cathal Garvey pisze:
> A warning, here. When BT released Sync but no source or protocol, I was
> pretty incensed and decided I'd try to hack up an open Python client
> that would be intercompatible. I went in armed with their fragmentary
> and sometimes contradictory marketing nonsense (was it AES 128 or AES
> 256?), PyCrypto, and WireShark.
> 
> I never did decrypt any stuff to get their encryption protocol worked
> out, so I don't have a protocol to share. I abandoned this long before
> succeeding in decryption because of one critical detail I discovered,
> which undermined *any* interest I had in an intercompatible app. It
> became clear at this instant that the people at Bittorrent, fond as they
> are of secret-sauce closed-source "encryption", hadn't a clue.
> 
> So, they were using AES256, as it turned out! Using the base32 encoded
> form of a private key. So, while they were advertising 256 bits, in
> actuality they had much less entropy in the key they were using than
> that. I gave up; what else can be hiding in there if they didn't grasp
> the basic concept of key entropy?
> 
> So now they're into P2P VoiP, and my response is DO NOT WANT. Bittorrent
> Inc. have no cultural knowledge of the value of openness in software
> design, especially in security or encryption, and based on my own
> personal experience this leads to stupid design decisions that will
> directly endanger the privacy and security of their users.

Thank you for this, this is highly relevant to my Internets.

-- 
Pozdr
rysiek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 411 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140918/5564516a/attachment.sig>

From tedks at riseup.net  Thu Sep 18 13:16:53 2014
From: tedks at riseup.net (Ted Smith)
Date: Thu, 18 Sep 2014 16:16:53 -0400
Subject: killing RC4 in Chrome
In-Reply-To: <3763193.Z2n6Afzyi6@lapuntu>
References: <CAJVRA1SCWZmtz7EWMoyOoDM7NDBxFakxDa0gDPrKy6PnT_zZ3A@mail.gmail.com>
 <541AB34F.7080908@cathalgarvey.me> <1411053055.21331.17.camel@anglachel>
 <3763193.Z2n6Afzyi6@lapuntu>
Message-ID: <1411071413.21331.20.camel@anglachel>

On Thu, 2014-09-18 at 20:29 +0200, rysiek wrote:
> Dnia czwartek, 18 września 2014 11:10:55 Ted Smith pisze:
> > There's sort of a chicken/egg problem here.
> > 
> > You can actually just disable them in configuration; in Firefox, you can
> > just go to about:config and set all the security.*.rc4* to false instead
> > of true.
> > 
> > However, this breaks a *lot* of sites, including some big ones.
> 
> Time for a little name and shame?
> 

This was a while ago and I've forgotten, though it was enough to be
annoying. 

It'd be pretty easy to write a script that harvested the allowed
ciphersuites from the top Alexa sites, if you were really interested.
The EFF's HTTPS Observatory might also have this information.

-- 
Sent from Ubuntu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140918/605369bf/attachment.sig>

From rdohm321 at gmail.com  Thu Sep 18 08:30:50 2014
From: rdohm321 at gmail.com (Randolph)
Date: Thu, 18 Sep 2014 16:30:50 +0100
Subject: Bittorrent Bleep
In-Reply-To: <CAEm6KbLXhFyCW_rkD9Lh0z-x7LS-ezd8+vx308GqZK7qocGcYQ@mail.gmail.com>
References: <CAEm6KbLXhFyCW_rkD9Lh0z-x7LS-ezd8+vx308GqZK7qocGcYQ@mail.gmail.com>
Message-ID: <CAEvNM8moMO51Z_pTG4pDwzZoAsvuC-KhaKBTMwRuwxFXVY+FiQ@mail.gmail.com>

Bleep is not open source
The DHT is hammering the mobiel battery, it can be more regarded as a
tool to support the DHT, because torrent users are going down.
So encryption is not their goal, but keeping the userbase.
The mobile menu has a quite good process to decide each step, if you
want to provide email or phone number or not.
In case you do, you send all your ID credentials to a central server,
as well not open source.
THEN, the mobile does not allow to copy any key out, only a QR code in
case two persons are present to each other, but you cannot e-mail your
online-ID-Key to another participant, so you are very fast back at the
method to provide them your phone number and email address.
They want to map you. The encryption is totally unknown. It works like
unencrypted. Do they use authentication? do they have a Mac? how long
is the hash? do they use a salt? can the Chat be end-to-end encrypted
by a smmetric key?
Totally useless if not open source and hammering the battery. Why is
there no mobile version of the encrypted http://firefloo.sf.net ??

2014-09-18 14:22 GMT+02:00 Александр <afalex169 at gmail.com>:
> http://blog.bittorrent.com/2014/09/17/bittorrent-bleep-alpha-goes-public-introduces-mac-and-android-apps/




From apexcp at gmail.com  Thu Sep 18 13:37:01 2014
From: apexcp at gmail.com (Patrick)
Date: Thu, 18 Sep 2014 16:37:01 -0400
Subject: More on the tor scam
In-Reply-To: <1411070467.330795.169160477.074F1647@webmail.messagingengine.com>
References: <541b2c35.0614e00a.1bdf.ffffd6d3@mx.google.com>
 <1411070467.330795.169160477.074F1647@webmail.messagingengine.com>
Message-ID: <CAOHwwFLQS4kYT4GVZcy=K3LXk2eU2coU6cDfzW__dsbc9-49Gg@mail.gmail.com>

Does anyone have ideas about who would be the right person or people to
follow up with about this? The school and researchers front doors seem
closed to queries, maybe there is a side door somewhere?

On Thu, Sep 18, 2014 at 4:01 PM, <x50 at fastmail.fm> wrote:

> I'd recommend the blog post about this, if you haven't seen it already:
>
>
> https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack
>
> It should answer some of your questions. I have only seen speculation on
> why the talk was cancelled.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 977 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140918/ac4601f6/attachment.txt>

From grarpamp at gmail.com  Thu Sep 18 13:53:40 2014
From: grarpamp at gmail.com (grarpamp)
Date: Thu, 18 Sep 2014 16:53:40 -0400
Subject: Apple says ending unlocking practice for LEA/users with ios8
Message-ID: <CAD2Ti2_NRJhjaBSHuArF3m6+u=Ufd3mJrmD_t6-kxowzuwiz0A@mail.gmail.com>

Apple will no longer unlock most iPhones, iPads for police, even with
search warrants

http://www.washingtonpost.com/business/technology/2014/09/17/2612af58-3ed2-11e4-b03f-de718edeb92f_story.html




From tedks at riseup.net  Thu Sep 18 14:18:07 2014
From: tedks at riseup.net (Ted Smith)
Date: Thu, 18 Sep 2014 17:18:07 -0400
Subject: More on the tor scam
In-Reply-To: <1411070467.330795.169160477.074F1647@webmail.messagingengine.com>
References: <541b2c35.0614e00a.1bdf.ffffd6d3@mx.google.com>
 <1411070467.330795.169160477.074F1647@webmail.messagingengine.com>
Message-ID: <1411075087.21331.25.camel@anglachel>

On Thu, 2014-09-18 at 16:01 -0400, x50 at fastmail.fm wrote:
> I'd recommend the blog post about this, if you haven't seen it already: 
> 
> https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack
> 
> It should answer some of your questions. I have only seen speculation on
> why the talk was cancelled.

The talk was almost certainly canceled because it contained admissions
of violating federal wiretapping laws, which is what happens if you
de-anonymize Tor users in the wild.

This is a legally gray area in theory, but I think in practice it would
never be judged in favor of the defendant, and so the CMU legal team
pulled the talk to avoid exposing themselves to liability.

-- 
Sent from Ubuntu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140918/5a3238a4/attachment.sig>

From adi at hexapodia.org  Thu Sep 18 17:23:06 2014
From: adi at hexapodia.org (Andy Isaacson)
Date: Thu, 18 Sep 2014 17:23:06 -0700
Subject: killing RC4 in Chrome [now with certificate data!]
In-Reply-To: <732e0075cfbdb38fe83701cbe151d189@cryptolab.net>
References: <CAJVRA1SCWZmtz7EWMoyOoDM7NDBxFakxDa0gDPrKy6PnT_zZ3A@mail.gmail.com>
 <541AB34F.7080908@cathalgarvey.me>
 <1411053055.21331.17.camel@anglachel> <3763193.Z2n6Afzyi6@lapuntu>
 <1411071413.21331.20.camel@anglachel>
 <20140918204926.GH12685@hexapodia.org>
 <732e0075cfbdb38fe83701cbe151d189@cryptolab.net>
Message-ID: <20140919002306.GI12685@hexapodia.org>

On Thu, Sep 18, 2014 at 07:33:01PM -0400, Griffin Boyce wrote:
> Andy Isaacson wrote:
> >Ted Smith wrote:
> >>It'd be pretty easy to write a script that harvested the allowed
> >>ciphersuites from the top Alexa sites, if you were really interested.
> >>The EFF's HTTPS Observatory might also have this information.
> >
> >Plenty of sites switched *to* RC4 during the BEAST attack mitigation.
> >Some may not have switched back.
> 
>   So, I ran a couple of quick tests, and checked for RC4... and got
> 1903 results for the Alexa Top 500.  Your theory about websites not
> switching back seems to hold water.

Note that the BEAST mitigation consists of moving RC4 to the front of
the list.  RC4 was always a valid option on most server implementations.

So if you're "checking for RC4" by looking at the preference list,
you're overcounting.  Instead you need to look at what the existing
client implementations will choose when connecting to the given server
preference list.

-andy




From juan.g71 at gmail.com  Thu Sep 18 15:26:44 2014
From: juan.g71 at gmail.com (Juan)
Date: Thu, 18 Sep 2014 19:26:44 -0300
Subject: Apple says ending unlocking practice for LEA/users with ios8
In-Reply-To: <CAD2Ti2_NRJhjaBSHuArF3m6+u=Ufd3mJrmD_t6-kxowzuwiz0A@mail.gmail.com>
References: <CAD2Ti2_NRJhjaBSHuArF3m6+u=Ufd3mJrmD_t6-kxowzuwiz0A@mail.gmail.com>
Message-ID: <541b5c2a.4925e00a.2916.0be2@mx.google.com>

On Thu, 18 Sep 2014 16:53:40 -0400
grarpamp <grarpamp at gmail.com> wrote:

> Apple will no longer unlock most iPhones, iPads for police, even with
> search warrants


	WHAHAHAHHAA.

	What, exactly, leads you post such a stupid lie? 



> 
> http://www.washingtonpost.com/business/technology/2014/09/17/2612af58-3ed2-11e4-b03f-de718edeb92f_story.html




From griffin at cryptolab.net  Thu Sep 18 16:33:01 2014
From: griffin at cryptolab.net (Griffin Boyce)
Date: Thu, 18 Sep 2014 19:33:01 -0400
Subject: killing RC4 in Chrome [now with certificate data!]
In-Reply-To: <20140918204926.GH12685@hexapodia.org>
References: <CAJVRA1SCWZmtz7EWMoyOoDM7NDBxFakxDa0gDPrKy6PnT_zZ3A@mail.gmail.com>
 <541AB34F.7080908@cathalgarvey.me> <1411053055.21331.17.camel@anglachel>
 <3763193.Z2n6Afzyi6@lapuntu> <1411071413.21331.20.camel@anglachel>
 <20140918204926.GH12685@hexapodia.org>
Message-ID: <732e0075cfbdb38fe83701cbe151d189@cryptolab.net>

Andy Isaacson wrote:
> Ted Smith wrote:
>> It'd be pretty easy to write a script that harvested the allowed
>> ciphersuites from the top Alexa sites, if you were really interested.
>> The EFF's HTTPS Observatory might also have this information.
> 
> Plenty of sites switched *to* RC4 during the BEAST attack mitigation.
> Some may not have switched back.

   So, I ran a couple of quick tests, and checked for RC4... and got 1903 
results for the Alexa Top 500.  Your theory about websites not switching 
back seems to hold water.

   It's a github repo, since apparently Github doesn't want me to create 
a 17000-line gist. (Fascists!)  Included are the list of supported 
cipher suites for 494/500 websites along with instructions on 
verifying/recreating the results: 
https://github.com/glamrock/ciphersuites

   The nmap command I used was: sudo nmap -sT -PN -p 443 -iL=alexa.csv 
--script=ssl-enum-ciphers.nse -oN=alexa_ciphers.txt

   Which only checks port 443. So if there's some magic port number you 
want to check (say, 9050 or 5222), be sure to swap that out first. If 
you want XML output, use -oX instead of -oN (and it's easy to convert 
xml to json if you're interested in data visualization).  The nmap 
script used was created by Bojan Zdrnja, praised be his name.

best,
Griffin

-- 
"I believe that usability is a security concern; systems that do
not pay close attention to the human interaction factors involved
risk failing to provide security by failing to attract users."
~Len Sassaman




From rysiek at hackerspace.pl  Thu Sep 18 11:29:09 2014
From: rysiek at hackerspace.pl (rysiek)
Date: Thu, 18 Sep 2014 20:29:09 +0200
Subject: killing RC4 in Chrome
In-Reply-To: <1411053055.21331.17.camel@anglachel>
References: <CAJVRA1SCWZmtz7EWMoyOoDM7NDBxFakxDa0gDPrKy6PnT_zZ3A@mail.gmail.com>
 <541AB34F.7080908@cathalgarvey.me> <1411053055.21331.17.camel@anglachel>
Message-ID: <3763193.Z2n6Afzyi6@lapuntu>

Dnia czwartek, 18 września 2014 11:10:55 Ted Smith pisze:
> There's sort of a chicken/egg problem here.
> 
> You can actually just disable them in configuration; in Firefox, you can
> just go to about:config and set all the security.*.rc4* to false instead
> of true.
> 
> However, this breaks a *lot* of sites, including some big ones.

Time for a little name and shame?

-- 
Pozdr
rysiek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 411 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140918/b0e76749/attachment.sig>

From rysiek at hackerspace.pl  Thu Sep 18 13:31:39 2014
From: rysiek at hackerspace.pl (rysiek)
Date: Thu, 18 Sep 2014 22:31:39 +0200
Subject: More on the tor scam
In-Reply-To: <541b2c35.0614e00a.1bdf.ffffd6d3@mx.google.com>
References: <541b2c35.0614e00a.1bdf.ffffd6d3@mx.google.com>
Message-ID: <1576478.E2IXpilFed@lapuntu>

Dnia czwartek, 18 września 2014 16:02:09 Juan pisze:
> And what about this 'vulnerability'? Isn't tor oh so amaazing that even
> the NSA can't track tor users...except that's a stupid lie?

And what about these "germs"? Isn't washing hands oh so amaazing that it makes 
it impossible to get sick, ever... except that's a stupid lie?

-- 
Pozdr
rysiek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 411 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140918/1e87e518/attachment.sig>

From pgut001 at cs.auckland.ac.nz  Thu Sep 18 03:40:27 2014
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Thu, 18 Sep 2014 22:40:27 +1200
Subject: [cryptography] Email encryption for the wider public
In-Reply-To: <20140918085756.GW11848@ctrlc.hu>
Message-ID: <E1XUZ8V-000258-Ki@login01.fos.auckland.ac.nz>

stef <s at ctrlc.hu> writes:

>let me summarize (and ask you to reread and understand) grapamps response to
>you: email is dead.

... he said, via email.

Peter.




From grarpamp at gmail.com  Thu Sep 18 20:19:13 2014
From: grarpamp at gmail.com (grarpamp)
Date: Thu, 18 Sep 2014 23:19:13 -0400
Subject: Bittorrent Bleep
In-Reply-To: <CAEvNM8moMO51Z_pTG4pDwzZoAsvuC-KhaKBTMwRuwxFXVY+FiQ@mail.gmail.com>
References: <CAEm6KbLXhFyCW_rkD9Lh0z-x7LS-ezd8+vx308GqZK7qocGcYQ@mail.gmail.com>
 <CAEvNM8moMO51Z_pTG4pDwzZoAsvuC-KhaKBTMwRuwxFXVY+FiQ@mail.gmail.com>
Message-ID: <CAD2Ti2-rAmYv+y_77Xbmkdz9RF9HMx9vndu8ty-i91x_RJCyNg@mail.gmail.com>

On Thu, Sep 18, 2014 at 11:30 AM, Randolph <rdohm321 at gmail.com> wrote:
> there no mobile version of the encrypted http://firefloo.sf.net ??

You keep announcing/posting links to this suite of related programs
on sourceforge. Please communicate to your team that if you expect
us, or anyone really, to take you seriously you need to *at minimum*
post on your sites detailed instructions on how to reproduce the binaries
you distribute from the sources you provide. That means any and all
details about the build platforms and all the command line steps
used that will allow us to build sha-256 identical binaries to yours.

We've asked you similar things many times before and you've not
responded. When are you going to step up and speak to address
these various issues with the community?

Also, I and others do NOT appreciate you spamming us in private
mail with invite links to your twitters, download links, etc regarding
your magical suite either. Nor was the stunt where you claimed
to be working with EFF re goldbug cool, or explained, either.

Till then I sincerely hope no one falls victim to your warez.




From grarpamp at gmail.com  Thu Sep 18 20:40:56 2014
From: grarpamp at gmail.com (grarpamp)
Date: Thu, 18 Sep 2014 23:40:56 -0400
Subject: Apple says ending unlocking practice for LEA/users with ios8
In-Reply-To: <541b5c2a.4925e00a.2916.0be2@mx.google.com>
References: <CAD2Ti2_NRJhjaBSHuArF3m6+u=Ufd3mJrmD_t6-kxowzuwiz0A@mail.gmail.com>
 <541b5c2a.4925e00a.2916.0be2@mx.google.com>
Message-ID: <CAD2Ti2-jTA68pS6Hi3Bw+bGFqfic8H=7s0=4w44VYDzvD6gk0g@mail.gmail.com>

On Thu, Sep 18, 2014 at 6:26 PM, Juan <juan.g71 at gmail.com> wrote:
>> grarpamp:
>> http://www.washingtonpost.com/business/technology/2014/09/17/2612af58-3ed2-11e4-b03f-de718edeb92f_story.html
>> Apple will no longer unlock most iPhones, iPads for police, even with
>> search warrants
>
>         WHAHAHAHHAA.
>         What, exactly, leads you post such a stupid lie?

Because few speak truth to bullshit like you do.

https://gigaom.com/2014/09/18/apples-warrant-canary-disappears-suggesting-new-patriot-act-demands/

http://www.washingtonpost.com/blogs/the-switch/wp/2014/09/18/newest-androids-will-join-iphones-in-offering-default-encryption-blocking-police/




From rdohm321 at gmail.com  Thu Sep 18 21:57:11 2014
From: rdohm321 at gmail.com (Randolph)
Date: Fri, 19 Sep 2014 05:57:11 +0100
Subject: Bittorrent Bleep
In-Reply-To: <CAD2Ti2-rAmYv+y_77Xbmkdz9RF9HMx9vndu8ty-i91x_RJCyNg@mail.gmail.com>
References: <CAEm6KbLXhFyCW_rkD9Lh0z-x7LS-ezd8+vx308GqZK7qocGcYQ@mail.gmail.com>
 <CAEvNM8moMO51Z_pTG4pDwzZoAsvuC-KhaKBTMwRuwxFXVY+FiQ@mail.gmail.com>
 <CAD2Ti2-rAmYv+y_77Xbmkdz9RF9HMx9vndu8ty-i91x_RJCyNg@mail.gmail.com>
Message-ID: <CAEvNM8nXsV9unqaRpuq98HRL0QXo_ejaL676y2+cmo=xOPxQPA@mail.gmail.com>

Hi Grarpamp
uh? The post was just, that bleep messenger is not open source and I
would not use it.
Instead there is firefloo as open source and it has binaries to
download, which I evaluated. A mobile version of that would be cool,
but I cannot compile this.
The website seems to be run by the QXMPP developer. If you want to
build it yourself, I think the developers added the information here
https://sourceforge.net/p/firefloo/code/HEAD/tree/trunk/branches/0.09/Documentation/COMPILING
or for the used library I think here
https://sourceforge.net/p/spot-on/code/HEAD/tree/branches/0.12/Documentation/COMPILING
as I have never compiled firefloo, I can try to do that with Qt and if
successful provide a script after the weekend, but dont relay on me
for that. But if possible, I send it to you. Regards

2014-09-19 5:19 GMT+02:00 grarpamp <grarpamp at gmail.com>:

> post on your sites detailed instructions on how to reproduce the binaries
> you distribute from the sources you provide. That means any and all
> details about the build platforms and all the command line steps
> used that will allow us to build sha-256 identical binaries to yours.




From grarpamp at gmail.com  Fri Sep 19 04:37:19 2014
From: grarpamp at gmail.com (grarpamp)
Date: Fri, 19 Sep 2014 07:37:19 -0400
Subject: GoldBug SF projects [was: Bittorrent Bleep]
Message-ID: <CAD2Ti2-BgskWH1LXfWVr89vGByu8b1k52VL84vrH3y4ZEWVnoA@mail.gmail.com>

On Fri, Sep 19, 2014 at 12:57 AM, Randolph <rdohm321 at gmail.com> wrote:
> Hi Grarpamp
> uh? The post was just, that bleep messenger is not open source and I
> would not use it.
> Instead there is firefloo as open source and it has binaries to
> download, which I evaluated. A mobile version of that would be cool,
> but I cannot compile this.
> The website seems to be run by the QXMPP developer. If you want to
> build it yourself, I think the developers added the information here
> https://sourceforge.net/p/firefloo/code/HEAD/tree/trunk/branches/0.09/Documentation/COMPILING
> or for the used library I think here
> https://sourceforge.net/p/spot-on/code/HEAD/tree/branches/0.12/Documentation/COMPILING
> as I have never compiled firefloo, I can try to do that with Qt and if
> successful provide a script after the weekend, but dont relay on me
> for that. But if possible, I send it to you. Regards

If you are able to compile a binary that sha-256 matches the
distributed binary, yes, please do make your compilation script and
platform notes available.

No, do not send it to me, send it to the list.


As to the "uh?" above ...

Search results for info on this family of sourceforge applications
are slim and don't really inspire the level of confidence this type
of crypto software would typically require... empty profiles, empty
mailing lists, no CV's, no whitepapers (there is a goldbug manual),
no presentations... no obvious email addresses... the claim to be
working with EFF and CCC... and likely the same folks mimicing TBB
below ... all of which has been said before.

You seem to be the one most familiar with the projects, only one
on the net posting about them (plus Thomas), only one to know
anything, seemingly chatting in the devel channel...
 http://sourceforge.net/p/goldbug/mailman/goldbug-forum/

More people here would like to welcome these new projects provided
they meet some of the usual community standards suitable for crypto
projects. If you (or more specificaly, whoever is behind these) are
playing anonymous or somesuch, and this cluster of projects on
sourceforge is legit, accept my apologies, I'm sure you understand
where people are coming from.

Doing a little more digging and CC'ing some potential relevants
for comment...

 Regarding firefloo ...

> The website seems to be run by the QXMPP developer.

I don't find any obvious forward references to SF from anyone
seemingly affiliated with qxmpp.

The backwards tree...

http://firefloo.sourceforge.net/
http://sourceforge.net/p/firefloo/wiki/Home/
 http://qex.users.sourceforge.net/  qexmpp
 http://manjeetdahiya.users.sourceforge.net/  Manjeet Dahiya
 http://amit1097.users.sourceforge.net/  Amit Jaiswal

The forward tree...

http://code.google.com/p/qxmpp/  qxmpp at googlegroups.com
 http://code.google.com/u/manjeetdahiya/  manjeetdahiya at gmail.com
 http://code.google.com/u/jeremy.laine/  jeremy.laine at gmail.com
 http://code.google.com/u/109046035500614130948/  0xd34df00d at gmail.com

https://github.com/qxmpp-project  qxmpp at googlegroups.com
 https://github.com/manjeetdahiya
  http://manjeetdahiya.com/  manjeetdahiya at gmail.com
   http://www.cse.iitd.ernet.in/~dahiya/  dahiya at cse.iitd.ernet.in
 https://github.com/jlaine
  http://www.jerryweb.org/  a6a9316d247390d196dbdc16960648c0-1457464
at contact.gandi.net
   http://www.sailcut.com/  jeremy.laine at m4x.org 0xD2CF64921ACE2687
 https://github.com/0xd34df00d  0xd34df00d at gmail.com
  http://0xd34df00d.me/  0XD34DF00D.ME at domainsbyproxy.com
   https://plus.google.com/109046035500614130948/posts
   http://leechcraft.org/our-team


Regarding goldbug, again no obvious forward references ...

The backwards tree...

https://www.facebook.com/pages/Goldbug/765809276783788
http://goldbug.sourceforge.net/
 http://sourceforge.net/projects/goldbug/
  http://sourceforge.net/u/berndhs/profile/  Bernd H Stramm
  http://sourceforge.net/u/mikeweber/profile/  Michael Weber
   https://www.google.com/search?q="michael+weber"+(crypto|goldbug)
   https://www.google.com/search?q="wwwmichi at gmx.ch"

http://sourceforge.net/projects/goldbug/files/goldbug-im_WIN_1.1/GoldBug_Secure_Instant_Messeng
er_Manual_1.1.pdf/download
http://en.wikipedia.org/wiki/Draft:GoldBug_(software)
http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/GoldBug_(software)

https://lists.torproject.org/pipermail/tor-talk/2013-July/029107.html
 thomasasta at googlemail.com (Thomas Asta)
http://es.listoso.com/diaspora-discuss/2013-07/msg00013.html
https://mailman.stanford.edu/pipermail/liberationtech/2013-July/010344.html
http://lists.gnupg.org/pipermail/gcrypt-devel/2013-July/002257.html
http://lists.gnupg.org/pipermail/gnupg-users/2013-July/047137.html
http://comments.gmane.org/gmane.comp.peer-to-peer.waste.discuss/218
https://www.mail-archive.com/otr-users at lists.cypherpunks.ca/msg00429.html
http://marc.info/?l=openssl-users&s=goldbug
http://marc.info/?l=openssl-dev&s=goldbug

The forward tree...

https://launchpad.net/~bernd-stramm  bernd.stramm at gmail.com 0x4604458E
https://github.com/berndhs
https://twitter.com/berndhs
https://plus.google.com/113338680925263376814/posts
https://www.facebook.com/public/Bernd-Stramm


Regarding some of the other projects, same issues ...

http://spot-on.sourceforge.net/
 http://sourceforge.net/projects/spot-on/
  http://sourceforge.net/u/textfield/profile/  Alexis Megas

"Echo Protocol"
http://pidgin.im/pipermail/devel/2013-August/023115.html
http://en.wikipedia.org/wiki/Echo_(communications_protocol)

http://bitmail.sourceforge.net/
 http://sourceforge.net/projects/bitmail/
  http://sourceforge.net/u/mikeweber/profile/  Michael Weber
  http://sourceforge.net/u/cholinek/profile/  Damian Cholewa
  http://sourceforge.net/u/donnico/profile/  Nicola De Filippo
  http://sourceforge.net/u/dontinelli/profile/  Don Tinelli

http://dooble.sourceforge.net/
 http://sourceforge.net/projects/dooble/
  http://sourceforge.net/u/textfield/profile/  Alexis Megas

http://browser4tor.sourceforge.net/
 http://sourceforge.net/projects/browser4tor/
http://torbrowser.sourceforge.net/
 http://sourceforge.net/projects/torbrowser/
  http://sourceforge.net/u/doobleaner/profile/  messengerfan
  http://sourceforge.net/u/sergeyvar/profile/  Sergey V

http://interface.sourceforge.net/
 http://sourceforge.net/projects/interface/
  http://sourceforge.net/u/berndhs/profile/  Bernd H Stramm
  http://sourceforge.net/u/doobleaner/profile/  messengerfan

http://sourceforge.net/projects/starbeam/
 http://sourceforge.net/u/marcomu/profile/  Marco M


Someone else can search more.




From henryaugustuschamberlain at gmail.com  Fri Sep 19 02:33:31 2014
From: henryaugustuschamberlain at gmail.com (Henry Augustus Chamberlain)
Date: Fri, 19 Sep 2014 11:33:31 +0200
Subject: Email encryption for the wider public
In-Reply-To: <CAAMy4US_+776z-S-f9MMKnRC4BcP1pwV_DoPueDzpks0R3hfjw@mail.gmail.com>
References: <CABU-GB37qpwUuTtK15VmykzuR4_-AVQvSFUYXO=W8VC3J2hEFA@mail.gmail.com>
 <CAD2Ti29NreOO75KPNE3a5P6Fg-A7+O1H4NLRRQM4t7_QAwebaA@mail.gmail.com>
 <CAAMy4US_+776z-S-f9MMKnRC4BcP1pwV_DoPueDzpks0R3hfjw@mail.gmail.com>
Message-ID: <CABU-GB1p8dPE0Pq1cCGixantmHvvVqgg6igWxnM9sUiqx4LC9Q@mail.gmail.com>

Hi all,

Some very interesting points so far. To avoid making this email too
long, I'm going to reply without quoting - I hope this doesn't
inconvenience anyone.

Regarding the memorability issue, all I can say is that end-to-end
encryption really does require sharing 100+ bit keys - it's essential!
You may be able to memorise your email address at the moment, but
that's only half the story, since you can't memorise your public key!
I can't solve every problem with PGP, but I still think this proposal
solves a fair few of them. In some cases it improves on PGP, and in
the other case it's at least no worse: you can still use online
institutional directories etc if you want.

Don't forget all the advantages this scheme could bring! Simplicity
and transparency for the end user is really important! They're more
likely to understand the significance of a public key if it forms part
of the address (despite not understanding why it has to be this way).

Perhaps it doesn't help Derek's mum - nor my mum, for that matter -
but there are plenty of people for whom PGP is to complex whereas this
scheme would be manageable. If you wish, you can send some emails
encrypted and others unencrypted, just like you can with PGP - in this
case, you'd just need two addresses (which is surely no worse than
PGP, where you have an address and a key).

Regarding telephone conversations: if it's with a mobile phone,
perhaps a text message would work; if it's a landline, you probably
have internet access, so an initial unencrypted email would work if
you're not worried about man-in-the-middle attacks. (If you are
worried about such attacks, then a bit of effort might be required,
beyond just rattling off a short email address over the phone.)

By the way, I'm suggesting printable characters to encode the key, not
arbitrary bytes. An alphanumeric character stores nearly 6 bits (or 5
if it isn't case-sensitive), so 256-bit keys would require around 50
characters. Email standards allow 64 characters for the local part of
the address, so there's room for error-correction too.

Regarding the point about forged email addresses: for cryptography to
work, you need to identify people using their keys, not their
addresses. With PGP, you could send an email to my mum, using my email
address but the wrong signature; if my mum is just relying on the
email address, then that defeats the purpose of PGP. Of course, most
PGP systems compare the key with that stored in the address book; a
similar system can be used for my proposal, but with the advantage
that forged emails don't give rise to the situation where the address
is known but the key is unknown, which might lead a naive user to
assume something's broken with the crypto software.

Regarding webmail... I still haven't solved that one. Maybe there's an
inherent contradiction in trying to include webmail in an end-to-end
encryption system.

I like the idea of using the "address+key at gmail.com" technique,
although it does contradict the idea of "identify people using the
key, not the address". Also, in my original proposal, I suggested
using the private key (instead of a password) to login to the email
server. I reckon Gmail is unlikely to allow that in the near future :)

Best wishes,

Henry




From cathalgarvey at cathalgarvey.me  Fri Sep 19 04:43:33 2014
From: cathalgarvey at cathalgarvey.me (Cathal Garvey)
Date: Fri, 19 Sep 2014 12:43:33 +0100
Subject: Email encryption for the wider public
In-Reply-To: <CABU-GB1p8dPE0Pq1cCGixantmHvvVqgg6igWxnM9sUiqx4LC9Q@mail.gmail.com>
References: <CABU-GB37qpwUuTtK15VmykzuR4_-AVQvSFUYXO=W8VC3J2hEFA@mail.gmail.com>
 <CAD2Ti29NreOO75KPNE3a5P6Fg-A7+O1H4NLRRQM4t7_QAwebaA@mail.gmail.com>
 <CAAMy4US_+776z-S-f9MMKnRC4BcP1pwV_DoPueDzpks0R3hfjw@mail.gmail.com>
 <CABU-GB1p8dPE0Pq1cCGixantmHvvVqgg6igWxnM9sUiqx4LC9Q@mail.gmail.com>
Message-ID: <541C16E5.4080502@cathalgarvey.me>

> Regarding the memorability issue, all I can say is that end-to-end
> encryption really does require sharing 100+ bit keys - it's essential!
> You may be able to memorise your email address at the moment, but
> that's only half the story, since you can't memorise your public key!

But you can memorise a passphrase and email address, and generate your
public key on the fly using key generation algorithms like the one used
in miniLock/deadLock. This deterministic key approach has its
disadvantages, but it addresses two key issues with PGP:

1) Your key doesn't exist when you're not "logged in" to a program
implementing the standard, so it can't be scooped and
brute-force-decrypted by an evil maid or the later installation of a
rootkit.

2) When out with friends, if you discover a friend who likes crypto or
convince someone else to try it, you can generate your pubkey on the fly
by "logging in", either on your own computer or theirs. Yes, this
transiently generates your private key on potentially untrusted
hardware, so it's a risk that must be carefully measured.

I think the "mail encryption for all" problem is entirely crackable. I
feel this would be trivial if we'd accept encryption tied to particular
devices, because that would hand off entirely the key management issue.
But, we don't want to be tied to particular devices, so we end up with
stupid problems like OTR keys that are different between phone and
laptop, or PGP keys not trusted on a phone, so can't decrypt. Key
generation on the fly helps to some extent, but it's hard to patch into
an existing system.

It would be nice if some future "email" was an entirely on-the-fly
affair; "logging in" deterministically generates a keypair *and* the
address in a DHT to visit to collect your most recent mail. Same process
on any device, uses proven primitives. With some UX to forbid weak keys
(like the key strength checker in miniLock) and a well designed, costly
key derivation function, you're pretty secure, and your mail can be
stored in plaintext or kept encrypted locally at the option of the
implementor or user.

On 19/09/14 10:33, Henry Augustus Chamberlain wrote:
> Hi all,
> 
> Some very interesting points so far. To avoid making this email too
> long, I'm going to reply without quoting - I hope this doesn't
> inconvenience anyone.
> 
> Regarding the memorability issue, all I can say is that end-to-end
> encryption really does require sharing 100+ bit keys - it's essential!
> You may be able to memorise your email address at the moment, but
> that's only half the story, since you can't memorise your public key!
> I can't solve every problem with PGP, but I still think this proposal
> solves a fair few of them. In some cases it improves on PGP, and in
> the other case it's at least no worse: you can still use online
> institutional directories etc if you want.
> 
> Don't forget all the advantages this scheme could bring! Simplicity
> and transparency for the end user is really important! They're more
> likely to understand the significance of a public key if it forms part
> of the address (despite not understanding why it has to be this way).
> 
> Perhaps it doesn't help Derek's mum - nor my mum, for that matter -
> but there are plenty of people for whom PGP is to complex whereas this
> scheme would be manageable. If you wish, you can send some emails
> encrypted and others unencrypted, just like you can with PGP - in this
> case, you'd just need two addresses (which is surely no worse than
> PGP, where you have an address and a key).
> 
> Regarding telephone conversations: if it's with a mobile phone,
> perhaps a text message would work; if it's a landline, you probably
> have internet access, so an initial unencrypted email would work if
> you're not worried about man-in-the-middle attacks. (If you are
> worried about such attacks, then a bit of effort might be required,
> beyond just rattling off a short email address over the phone.)
> 
> By the way, I'm suggesting printable characters to encode the key, not
> arbitrary bytes. An alphanumeric character stores nearly 6 bits (or 5
> if it isn't case-sensitive), so 256-bit keys would require around 50
> characters. Email standards allow 64 characters for the local part of
> the address, so there's room for error-correction too.
> 
> Regarding the point about forged email addresses: for cryptography to
> work, you need to identify people using their keys, not their
> addresses. With PGP, you could send an email to my mum, using my email
> address but the wrong signature; if my mum is just relying on the
> email address, then that defeats the purpose of PGP. Of course, most
> PGP systems compare the key with that stored in the address book; a
> similar system can be used for my proposal, but with the advantage
> that forged emails don't give rise to the situation where the address
> is known but the key is unknown, which might lead a naive user to
> assume something's broken with the crypto software.
> 
> Regarding webmail... I still haven't solved that one. Maybe there's an
> inherent contradiction in trying to include webmail in an end-to-end
> encryption system.
> 
> I like the idea of using the "address+key at gmail.com" technique,
> although it does contradict the idea of "identify people using the
> key, not the address". Also, in my original proposal, I suggested
> using the private key (instead of a password) to login to the email
> server. I reckon Gmail is unlikely to allow that in the near future :)
> 
> Best wishes,
> 
> Henry
> 

-- 
Twitter: @onetruecathal, @formabiolabs
Phone: +353876363185
Blog: http://indiebiotech.com
miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x988B9099.asc
Type: application/pgp-keys
Size: 6176 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140919/a486bdfd/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140919/a486bdfd/attachment.sig>

From juliocesarfort at gmail.com  Thu Sep 18 21:23:16 2014
From: juliocesarfort at gmail.com (Julio Cesar Fort)
Date: Fri, 19 Sep 2014 14:23:16 +1000
Subject: Apple says ending unlocking practice for LEA/users with ios8
In-Reply-To: <CAD2Ti2-jTA68pS6Hi3Bw+bGFqfic8H=7s0=4w44VYDzvD6gk0g@mail.gmail.com>
References: <CAD2Ti2_NRJhjaBSHuArF3m6+u=Ufd3mJrmD_t6-kxowzuwiz0A@mail.gmail.com>
 <541b5c2a.4925e00a.2916.0be2@mx.google.com>
 <CAD2Ti2-jTA68pS6Hi3Bw+bGFqfic8H=7s0=4w44VYDzvD6gk0g@mail.gmail.com>
Message-ID: <CABbME3Lv6+Xn-j2sHGst746R_FzXPkDcr75F8XjQ2P+vcqD4hg@mail.gmail.com>

Some technical information about this matter can be found at Jonathan
Zdziarski's blog: http://www.zdziarski.com/blog/?p=3875

On Fri, Sep 19, 2014 at 1:40 PM, grarpamp <grarpamp at gmail.com> wrote:

> On Thu, Sep 18, 2014 at 6:26 PM, Juan <juan.g71 at gmail.com> wrote:
> >> grarpamp:
> >>
> http://www.washingtonpost.com/business/technology/2014/09/17/2612af58-3ed2-11e4-b03f-de718edeb92f_story.html
> >> Apple will no longer unlock most iPhones, iPads for police, even with
> >> search warrants
> >
> >         WHAHAHAHHAA.
> >         What, exactly, leads you post such a stupid lie?
>
> Because few speak truth to bullshit like you do.
>
>
> https://gigaom.com/2014/09/18/apples-warrant-canary-disappears-suggesting-new-patriot-act-demands/
>
>
> http://www.washingtonpost.com/blogs/the-switch/wp/2014/09/18/newest-androids-will-join-iphones-in-offering-default-encryption-blocking-police/
>



-- 
Julio Cesar Fort
GPG public key: http://www.juliocesarfort.com/juliocesarfort.gpg
-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 2023 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140919/e7366c19/attachment.txt>

From grarpamp at gmail.com  Fri Sep 19 13:10:01 2014
From: grarpamp at gmail.com (grarpamp)
Date: Fri, 19 Sep 2014 16:10:01 -0400
Subject: Fwd: [Cryptography] Shaming sites that send sensitive information
 over HTTP
In-Reply-To: <FFBBC6C1-BADB-4AC4-A132-D5A944F20AF2@lrw.com>
References: <FFBBC6C1-BADB-4AC4-A132-D5A944F20AF2@lrw.com>
Message-ID: <CAD2Ti29g3D=NHRUd9e2s5-Fs8555PLeYWqO7iCm9y+C35r7THQ@mail.gmail.com>

---------- Forwarded message ----------
From: Jerry Leichter <leichter at lrw.com>
Date: Fri, Sep 19, 2014 at 12:03 PM
To: Cryptography <cryptography at metzdowd.com>

My favorite:  The NSA's web site *redirects HTTPS to HTTP*.  Some kind
of back-handed acknowledgement of what they do?

http://httpshaming.tumblr.com




From juan.g71 at gmail.com  Fri Sep 19 12:17:45 2014
From: juan.g71 at gmail.com (Juan)
Date: Fri, 19 Sep 2014 16:17:45 -0300
Subject: Apple says ending unlocking practice for LEA/users with ios8
In-Reply-To: <CAD2Ti2-jTA68pS6Hi3Bw+bGFqfic8H=7s0=4w44VYDzvD6gk0g@mail.gmail.com>
References: <CAD2Ti2_NRJhjaBSHuArF3m6+u=Ufd3mJrmD_t6-kxowzuwiz0A@mail.gmail.com>
 <541b5c2a.4925e00a.2916.0be2@mx.google.com>
 <CAD2Ti2-jTA68pS6Hi3Bw+bGFqfic8H=7s0=4w44VYDzvD6gk0g@mail.gmail.com>
Message-ID: <541c815a.0406e00a.22ad.fffff0df@mx.google.com>

On Thu, 18 Sep 2014 23:40:56 -0400
grarpamp <grarpamp at gmail.com> wrote:

> On Thu, Sep 18, 2014 at 6:26 PM, Juan <juan.g71 at gmail.com> wrote:
> >> grarpamp:
> >> http://www.washingtonpost.com/business/technology/2014/09/17/2612af58-3ed2-11e4-b03f-de718edeb92f_story.html
> >> Apple will no longer unlock most iPhones, iPads for police, even
> >> with search warrants
> >
> >         WHAHAHAHHAA.
> >         What, exactly, leads you post such a stupid lie?
> 
> Because few speak truth to bullshit like you do.


	Thanks for the links. 

	


> 
> https://gigaom.com/2014/09/18/apples-warrant-canary-disappears-suggesting-new-patriot-act-demands/
> 
> http://www.washingtonpost.com/blogs/the-switch/wp/2014/09/18/newest-androids-will-join-iphones-in-offering-default-encryption-blocking-police/




From x50 at fastmail.fm  Fri Sep 19 13:29:49 2014
From: x50 at fastmail.fm (x50 at fastmail.fm)
Date: Fri, 19 Sep 2014 16:29:49 -0400
Subject: More on the tor scam
In-Reply-To: <1411075087.21331.25.camel@anglachel>
References: <541b2c35.0614e00a.1bdf.ffffd6d3@mx.google.com>
 <1411070467.330795.169160477.074F1647@webmail.messagingengine.com>
 <1411075087.21331.25.camel@anglachel>
Message-ID: <1411158589.452027.169563085.291D0ACC@webmail.messagingengine.com>

On Thu, Sep 18, 2014, at 05:18 PM, Ted Smith wrote:
> The talk was almost certainly canceled because it contained admissions
> of violating federal wiretapping laws, which is what happens if you
> de-anonymize Tor users in the wild.
> 
> This is a legally gray area in theory, but I think in practice it would
> never be judged in favor of the defendant, and so the CMU legal team
> pulled the talk to avoid exposing themselves to liability.

Thanks Ted.. I fully agree that this is almost certainly the reason for
the cancellation of the talk and for good reason. Many of us are aware
of how these cases typically go for the defendants and it is not unusual
for the prosecution to push for extreme sentences in these types of
cases.

That said, while I do understand the reasoning for cancelling the talk,
I've still be extremely disappointed in the lack of cooperation with the
Tor project on addressing the concerns. Especially given the
relationship between CMU and CERT. It seems there would have to be some
middle ground between a public speech at a convention and being almost
completely silent when it comes to working with the developers on
understanding the issue and implementing a fix. 

As for Patrick's question, unfortunately I am not aware of any side
doors to collect additional information and I am not overly optimistic
given the developer's issues with obtaining the information they
requested on the attack.




From rdohm321 at gmail.com  Fri Sep 19 09:06:38 2014
From: rdohm321 at gmail.com (Randolph)
Date: Fri, 19 Sep 2014 17:06:38 +0100
Subject: compiling bleep
Message-ID: <CAEvNM8nV8ctN1KbyVPzf=LGnm+poCPXS2JgpOxB_=giTYWtRFw@mail.gmail.com>

Hi Grarpamp,
the point was that I would not use bleep messenger from bittorrent, as
it is not open source. Others like the one you did a research on might
be worth for further testings, either by the binaries or - you seem to
be keen on to - compile it yourself.  I cannot help you with compile
firefloo messenger on linux or windows, as I have not done this yet.
Why don' t you test the binaries? The source and the binaries might
not be machting from hash, because if you know source projects, the
source might be corrected on one or two files even when the binaries
have been build. So better build the software from source and use your
own binaries. I would suggest to build the crypto core first, which is
spot-on. Regards

1) I guess you use windows.

2a) download the source from either the download files
https://sourceforge.net/projects/spot-on/files/Version%200.11/
File: Spot-On.d.tar.gz

2b) or use the SVN url to be current:
https://sourceforge.net/p/spot-on/code/HEAD/tree/
svn checkout svn://svn.code.sf.net/p/spot-on/code/ spot-on-code

3) install Qt.io
Use Version 5.3.1
Qt 5.3.2 for Windows 32-bit (MinGW 4.8.2, OpenGL, 737 MB)
http://download.qt-project.org/official_releases/qt/5.3/5.3.2/qt-opensource-windows-x86-mingw482_opengl-5.3.2.exe
configure it correctly

4a) use the comand line app from Qt
and here you use these commands:
https://sourceforge.net/p/spot-on/code/HEAD/tree/branches/0.12/Documentation/COMPILING
Linux:
qmake -o Makefile spot-on.pro
Return
make

4b) or use better  the creator app from Qt. this is very convenient,
so I describe this way further:

Load the file "spot-on.win.qt5.pro" with the Creator. It is the .pro
file for the kernel. Under windows it also loads the
spot-on-gui.win.qt5.pro, which is the .pro file for the gui. (Under
linux you might need to pic up both and compile both).

5) click the green forward icon to compile the pro file (for release
and pro-gui), in the Creator. the compile runs and shows the app.

6.) Enter password, generate keys and connect to the project server in
Neighbours tab: tulip.cloud.tilaa.com 4710

7) Ask a friend to do the same or to use the binaries: exchange keys,
and chat. Done. All is encrypted and you never need to exchange keys.

Hope this helps to use Qt. It is very easy.
Regards


2014-09-19 13:37 GMT+02:00 grarpamp <grarpamp at gmail.com>:
> If you are able to compile a binary
> No, do not send it to me, send it to the list.




From grarpamp at gmail.com  Fri Sep 19 15:30:30 2014
From: grarpamp at gmail.com (grarpamp)
Date: Fri, 19 Sep 2014 18:30:30 -0400
Subject: More on the tor scam
In-Reply-To: <1411158589.452027.169563085.291D0ACC@webmail.messagingengine.com>
References: <541b2c35.0614e00a.1bdf.ffffd6d3@mx.google.com>
 <1411070467.330795.169160477.074F1647@webmail.messagingengine.com>
 <1411075087.21331.25.camel@anglachel>
 <1411158589.452027.169563085.291D0ACC@webmail.messagingengine.com>
Message-ID: <CAD2Ti297rftfVDnbHdkbZnpoTKmeNXuvPCk68hFrvbn12Wfxjg@mail.gmail.com>

On Fri, Sep 19, 2014 at 4:29 PM,  <x50 at fastmail.fm> wrote:
> On Thu, Sep 18, 2014, at 05:18 PM, Ted Smith wrote:
>> The talk was almost certainly canceled because it contained admissions
>> of violating federal wiretapping laws, which is what happens if you
>> de-anonymize Tor users in the wild.
>> This is a legally gray area in theory, but I think in practice it would
>> never be judged in favor of the defendant, and so the CMU legal team
>> pulled the talk to avoid exposing themselves to liability.

Wiretapping usually involves collecting content or traffic metadata
that is identifiable to the user. When not against a specific user,
disclosing a real IP address in itself might be more of an edge case
along the lines of circumvention of the tech, cracking what the user
setup, etc. There probably need to be test cases to cover these areas
as applied to anonymity networks.

> I've still be extremely disappointed in the lack of cooperation with the
> Tor project on addressing the concerns. Especially given the
> relationship between CMU and CERT.

That's still thinking in terms of some BS non-full-disclosure
legal/professional/industry play-nice rules. There's no reason
why, if their is no crime, no contractual party loss, etc that
the 1st amendment can't be used to disclose it.

And ZERO reason whatsoever that the research cannot simply
be anonymized, rewritten and anonymously posted somewhere
as if it were developed in parallel by some anon.

It's as if while playing their legal/credit games they forget/ignore
that vulnerable users come first. Or someone bought them out.




From odinn.cyberguerrilla at riseup.net  Fri Sep 19 19:56:43 2014
From: odinn.cyberguerrilla at riseup.net (Odinn Cyberguerrilla)
Date: Fri, 19 Sep 2014 19:56:43 -0700
Subject: Activism questions, please reply to thread by e-mail or if you
 prefer by bitmessage [included]
Message-ID: <e9cf76290ff3454e2a1581fe7eadee24@riseup.net>

Hello,

Recent events have led me to seriously consider a fast.  In protest 
culture there has been a difference between how hunger strikes and fasts 
are looked at.  The difference is explained well enough here:
http://wagingnonviolence.org/feature/rules-hunger-striking-radicals/

I would like to get your opinions pro or con.  Please feel free to tell
me just how important it is that I should consider it or just how
ridiculous it is that I am even bringing it up.  I value your opinion.
However, I would greatly appreciate receiving your opinion, no matter
how much or how little you have to say, within a day's time from when I
am sending this message.

See also:
http://www.wikihow.com/Go-on-a-Hunger-Strike-Safely

Causes that most interest me are related to the interest of the USA
police state to militarize and surveill at home while attempting to
engage in war after war overseas without end,

The coercive and violent methods that the US government and governments
like it (e.g. Russia, China, and many others) around the globe use in
order to forcibly extract through taxation from residents so that they
can wage war profitably,

The social problems inherent in unquestioning compliance with
nationality and laws attached to such notions, and the alternatives
which could be presented through decentralization of giving systems
which are more similar to those found in nature.

I realize that if I do this I'm going to have to distill a cause and
make it palatable and reduce it basically to one so that it's clear and
to the point (in addition to have clear and obvious targets for who is 
the person or persons who I mean to draw attention to by way of the 
fast, etc.)

If you'd rather not reply by e-mail, here's a public bitmessage address
associated with this issue that any of you can reply to:

BM-2cWLvGzKgX9jdQ5u43D6JEDgfnFhUzrj33

Details of bitmessage installation regardless of whatever operating 
system you have are here:
https://bitmessage.org
(or)
https://bitmessage.org/wiki/Main_Page

I look forward to your advice.

Respectfully,

Odinn




From me at staticsafe.ca  Fri Sep 19 17:52:41 2014
From: me at staticsafe.ca (staticsafe)
Date: Fri, 19 Sep 2014 20:52:41 -0400
Subject: Fwd: [Cryptography] Shaming sites that send sensitive information
 over HTTP
In-Reply-To: <E1XV78D-0000Ot-5O@login01.fos.auckland.ac.nz>
References: <E1XV78D-0000Ot-5O@login01.fos.auckland.ac.nz>
Message-ID: <541CCFD9.6060504@staticsafe.ca>

On 9/19/2014 18:58, Peter Gutmann wrote:
> grarpamp <grarpamp at gmail.com> forwarded:
> 
>> My favorite:  The NSA's web site *redirects HTTPS to HTTP*.  Some kind of
>> back-handed acknowledgement of what they do?
> 
> My guess is that it's politically-motivated, if you're the NSA would you want
> to buy your certs from a commercial CA, and if you're a commercial CA would
> you want to be known as the supplier of trusted certs to the NSA?
> 
> Peter.
> 

When I go to www.nsa.gov, I do not get a redirect to HTTP. HTTPS with a
cert provided by GeoTrust is what I get.

-- 
staticsafe
https://staticsafe.ca




From komachi at openmailbox.org  Sat Sep 20 03:32:59 2014
From: komachi at openmailbox.org (Anton Nesterov)
Date: Sat, 20 Sep 2014 10:32:59 +0000
Subject: Russia moves date when personal data law came into force to 1st Jan
 2015
Message-ID: <541D57DB.5030700@openmailbox.org>

Today Duma have passed in first reading bill which moves date when
personal data law came into force from 1st Sep 2016 to 1st Jan 2015.

Original law forbid storing any personal data of Russian users outside
of Russia.

"We need to speed up the law, it's not a secret that personal data is
the object of attention of criminals and special services of Western
countries." — says one of the authors, Alexandr Yushenko from Communists
party.

"And maybe we need to forbid all that social networks, as in Iran? Let
everyone involved in amateur, go to the cinema, museums. They sit alone
in that networks, or acquaint with somebody, and then follows sexual
promiscuity. It's indeed dangerous, you just say an extra word — and
then claim on you in court!" — says Vitaliy Zolochevsky, member of LDPR
party.

438 votes for, 0 against, 0 abstained.


Bill
http://asozd2.duma.gov.ru/main.nsf/%28Spravka%29?OpenAgent&RN=596277-6&02
Voting results http://vote.duma.gov.ru/vote/87314
Report http://rublacklist.net/8662/ (in Russian)
Another one http://www.rosbalt.ru/main/2014/09/19/1317343.html (in Russian)

-- 
https://komachi.github.io
GPG key: 0CE8 65F1 9043 2B11 25A5 74A7 1187 6869 67AA 56E4
https://keybase.io/komachi/key.asc





From pgut001 at cs.auckland.ac.nz  Fri Sep 19 15:58:25 2014
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Sat, 20 Sep 2014 10:58:25 +1200
Subject: Fwd: [Cryptography] Shaming sites that send sensitive information
 over HTTP
In-Reply-To: <CAD2Ti29g3D=NHRUd9e2s5-Fs8555PLeYWqO7iCm9y+C35r7THQ@mail.gmail.com>
Message-ID: <E1XV78D-0000Ot-5O@login01.fos.auckland.ac.nz>

grarpamp <grarpamp at gmail.com> forwarded:

>My favorite:  The NSA's web site *redirects HTTPS to HTTP*.  Some kind of
>back-handed acknowledgement of what they do?

My guess is that it's politically-motivated, if you're the NSA would you want
to buy your certs from a commercial CA, and if you're a commercial CA would
you want to be known as the supplier of trusted certs to the NSA?

Peter.




From s at ctrlc.hu  Sat Sep 20 08:38:41 2014
From: s at ctrlc.hu (stef)
Date: Sat, 20 Sep 2014 17:38:41 +0200
Subject: salty axolotl
Message-ID: <20140920153840.GE11848@ctrlc.hu>

you might like to use this, or you might want to improve on it, or enjoy
ridiculing me for it and its bugs:

axolotl ratched implemented with libsodium and scrypt (maybe the latter has
been over-used a bit):

https://github.com/stef/saxolotl

-- 
otr fp: https://www.ctrlc.hu/~stef/otr.txt




From l at odewijk.nl  Sat Sep 20 09:38:48 2014
From: l at odewijk.nl (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?=)
Date: Sat, 20 Sep 2014 18:38:48 +0200
Subject: Unraveling NSA's TURBULENCE Programs
In-Reply-To: <CAJVRA1RNzOu_JDfoqBcSDUQ9R24h6MfOkWVUfztRZWNVe_bLJA@mail.gmail.com>
References: <CAJVRA1RNzOu_JDfoqBcSDUQ9R24h6MfOkWVUfztRZWNVe_bLJA@mail.gmail.com>
Message-ID: <CAHWD2rKPGR6KUizAhuBgUbJV_tGx_3rMu5RDJ3BTz=oPNyOuhA@mail.gmail.com>

Funny to think of an NSA program as being "over budget" when the DoD has
such a massive excess of funds.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 167 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140920/cf5897c8/attachment.txt>

From codesinchaos at gmail.com  Sat Sep 20 09:43:56 2014
From: codesinchaos at gmail.com (CodesInChaos)
Date: Sat, 20 Sep 2014 18:43:56 +0200
Subject: salty axolotl
In-Reply-To: <20140920153840.GE11848@ctrlc.hu>
References: <20140920153840.GE11848@ctrlc.hu>
Message-ID: <CAK9dnSyw1dXhDO8uuJjsQ24B39FWwWECt6vdYNUuxmprw1Xq7w@mail.gmail.com>

Why would you use scrypt for anything except strengthening low entropy
secrets (like passwords)?
For high entropy secrets there are much simpler and cleaner
alternatives, such as HKDF.




From s at ctrlc.hu  Sat Sep 20 09:53:06 2014
From: s at ctrlc.hu (stef)
Date: Sat, 20 Sep 2014 18:53:06 +0200
Subject: salty axolotl
In-Reply-To: <CAK9dnSyw1dXhDO8uuJjsQ24B39FWwWECt6vdYNUuxmprw1Xq7w@mail.gmail.com>
References: <20140920153840.GE11848@ctrlc.hu>
 <CAK9dnSyw1dXhDO8uuJjsQ24B39FWwWECt6vdYNUuxmprw1Xq7w@mail.gmail.com>
Message-ID: <20140920165306.GF11848@ctrlc.hu>

On Sat, Sep 20, 2014 at 06:43:56PM +0200, CodesInChaos wrote:
> Why would you use scrypt for anything except strengthening low entropy
> secrets (like passwords)?
> For high entropy secrets there are much simpler and cleaner
> alternatives, such as HKDF.

excellent observation. with nacl would generic_hash(master_key, some_const, key_size) 
be sufficient as a kdf?

-- 
otr fp: https://www.ctrlc.hu/~stef/otr.txt




From s at ctrlc.hu  Sat Sep 20 10:14:48 2014
From: s at ctrlc.hu (stef)
Date: Sat, 20 Sep 2014 19:14:48 +0200
Subject: salty axolotl
In-Reply-To: <20140920165306.GF11848@ctrlc.hu>
References: <20140920153840.GE11848@ctrlc.hu>
 <CAK9dnSyw1dXhDO8uuJjsQ24B39FWwWECt6vdYNUuxmprw1Xq7w@mail.gmail.com>
 <20140920165306.GF11848@ctrlc.hu>
Message-ID: <20140920171448.GG11848@ctrlc.hu>

On Sat, Sep 20, 2014 at 06:53:06PM +0200, stef wrote:
> On Sat, Sep 20, 2014 at 06:43:56PM +0200, CodesInChaos wrote:
> > Why would you use scrypt for anything except strengthening low entropy
> > secrets (like passwords)?

reason: i'm stupid, wasn't thinking, and had so far no such valuable feedback
as ours.

> > For high entropy secrets there are much simpler and cleaner
> > alternatives, such as HKDF.
> 
> excellent observation. with nacl would generic_hash(master_key, some_const, key_size) 
> be sufficient as a kdf?

thank you for this useful feedback! i removed scrypt and replaced it with
above suggestion. updated on git.

-- 
otr fp: https://www.ctrlc.hu/~stef/otr.txt




From coderman at gmail.com  Sun Sep 21 19:29:27 2014
From: coderman at gmail.com (coderman)
Date: Sun, 21 Sep 2014 19:29:27 -0700
Subject: [cryptography] RC4 is dangerous in ways not yet known - heads up
 on near injection WPA2 downgrade to TKIP RC4
In-Reply-To: <CACt_CWnnF9X4Vhkn=nGAFTise04gfxd5a4j_Ltzs_dZEawLFiQ@mail.gmail.com>
References: <CAJVRA1Sxg_VJ1JO2G0+fKBfcEdMEJULsrp7-Q_OcmVFHEwza0Q@mail.gmail.com>
 <CACt_CWnnF9X4Vhkn=nGAFTise04gfxd5a4j_Ltzs_dZEawLFiQ@mail.gmail.com>
Message-ID: <CAJVRA1Rvwqr4kiFDagTtkKq7hyBHKWeoBqpE0roH-G3c5xXaaQ@mail.gmail.com>

On 9/21/14, Daniel <kyhwana at gmail.com> wrote:
> Hey coderman,
> has this been released anywhere? I asked because I discovered
> http://people.cs.kuleuven.be/~mathy.vanhoef/papers/wpatkip.pdf again.
> (Where with TKIP, if you can inject packets on the air, you can get
> back unencrypted traffic that was headed towards the client..)


hi Daniel!

please continue posting relevant material.  this is released plus or
minus Full Disclosure   moderation queue. you are smart enough to see
why this is a dead end, and "optional" TKIP will live in WPA2 forever.

you may also want to keep in touch with K. Paterson who wrote about
another TKIP issue as mentioned earlier in this thread.  i have not
heard of any further input from K. i have not seen any further public
confirmation of active TKIP downgrade or implications.

silence the story, per usual.

best regards,




From coderman at gmail.com  Sun Sep 21 20:11:17 2014
From: coderman at gmail.com (coderman)
Date: Sun, 21 Sep 2014 20:11:17 -0700
Subject: Fwd: [Cryptography] Shaming sites that send sensitive information
 over HTTP
In-Reply-To: <541CCFD9.6060504@staticsafe.ca>
References: <E1XV78D-0000Ot-5O@login01.fos.auckland.ac.nz>
 <541CCFD9.6060504@staticsafe.ca>
Message-ID: <CAJVRA1RxrsEEavSQ9zBrY+xfz92PvF3in6ugxrL9eSjCgN_MVw@mail.gmail.com>

On 9/19/14, staticsafe <me at staticsafe.ca> wrote:
> ...
> When I go to www.nsa.gov, I do not get a redirect to HTTP. HTTPS with a
> cert provided by GeoTrust is what I get.


well, at least we know they're listening to customer feedback!
 ;)


[this did indeed change in the interim period, due to server side
configuration.]




From coderman at gmail.com  Sun Sep 21 20:23:26 2014
From: coderman at gmail.com (coderman)
Date: Sun, 21 Sep 2014 20:23:26 -0700
Subject: [Dailydave] Protecting your code versions.
In-Reply-To: <541C79F9.2050000@immunityinc.com>
References: <541C79F9.2050000@immunityinc.com>
Message-ID: <CAJVRA1QyS_MZUXip-zvK3T4j-F-z1O35dHyujKF55YA3fn6u_A@mail.gmail.com>

hi Dave, long time fan. first time feedbacker, well:

On 9/19/14, Dave Aitel <dave at immunityinc.com> wrote:
> ...
> Everyone is sick of the Kaspersky guys doing three hundred page PDFs
> with a long listing of which versions of some trojan they found were
> installed when, and what features each trojan had, and what possible
> code reuse there was. And of course, if there's an 0day in some random
> trojan, everyone likes to rip that out and spend years pontificating
> about it.

no doubt. i prefer my salty rants Aitel stylez! all of us in the game
have lineage to a tee... but i digress,


> But even if I'm not using 0day, I often want to protect my escalation of
> privilege attacks from the defenders. I don't want them able to track my
> code versions, and I don't want them knowing the details of my
> exploitation methods so they can add more features to EMET or KAV.

yeah, fuck those guys trying to make my shit fuck them less!


> That's why INNUENDO allows you to put a password in that protects as
> much of your implant deployment package as possible.

i asked a friend, Volatility, and they said "please to re state in
terms of cryptographic digest for code version and instruction
sequence in terms of exploitation method."

because every consideration they pose evaluates to a "as much as
possible" equivalent to zero. there was agreement from VM recording
and bus lane recording, as well.

best regards,




From nymble at gmail.com  Sun Sep 21 22:49:27 2014
From: nymble at gmail.com (nymble)
Date: Sun, 21 Sep 2014 22:49:27 -0700
Subject: [cryptography] RC4 is dangerous in ways not yet known - heads up
 on near injection WPA2 downgrade to TKIP RC4
In-Reply-To: <CAJVRA1Sxg_VJ1JO2G0+fKBfcEdMEJULsrp7-Q_OcmVFHEwza0Q@mail.gmail.com>
References: <CAJVRA1Sxg_VJ1JO2G0+fKBfcEdMEJULsrp7-Q_OcmVFHEwza0Q@mail.gmail.com>
Message-ID: <E8DBBC03-0788-4425-9B6C-D2009007F4E8@gmail.com>


On Sep 15, 2014, at 1:02 AM, coderman <coderman at gmail.com> wrote:

> first and foremost:
> WPA2 does NOT prevent an adversary able to inject packets at you from
> downgrading crypto to flawed RC4. due to odd forgotten legacy protocol
> bits, every implementation of WPA2 that i have tested is vulnerable to
> an active downgrade to TKIP/RC4 while still being "WPA2" and still
> showing all signs of using strongest security settings.

TKIP is NOT the same as RC4 … while we are trying to remove it from
any usage in Wi-FI, it has yet to be fully broken (publicly).

> 
> let me re-iterate: _WPA2 only_ as a setting on router or client device
> does not prevent an active RC4 downgrade when using WPA2. AES-CCMP
… vendors create crappy UIs.  WPA2 only should mean just AES-CCMP.
Some are done correctly.

> must be explicitly checked for, and this is not straightforward in
> end-user configuration or management utilities.
> 
> RECOMMENDATION: use a wireless packet capture utility to specifically
> check for and alert on the presence of TKIP in a WPA2 session. this
> never happens under legitimate circumstances. [if you know of one,
> please tell me!]
YEs/

> 
> TKIP in WPA2 == Active injection attack by "well funded" adversary[0]
Please elaborate.  TKIP has not been identified as a ‘active attack’ vector.

> 
> ---
> 
> i missed the renewed speculation that periodically swirls around RC4, e.g.
> 
> "I feel but cannot prove that the day is coming when we learn that
> everything we ever encrypted with RC4 is very practical to decrypt"
> - https://twitter.com/marshray/status/505586082461655040
> 
> "Kind of annoyed SHA-1 is a "crypto emergency" when most of the web
> was encrypted with RC4 last year and almost no one cared"
> - https://twitter.com/bascule/status/509239990216163330
> 
> "This attack also applies directly to WPA/TKIP, with similar success
> rates, because of its use of per-packet keys for RC4. Here, the
> particular structure of WPA/TKIP keys means that a different set of
> biases are obtained in the first 256 bytes of RC4 keystream... For
> WPA/TKIP, the only reasonable countermeasure is to upgrade to WPA2."
> - http://www.isg.rhul.ac.uk/tls/
> 
> ---
> 
> i have an advisory pending to full-disclosure with details on this
> WPA2 force downgrade to TKIP attack and a rant about Kaminsky's DEF
> CON 22 talk. advisory includes timeline indicating "in the wild"
> discovery of this technique late 2013.  any earlier indications
> welcome!
> 
> to be clear, this issue is with backwards compatibility in WPA2, and
> the manner in which a local attacker (8 miles or more with power and
> directional emission) can force the WPA2 protected session to use
> TKIP/RC4 while appearing to both client and network management
> equipment to be using WPA2 and best security configuration. (not WEP,
> not WPA)
> 
> this is not about how RC4 is broken; i have no idea about the nature
> of the RC4 weaknesses enabling decryption, and this as yet unknown
> attack is certainly more effective than the attack described in
> CVE-2013-2566:
> "The attacks can only be carried out by a determined attacker who can
> generate sufficient sessions for the attacks. They recover a limited
> amount of plaintext. In this sense, the attacks do not pose a
> significant danger to ordinary users of TLS or WPA/TKIP in their
> current form. However, it is a truism that attacks only get better
> with time, and we anticipate significant further improvements to our
> attacks."
> 
> the attacks observed in the wild did not rely on any additional or
> excessive packet creation to reach effectiveness.
> 
> best regards,
> 
> 
> 
> 0. About TKIP with WPA2...
> some tools know that TKIP is backwards compatible in WPA2, having
> written to spec. E.g. airodump-ng: "Not mandatory, but TKIP is
> typically used with WPA and CCMP is typically used with WPA2."
> 
> in my testing i have never seen a device that could do WPA2 but not
> AES-CCMP.
WPA2 is supposed to mean AES-CCMP.  WPA is TKIP.  
Unclear that you know what you are saying ….


nymble


> if you find one i'd like to know about it!  if you ever see
> a device+router pair that used to speak AES-CCMP over WPA2 suddenly
> using TKIP you are under active attack.
> 
> finally, i mention "advanced attacker" because utilizing this
> downgrade also means applying an as yet unknown attack on the RC4
> cipher to decrypt.
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography





From grarpamp at gmail.com  Sun Sep 21 23:55:05 2014
From: grarpamp at gmail.com (grarpamp)
Date: Mon, 22 Sep 2014 02:55:05 -0400
Subject: GoldBug SF projects [was: Bittorrent Bleep]
In-Reply-To: <CAD2Ti2-BgskWH1LXfWVr89vGByu8b1k52VL84vrH3y4ZEWVnoA@mail.gmail.com>
References: <CAD2Ti2-BgskWH1LXfWVr89vGByu8b1k52VL84vrH3y4ZEWVnoA@mail.gmail.com>
Message-ID: <CAD2Ti280QCEBo7maHvt_NkZuf7yt_so8dY45smr5ecV1eGdmAA@mail.gmail.com>

> https://cpunks.org//pipermail/cypherpunks/2014-September/005507.html

Reply in thread please.

> the point was that I would not use bleep messenger from bittorrent, as
> it is not open source.

The point in this particular thread is... that since day one you
and your project developers are ignoring real concerns being raised
about your apparent cluster of projects.

> Others like the one you did a research on might
> be worth for further testings, either by the binaries

> Why don' t you test the binaries?

> 7) Ask a friend [...] to use the binaries: exchange keys,
> and chat. Done. All is encrypted and you never need to exchange keys.

Your repeated classic dodge... suggesting that people run blobs
instead of answering the question.

The 'research' was posted to throw up red flags about these projects
for anyone searching so the can see and form their own opinion.

The world does not need more closed source.
And it does not need more non-reproducible binaries.
ESPECIALLY from software projects claiming to protect users privacy
through encryption, and further enticing the masses to run them by
putting cute little doggies on the tin.

> The source and the binaries might not be machting from hash,
> because if you know source projects, the source might be corrected
> on one or two files even when the binaries have been build.

Fix your code then. Reproducible builds are a MUST for any
security/privacy project like yours.

> So better build the software from source and use your own binaries.
> I would suggest to build the crypto core first, which is spot-on.

> I cannot help you with compile firefloo messenger on linux or
> windows, as I have not done this yet.

I'm not going to waste time attempting to build stuff that apparently
no one but you and or your devs have been able to build. And I'm
not going to waste time disassembling the binaries either.

Post your SHA-256 reproducible build instructions on the wiki's for
your projects. Then ask for build confirmation/review from the
community.


Until you either ...

A) Quit distributing binaries
 or
B) Tell people in a COMPILING doc included in the sources how to
make binaries that SHA-256 match the ones you distribute


 and then

C) Answer why you claimed to be announced/partnered with EFF/CCC
(which they have both denied [1]), why you are continuing to mimic
the Tor homepage/TBB, why you're directly spamming people with
invites, why you are dodging these and other questions, and generally
appearing and acting very unusual for an opensource privacy suite

... no one is going to believe these projects are anything but
untrustworthy snake oil.

Help us help you.

In my opinion at this time, these (your) projects have serious trust
issues and I wouldn't recommend them until resolved.

And while this list isn't perfect or comprehensive, those needing
privacy solutions have other options to choose from here...
https://www.prism-break.org/


License issues...
http://www.gossamer-threads.com/lists/gnupg/users/62118

An example of a decent model announcement and request for review,
that your seeming sockpuppet then replied to with a lure...
https://lists.torproject.org/pipermail/tor-talk/2014-March/032498.html

Old stuff... (RetroShare?)
http://nabble.documentfoundation.org/Instant-Messenger-for-Libre-Office-serverle
ss-and-open-source-td2595287.html
http://comments.gmane.org/gmane.os.haiku.devel/18674

Can anyone provide an overall interpretation in English of posts?
http://moenchengladbach.hopto.org/k/buecher/cd0001/instit/org/Aktion_Grundrechte
/AKV-mailarchiv-2009-201310/author.html
http://moenchengladbach.hopto.org/k/buecher/cd0001/instit/org/Aktion_Grundrechte
/AKV-mailarchiv-2009-201310/26906.html


Ps: To date, none of the people potentially related to these projects
that I previously CC'd seeking comment from have replied either.

[1] Official Comments
EFF:
https://lists.torproject.org/pipermail/tor-talk/2013-July/029129.html
CCC:
Subject: [rt.ccc.de #40481] False press using EFF / CCC? goldbug.sf.net




From tbiehn at gmail.com  Mon Sep 22 07:15:30 2014
From: tbiehn at gmail.com (Travis Biehn)
Date: Mon, 22 Sep 2014 10:15:30 -0400
Subject: salty axolotl
In-Reply-To: <20140920171448.GG11848@ctrlc.hu>
References: <20140920153840.GE11848@ctrlc.hu>
 <CAK9dnSyw1dXhDO8uuJjsQ24B39FWwWECt6vdYNUuxmprw1Xq7w@mail.gmail.com>
 <20140920165306.GF11848@ctrlc.hu> <20140920171448.GG11848@ctrlc.hu>
Message-ID: <CAKtE3zdg+oH03GjHXErQpQ3CnEkrQkRCsp-+DgG5O6hOeKJPjA@mail.gmail.com>

Page 6 of the illustrated primer is better than any ASCII RFC chart I've
ever seen.

http://www.slideshare.net/ChristineCorbettMora/axolotl-protocol-an-illustrated-primer



On Sat, Sep 20, 2014 at 1:14 PM, stef <s at ctrlc.hu> wrote:

> On Sat, Sep 20, 2014 at 06:53:06PM +0200, stef wrote:
> > On Sat, Sep 20, 2014 at 06:43:56PM +0200, CodesInChaos wrote:
> > > Why would you use scrypt for anything except strengthening low entropy
> > > secrets (like passwords)?
>
> reason: i'm stupid, wasn't thinking, and had so far no such valuable
> feedback
> as ours.
>
> > > For high entropy secrets there are much simpler and cleaner
> > > alternatives, such as HKDF.
> >
> > excellent observation. with nacl would generic_hash(master_key,
> some_const, key_size)
> > be sufficient as a kdf?
>
> thank you for this useful feedback! i removed scrypt and replaced it with
> above suggestion. updated on git.
>
> --
> otr fp: https://www.ctrlc.hu/~stef/otr.txt
>



-- 
Twitter <https://twitter.com/tbiehn> | LinkedIn
<http://www.linkedin.com/in/travisbiehn> | GitHub <http://github.com/tbiehn>
| TravisBiehn.com <http://www.travisbiehn.com> | Google Plus
<https://plus.google.com/+TravisBiehn>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 2064 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140922/311afc25/attachment.txt>

From grarpamp at gmail.com  Mon Sep 22 12:33:58 2014
From: grarpamp at gmail.com (grarpamp)
Date: Mon, 22 Sep 2014 15:33:58 -0400
Subject: [tor-talk] Article: Best Alternatives to Tor
In-Reply-To: <54200BF5.6060205@riseup.net>
References: <20140922192903.7a2d901c@localhost.localdomain>
 <CADop2NG7PhNHvmn=PHmTXbTK4YfAka85bxGGg3RkaChFXyN8dg@mail.gmail.com>
 <54200BF5.6060205@riseup.net>
Message-ID: <CAD2Ti284WzWFR_G-j1EV3eOKhQ+PFxrrX54u-ScEyKJiR4Ez1Q@mail.gmail.com>

On Mon, Sep 22, 2014 at 7:45 AM, Colin Mahns <colinmahns at riseup.net> wrote:
> I like how a couple of the alternatives to "Tor" in this article are
> Tails and Whonix. What do they use for anonymity again? Oh yeah, Tor...
>
> They also list Disconnect and Tox as an alternative, and then quickly
> say they aren't alternatives. I'd say this writer was hoping for clickbait.
>>> http://www.idigitaltimes.com/best-alternatives-tor-12-programs-use-nsa-hackers-compromised-tor-project-376976

As mostly a list of OS wrappers around things,
the entries include the usual list of apps:
Tor, I2P, Freenet, JonDo, Tox, Pond, etc.

The list of OS wrappers is typical, but includes
one unique entry... from US Air Force:

Anti-Tamper - Software Protection Initiative: LPS - Lightweight
Portable Security
http://www.spi.dod.mil/lipose.htm

There are some crypto tools and docs on the SPI site and
you can even watch the SPI Show (in Letterman style)...

http://spi.dod.mil/docs/Top_Ten_640x360.wmv




From coderman at gmail.com  Mon Sep 22 16:37:32 2014
From: coderman at gmail.com (coderman)
Date: Mon, 22 Sep 2014 16:37:32 -0700
Subject: [cryptography] RC4 is dangerous in ways not yet known - heads up
 on near injection WPA2 downgrade to TKIP RC4
In-Reply-To: <E8DBBC03-0788-4425-9B6C-D2009007F4E8@gmail.com>
References: <CAJVRA1Sxg_VJ1JO2G0+fKBfcEdMEJULsrp7-Q_OcmVFHEwza0Q@mail.gmail.com>
 <E8DBBC03-0788-4425-9B6C-D2009007F4E8@gmail.com>
Message-ID: <CAJVRA1T6yTnfUX9__ZV1XV2OFgCuX1_Y=A+ryAeSnaO2OD1sEg@mail.gmail.com>

On 9/21/14, nymble <nymble at gmail.com> wrote:
> ...
> TKIP is NOT the same as RC4 … while we are trying to remove it from
> any usage in Wi-FI, it has yet to be fully broken (publicly).

agreed.



> Please elaborate.  TKIP has not been identified as a ‘active attack’
> vector.

if TKIP is optional in WPA2, and yet must be implemented in WPA2 [0]
 and, attacker is able to inject EAPOL in one or both directions, some
of the time
  then, attacker can force TKIP in a "WPA2 protected session" visibly
identical to the user as desired AES-CCMP WPA2 mode. " [1]
    and attacker can force WPA2-TKIP regardless of the WPA disable,
and TKIP disable options set in client or access point, which all
appear to set advertised preferences, not absolute capabilities, at
the radio level.

consider the following states, which may be influenced by injecting attacker:
access point WPA2-TKIP disable + client WPA2-TKIP requested
access point WPA2-TKIP requested + client WPA2-TKIP disable
access point WPA2-TKIP disable + client WPA2-TKIP disable (able to
silent transition? bug on top of bug) [2]

if any of these end up in WPA2 TKIP for a given hardware pair, it is a problem.

we have problems.


best regards,


to be specific about the problems, in case not concise enough above:
0. lack of a way to enforce TKIP disable.
1. lack of visual signal of TKIP downgraded security in WPA2 to users.
2. insult to injury with "unspecified" bozofail TKIP transition to ON
flaws in some hw.




From coderman at gmail.com  Mon Sep 22 17:05:17 2014
From: coderman at gmail.com (coderman)
Date: Mon, 22 Sep 2014 17:05:17 -0700
Subject: SENTER Sandman: Using Intel TXT to Attack BIOSes - request for slides
 / transcript
Message-ID: <CAJVRA1QS=e3nZTW=ApbxY3WrTEXav8qny9RC4q-S9OWQzFCcAA@mail.gmail.com>

anyone have details on:

SENTER Sandman: Using Intel TXT to Attack BIOSes
 - http://2014.hack.lu/index.php/List#Xeno_Kovah.2C_Corey_Kallenberg.2C_John_Butterworth.2C_Sam_Cornwell_-_SENTER_Sandman:_Using_Intel_TXT_to_Attack_BIOSes
"""
At CanSecWest 2014 we presented the first prototype of Copernicus 2, a
trustworthy BIOS capture system. It was undertaken specifically to
combat our “Smite’em the Stealthy” PoC which can forge the BIOS
collection results from all other systems (including our own
Copernicus 1, the open source Flashrom, Intel Chipsec, etc).
Copernicus 2 makes use of the open source Flicker project from Jon
McCune of CMU which utilizes Intel Trusted Execution Technology in
order to build a trustworthy environment from which to run our BIOS
measurement code. We specifically chose TXT because it has the ability
to disable System Management Interrupts (SMIs) effectively putting the
SMM MitM, Smite’em, to sleep.

But if you’ve been following our work (specifically “Defeating Signed
BIOS Enforcement” and “Setup for Failure: Defeating UEFI SecureBoot”)
you will have seen that we have two other attacks where we leverage
the ability to suppress SMIs to break into some BIOSes. Thus the
Sandman cometh! We will explain how we could implement the PoC Sandman
attack using the same infrastructure as Copernicus 2. We will also
explain what can be done against this kind of attack, and how the
latest Copernicus 2 attempts to prevent opening the door to the
Sandman. We will also cover how Copernicus 1 and 2 can check for the
problems with BIOSes that make SMI-suppression attacks feasible, how
to tell if you’re vulnerable, and what you may be able to do about it.
"""




From grarpamp at gmail.com  Mon Sep 22 17:59:41 2014
From: grarpamp at gmail.com (grarpamp)
Date: Mon, 22 Sep 2014 20:59:41 -0400
Subject: GoldBug SF projects [was: Bittorrent Bleep]
In-Reply-To: <CADS43vCD_k0-wZ7skCsqG98vbW3Vn7Fnt4cUVzawTa0n1tSzOg@mail.gmail.com>
References: <CAD2Ti2-BgskWH1LXfWVr89vGByu8b1k52VL84vrH3y4ZEWVnoA@mail.gmail.com>
 <CAD2Ti280QCEBo7maHvt_NkZuf7yt_so8dY45smr5ecV1eGdmAA@mail.gmail.com>
 <CADS43vCD_k0-wZ7skCsqG98vbW3Vn7Fnt4cUVzawTa0n1tSzOg@mail.gmail.com>
Message-ID: <CAD2Ti28iDxVpbCFAO0RKiKRHv-bg9sdowzK6Y0FvD5tdWT6DZw@mail.gmail.com>

On Mon, Sep 22, 2014 at 3:12 AM, Bernd Stramm <bernd.stramm at gmail.com> wrote:
> To the extent that linux versions of these projects are available, I put
> them in the opensuse build system.
> From there you can get RPMs, and a few DEBs, including the source versions.
> OBS signs them.

If I wanted to try Unix/OBS versions I would. And I might if these
issues are ever resolved and they are picked up and looked at by
more Unix's.

> So quit whining

I'm defending users who might be considering running the binaries
you distribute. As far as I can tell, no one has ever been able to
reproduce them from your sources. And you haven't posted sufficient
details about your platform to make whatever compilation notes you
posted worthwhile. "32 bit windows" could be anything.

I also can't find OpenPGP signatures for the binaries or the sources
that you distribute.

Nor can I find a reply from you or "Mike Weber" or anyone else
regarding all these issues.

> If you use windows, it is your own fault.

So if I use the source without blobs I'm safe, but if I use your
windows binaries I'm rooted? Or should this mean that you know
windows sucks but you're writing to it anyways, and perhaps you
don't care much about the implementation quality there.





Now because you're a member of GoldBug Messenger on SF...

/ http://lists.gnupg.org/pipermail/gnupg-users/2013-July/047137.html
/ "[Today ...] the EFF in conjunction with the Chaos Computer Club announced a
/ new secure Instant Messenger called: GoldBug.sf.net (http://goldbug.sf.net)"

Are you suggesting that users ignore the falsehood you put in your
announcements and just trust your software?

(Is that what all those anonymous 5-star 1-review posts of GoldBug
to mostly second and third class windows software aggregator sites
are about... building trust? You can google for those.)

Or are you saying that you somehow forgot to post your own project
denial of Randolph / Thomas posting as if they were associated with
your projects?

Ok, well maybe you did forget that, so let's see who has control...

Currently:
http://sourceforge.net/projects/goldbug/
"Brought to you by: berndhs, mikeweber"

... and what they do with that control...

/ http://lists.gnupg.org/pipermail/gnupg-users/2013-July/047137.html

This gnupg thread also shows two other witnesses to...

/ "a review on sourceforge which indicates that the CCC has no idea
/ of it"

/ "... I also note that about 30 minutes ago, a representative of the Chaos
/ Computer Club (CCC) posted a one-star review of GoldBug in which he said
/ that CCC had never heard of GoldBug, despite GoldBug claiming to be
/ associated with CCC.
/
/ About five minutes ago the GoldBug project admin disabled reviews and
/ the one-star review is no longer visible.
/
/ This kind of behavior on the part of the GoldBug project leaders is
/ deeply irresponsible.  This, by itself, should persuade people to not
/ use it.  Responsible programmers *welcome* criticism -- we don't
/ suppress it."

Currently:
http://sourceforge.net/projects/goldbug/reviews
"This project does not allow reviews to be posted."


Now of course back then "Mike Weber" may have been the only one in
the SF GB project, plus the apparent, in my opinion, shills Thomas
and Randolph.

However, you are now also on the SF GB project since at least Oct 26 2013.
https://web.archive.org/web/20131004145711/http://sourceforge.net/projects/goldbug/
https://web.archive.org/web/20131026004244/http://sourceforge.net/projects/goldbug/

So lets see if your project has improved its behaviour since pointed
out by people on gnupg list in Jul 2013... no it hasn't.
To wit: Your project just censored my post and turned on list
moderation so that no one else can speak. Oopsie, footshot ;-)

https://web.archive.org/web/20140922090221/http://sourceforge.net/p/goldbug/mailman/goldbug-forum/
https://web.archive.org/web/20140922201304/http://sourceforge.net/p/goldbug/mailman/goldbug-forum/
http://sourceforge.net/p/goldbug/mailman/goldbug-forum/
"1 message has been excluded from this view by a project administrator."
14 out of 15 posts.
"Your mail to 'GoldBug-Forum' ... is being held ... Post to moderated list"


So the question now begs, with you being fully aware, and perhaps
even complicit... why do you remain associated with projects that
have serious issues? If you choose to remain, you definitely need
to get "Mike", and you, to post an answer on this stuff. And if you
choose to leave, an exit statement from you would surely serve you
well as a possible member of the FOSS/Suse community.


> So quit whining

As long as all these questions remain unanswered, I will not quit
defending users, or the names of Tor, EFF, CCC.


Last minute additions...

# These two addresses are '550 user unknown' ...
 berndhs at users.sourceforge.net
 mikeweber at users.sourceforge.net
# A story about one particular Michael Weber
http://www.businessinsider.com/swiss-software-developer-bitcoin-2014-4
# Another email found
spot-on and dooble - "Alexis Megas" - textbrowser at gmail.com, textfield at us...
# They uncensored my post to their list (second in this thread),
# but have not yet approved my first from this thread, or possibly
# this third post.
http://sourceforge.net/p/goldbug/mailman/goldbug-forum/
# I'm aware of no replies other than Bernd above.


Maybe for Goldbug et al it's all about the cute puppies...

/ http://lists.gnupg.org/pipermail/gnupg-users/2013-July/047137.html
/ "Some net communities already call it the 'Neuland Messenger' due to
/ the Font Name of the Logo."

Really, they do call it that? Well shoot your foot again, seems
that phrase has no applicable google search results on the net other
than your own announcement and a ...

http://www.infodog.com/RESULTS/brdrsl.htm?evno=2000110102&bno=31800
 "Bern"ese mountain show dog.


You silly "novice bitches", hopefully the twitters will have their
way with you and your apparently bogus projects too.

https://twitter.com/GoldBugIM

Bye bye.




From dal at riseup.net  Mon Sep 22 20:50:39 2014
From: dal at riseup.net (Douglas Lucas)
Date: Mon, 22 Sep 2014 22:50:39 -0500
Subject: Where's a human-like randomizer?
Message-ID: <5420EE0F.8010004@riseup.net>

I've an odd question. Is there a program that will generate passwords
that imitate the badness with which humans armed with pen and paper only
would generate randomness? No, not a program that spits out "password"
over and over, that contemptible most frequently used password; I'm
imagining an English speaker of above average intelligence who has some
familiarity with best practices for coming up with passwords, but who's
no mathematical crypto wizard or anything.

Imagine a human who wants to generate an alphanumeric passphrase with
both upper- and lowercase, and he's in a jail cell with just pen and
paper. So he has a set of 62 characters to work with, and he tries to
write out a truly random password. But maybe he puts "M" in the password
too often for it to be truly random, because his name is Mario, so he
thinks about "M" unusually often; or maybe his writing surface is shaped
such that it incentivizes long downstrokes, so he pens the letter "l"
too often for true randomness.

Now, has anyone created a computer program to MIMIC what that human
would come up with? Is such a thing possible? Obviously I could simply
do it myself as a human being by, you know, qrMt8x3, but I want a
program that will create that for an x-long, say, 80,000 character-long,
string.








From cpunks at martin-studio.com  Mon Sep 22 23:04:26 2014
From: cpunks at martin-studio.com (Anthony Martin)
Date: Mon, 22 Sep 2014 23:04:26 -0700
Subject: Where's a human-like randomizer?
In-Reply-To: <5420EE0F.8010004@riseup.net>
References: <5420EE0F.8010004@riseup.net>
Message-ID: <CAGJCD36ATRmS-G7pX3=Xqw55FtgETYao24X_2n8qeK07EY-=-w@mail.gmail.com>

I think you could generate truly random passwords first, then corrupt them
into less random passwords with a few regex passes

On Monday, September 22, 2014, Douglas Lucas <dal at riseup.net> wrote:

> I've an odd question. Is there a program that will generate passwords
> that imitate the badness with which humans armed with pen and paper only
> would generate randomness? No, not a program that spits out "password"
> over and over, that contemptible most frequently used password; I'm
> imagining an English speaker of above average intelligence who has some
> familiarity with best practices for coming up with passwords, but who's
> no mathematical crypto wizard or anything.
>
> Imagine a human who wants to generate an alphanumeric passphrase with
> both upper- and lowercase, and he's in a jail cell with just pen and
> paper. So he has a set of 62 characters to work with, and he tries to
> write out a truly random password. But maybe he puts "M" in the password
> too often for it to be truly random, because his name is Mario, so he
> thinks about "M" unusually often; or maybe his writing surface is shaped
> such that it incentivizes long downstrokes, so he pens the letter "l"
> too often for true randomness.
>
> Now, has anyone created a computer program to MIMIC what that human
> would come up with? Is such a thing possible? Obviously I could simply
> do it myself as a human being by, you know, qrMt8x3, but I want a
> program that will create that for an x-long, say, 80,000 character-long,
> string.
>
>
>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 1886 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140922/4b39b730/attachment.txt>

From grarpamp at gmail.com  Tue Sep 23 13:19:18 2014
From: grarpamp at gmail.com (grarpamp)
Date: Tue, 23 Sep 2014 16:19:18 -0400
Subject: GoldBug SF projects [was: Bittorrent Bleep]
In-Reply-To: <CAD2Ti28iDxVpbCFAO0RKiKRHv-bg9sdowzK6Y0FvD5tdWT6DZw@mail.gmail.com>
References: <CAD2Ti2-BgskWH1LXfWVr89vGByu8b1k52VL84vrH3y4ZEWVnoA@mail.gmail.com>
 <CAD2Ti280QCEBo7maHvt_NkZuf7yt_so8dY45smr5ecV1eGdmAA@mail.gmail.com>
 <CADS43vCD_k0-wZ7skCsqG98vbW3Vn7Fnt4cUVzawTa0n1tSzOg@mail.gmail.com>
 <CAD2Ti28iDxVpbCFAO0RKiKRHv-bg9sdowzK6Y0FvD5tdWT6DZw@mail.gmail.com>
Message-ID: <CAD2Ti2-pKewLHXtOEHpN_Y44h_dFgBBcbVoKzkAENKrytEBizA@mail.gmail.com>

Additional links, threads and updates...

No replies came to me except for:
- One further note of no particular substance from Bernd.
- One thank you for exposing things further. Thanks :)


On tor-talk: TPO/TBB clone on SourceForge, use of TPO name
https://lists.torproject.org/pipermail/tor-talk/2014-September/034930.html
https://trac.torproject.org/projects/tor/ticket/11515
https://docs.google.com/spreadsheet/ccc?key=0AqtQ4kKC2rLzdEVjWkxTcUVTTWxmdnh4VWFDY25zTHc

On Wikipedia:
http://en.wikipedia.org/wiki/User_talk:MarcoSU
http://en.wikipedia.org/wiki/Special:Contributions/MarcoSU

Attn czarkoff: Background threads for reference in your wikipedia work
https://cpunks.org/pipermail/cypherpunks/2014-September/thread.html
https://cpunks.org/pipermail/cypherpunks/2014-September/005505.html

keywords: goldbug messenger, firefloo communicator, lib spot-on, echo
protocol, cassiopeia bitmail, dooble web browser, interface social
network




From grarpamp at gmail.com  Tue Sep 23 15:51:20 2014
From: grarpamp at gmail.com (grarpamp)
Date: Tue, 23 Sep 2014 18:51:20 -0400
Subject: GoldBug SF projects [was: Bittorrent Bleep]
In-Reply-To: <20140923205009.GA21133@e325.my.domain>
References: <CAD2Ti2-BgskWH1LXfWVr89vGByu8b1k52VL84vrH3y4ZEWVnoA@mail.gmail.com>
 <CAD2Ti280QCEBo7maHvt_NkZuf7yt_so8dY45smr5ecV1eGdmAA@mail.gmail.com>
 <CADS43vCD_k0-wZ7skCsqG98vbW3Vn7Fnt4cUVzawTa0n1tSzOg@mail.gmail.com>
 <CAD2Ti28iDxVpbCFAO0RKiKRHv-bg9sdowzK6Y0FvD5tdWT6DZw@mail.gmail.com>
 <CAD2Ti2-pKewLHXtOEHpN_Y44h_dFgBBcbVoKzkAENKrytEBizA@mail.gmail.com>
 <20140923205009.GA21133@e325.my.domain>
Message-ID: <CAD2Ti29H8hf6+QiU_+HtBrH0eBD1qpbgMjeZ9Ww-_m714Gu+OQ@mail.gmail.com>

On Tue, Sep 23, 2014 at 4:50 PM, Dmitrij D. Czarkoff <czarkoff at gmail.com> wrote:
> Hi!
>
>> Attn czarkoff: Background threads for reference in your wikipedia work
>> https://cpunks.org/pipermail/cypherpunks/2014-September/thread.html
>> https://cpunks.org/pipermail/cypherpunks/2014-September/005505.html
>>
>> keywords: goldbug messenger, firefloo communicator, lib spot-on, echo
>> protocol, cassiopeia bitmail, dooble web browser, interface social
>> network
>
> I am not sure how I can help here.

In those threads and links following from the above are people
showing that these 'goldbug' related projects have serious trust
issues and may be some form of malware/crapware. Read the
linked threads for more info.

If you search around wikipedia for these projects and
look at their edit, talk and contributor histories you can
find their edit trails there. Bogus listings is their way of
free advertising and luring gullible users to them.

I don't know much about how these things are handled within
wikipedia community. But I have seen articles that have
'Controversy' sections in them.

So if I were an editor I'd add exactly such a controversy section
to all the pages... that some people see big issues with these
projects. And back it up with links out to these threads on the
cpunks, gnupg, and tor lists. At least that way it's on wikipedia
history for people to see.

http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/GoldBug_(software)
http://en.wikipedia.org/wiki/Draft:GoldBug_(software)
http://en.wikipedia.org/wiki/GoldBug_(Instant_Messenger)
http://en.wikipedia.org/wiki/Echo_(communications_protocol)

Saw your arguments on the deletion page and figured
you would like to be aware of these issues as well.




From rysiek at hackerspace.pl  Tue Sep 23 14:06:11 2014
From: rysiek at hackerspace.pl (rysiek)
Date: Tue, 23 Sep 2014 23:06:11 +0200
Subject: GoldBug SF projects [was: Bittorrent Bleep]
In-Reply-To: <CAD2Ti2-pKewLHXtOEHpN_Y44h_dFgBBcbVoKzkAENKrytEBizA@mail.gmail.com>
References: <CAD2Ti2-BgskWH1LXfWVr89vGByu8b1k52VL84vrH3y4ZEWVnoA@mail.gmail.com>
 <CAD2Ti28iDxVpbCFAO0RKiKRHv-bg9sdowzK6Y0FvD5tdWT6DZw@mail.gmail.com>
 <CAD2Ti2-pKewLHXtOEHpN_Y44h_dFgBBcbVoKzkAENKrytEBizA@mail.gmail.com>
Message-ID: <2738320.0fRSD4ICgg@lapuntu>

Dnia wtorek, 23 września 2014 16:19:18 grarpamp pisze:
> Additional links, threads and updates...
> 
> No replies came to me except for:
> - One further note of no particular substance from Bernd.
> - One thank you for exposing things further. Thanks :)

Here's another one of these: thanks a lot. The whole thread is very 
informative.

> (...)
> 
> keywords: goldbug messenger, firefloo communicator, lib spot-on, echo
> protocol, cassiopeia bitmail, dooble web browser, interface social
> network

Whoa, some nice bullshit bingo right there! ;)

-- 
Pozdr
rysiek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 411 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140923/fdab593e/attachment.sig>

From lists at infosecurity.ch  Wed Sep 24 00:38:54 2014
From: lists at infosecurity.ch (Fabio Pietrosanti (naif))
Date: Wed, 24 Sep 2014 09:38:54 +0200
Subject: GoldBug SF projects [was: Bittorrent Bleep]
In-Reply-To: <CAD2Ti29H8hf6+QiU_+HtBrH0eBD1qpbgMjeZ9Ww-_m714Gu+OQ@mail.gmail.com>
References: <CAD2Ti2-BgskWH1LXfWVr89vGByu8b1k52VL84vrH3y4ZEWVnoA@mail.gmail.com>
 <CAD2Ti280QCEBo7maHvt_NkZuf7yt_so8dY45smr5ecV1eGdmAA@mail.gmail.com>
 <CADS43vCD_k0-wZ7skCsqG98vbW3Vn7Fnt4cUVzawTa0n1tSzOg@mail.gmail.com>
 <CAD2Ti28iDxVpbCFAO0RKiKRHv-bg9sdowzK6Y0FvD5tdWT6DZw@mail.gmail.com>
 <CAD2Ti2-pKewLHXtOEHpN_Y44h_dFgBBcbVoKzkAENKrytEBizA@mail.gmail.com>
 <20140923205009.GA21133@e325.my.domain>
 <CAD2Ti29H8hf6+QiU_+HtBrH0eBD1qpbgMjeZ9Ww-_m714Gu+OQ@mail.gmail.com>
Message-ID: <5422750E.2070104@infosecurity.ch>

Il 9/24/14, 12:51 AM, grarpamp ha scritto:
> Saw your arguments on the deletion page and figured you would like to
> be aware of these issues as well. 

Time has come, after few years of such very likely malicious/suspicious
activities, we have to strike back.

Kudos moritz!

Is it worth  making a small website to clearly put all of those
information in a collaborative way, published online?

The only way such "suspicious" projects will have to recover is by being
transparent on who they are, who pay them, what's their goal ;)

-- 
Fabio Pietrosanti (naif)
HERMES - Center for Transparency and Digital Human Rights
http://logioshermes.org - http://globaleaks.org - http://tor2web.org




From rysiek at hackerspace.pl  Wed Sep 24 09:25:26 2014
From: rysiek at hackerspace.pl (rysiek)
Date: Wed, 24 Sep 2014 18:25:26 +0200
Subject: GoldBug SF projects [was: Bittorrent Bleep]
In-Reply-To: <5422750E.2070104@infosecurity.ch>
References: <CAD2Ti2-BgskWH1LXfWVr89vGByu8b1k52VL84vrH3y4ZEWVnoA@mail.gmail.com>
 <CAD2Ti29H8hf6+QiU_+HtBrH0eBD1qpbgMjeZ9Ww-_m714Gu+OQ@mail.gmail.com>
 <5422750E.2070104@infosecurity.ch>
Message-ID: <1894801.e4hldsv2ig@lapuntu>

Dnia środa, 24 września 2014 09:38:54 Fabio Pietrosanti pisze:
> Il 9/24/14, 12:51 AM, grarpamp ha scritto:
> > Saw your arguments on the deletion page and figured you would like to
> > be aware of these issues as well.
> 
> Time has come, after few years of such very likely malicious/suspicious
> activities, we have to strike back.
> 
> Kudos moritz!
> 
> Is it worth  making a small website to clearly put all of those
> information in a collaborative way, published online?
> 
> The only way such "suspicious" projects will have to recover is by being
> transparent on who they are, who pay them, what's their goal ;)

How about putting all this, with sources, on this project's WikiPedia page? 
Seriously, there is no better place for it. :)

-- 
Pozdr
rysiek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 411 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140924/dca61d06/attachment.sig>

From grarpamp at gmail.com  Thu Sep 25 00:39:24 2014
From: grarpamp at gmail.com (grarpamp)
Date: Thu, 25 Sep 2014 03:39:24 -0400
Subject: GoldBug SF projects [was: Bittorrent Bleep]
In-Reply-To: <CAD2Ti2-pKewLHXtOEHpN_Y44h_dFgBBcbVoKzkAENKrytEBizA@mail.gmail.com>
References: <CAD2Ti2-BgskWH1LXfWVr89vGByu8b1k52VL84vrH3y4ZEWVnoA@mail.gmail.com>
 <CAD2Ti280QCEBo7maHvt_NkZuf7yt_so8dY45smr5ecV1eGdmAA@mail.gmail.com>
 <CADS43vCD_k0-wZ7skCsqG98vbW3Vn7Fnt4cUVzawTa0n1tSzOg@mail.gmail.com>
 <CAD2Ti28iDxVpbCFAO0RKiKRHv-bg9sdowzK6Y0FvD5tdWT6DZw@mail.gmail.com>
 <CAD2Ti2-pKewLHXtOEHpN_Y44h_dFgBBcbVoKzkAENKrytEBizA@mail.gmail.com>
Message-ID: <CAD2Ti295eczCXS_7DxQX6K5f5=ZznBTuWfzHUfN7_GhnxPmfTw@mail.gmail.com>

On Tue, Sep 23, 2014 at 4:19 PM, grarpamp <grarpamp at gmail.com> wrote:
> Additional links, threads and updates...

Found a new shill using their classic style to push GoldBug
messenger. Here's the thread...
https://mailman.boum.org/pipermail/tails-dev/2014-July/006326.html
darkd0 at unseen.is


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728669
Debian should probably include this cpunks thread in any
decision process regarding importing the softwares noted
herein into debian.




From bluelotus at openmailbox.org  Thu Sep 25 15:18:44 2014
From: bluelotus at openmailbox.org (bluelotus at openmailbox.org)
Date: Thu, 25 Sep 2014 18:18:44 -0400
Subject: Offering free firmware rootkits perhaps even badBIOS
Message-ID: <509a1f5376f144106d9159547efcfd37@openmailbox.org>

Want firmware rootkits, probably more sophisticated than FinFisher's, 
probably BadBiOS, emailed to you?

Hidden .mp3 and ID3 tag embedded in .exif in photos I took. Clicking on 
the photos does not produce audible sound. Is audio ultrasound?
http://www.reddit.com/r/badBIOS/comments/2hd3ia/is_hidden_mp3_in_hidden_exif_in_jpg_streaming/

JavaScript block, multiple objects, multiple stream objects, OpenAction 
and JFIF in documents that I scanned into PDF.
http://www.reddit.com/r/badBIOS/comments/2gzbt6/infected_music_other_objects_embedded_in_pdf_files/

Malware hiding in revisions, OLE2 streams and null characters after the 
end of file of doc files I had created. Null characters after the end of 
file of tiff files.
http://www.reddit.com/r/badBIOS/comments/2h91bb/ole2_streams_in_doc_files_and_malicious_null/

I removed ID3 tags from music. Hackers concealed reinserting ID3 tags.
http://www.reddit.com/r/badBIOS/comments/2h6nuk/hidden_infected_id3_tags_in_music/




From zen at freedbms.net  Thu Sep 25 06:53:20 2014
From: zen at freedbms.net (Zenaan Harkness)
Date: Thu, 25 Sep 2014 23:53:20 +1000
Subject: GoldBug SF projects [was: Bittorrent Bleep]
In-Reply-To: <CAD2Ti295eczCXS_7DxQX6K5f5=ZznBTuWfzHUfN7_GhnxPmfTw@mail.gmail.com>
References: <CAD2Ti2-BgskWH1LXfWVr89vGByu8b1k52VL84vrH3y4ZEWVnoA@mail.gmail.com>
 <CAD2Ti280QCEBo7maHvt_NkZuf7yt_so8dY45smr5ecV1eGdmAA@mail.gmail.com>
 <CADS43vCD_k0-wZ7skCsqG98vbW3Vn7Fnt4cUVzawTa0n1tSzOg@mail.gmail.com>
 <CAD2Ti28iDxVpbCFAO0RKiKRHv-bg9sdowzK6Y0FvD5tdWT6DZw@mail.gmail.com>
 <CAD2Ti2-pKewLHXtOEHpN_Y44h_dFgBBcbVoKzkAENKrytEBizA@mail.gmail.com>
 <CAD2Ti295eczCXS_7DxQX6K5f5=ZznBTuWfzHUfN7_GhnxPmfTw@mail.gmail.com>
Message-ID: <CAOsGNSQ5EhA6mSOJpG366h7cgN9eVqwofPLQxHUfjjV9VKg_hQ@mail.gmail.com>

(On list this time sorry.)

On 9/25/14, grarpamp <grarpamp at gmail.com> wrote:
> On Tue, Sep 23, 2014 at 4:19 PM, grarpamp <grarpamp at gmail.com> wrote:
>> Additional links, threads and updates...
>
> Found a new shill using their classic style to push GoldBug
> messenger. Here's the thread...
> https://mailman.boum.org/pipermail/tails-dev/2014-July/006326.html
> darkd0 at unseen.is
>
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728669
> Debian should probably include this cpunks thread in any
> decision process regarding importing the softwares noted
> herein into debian.

I think posting is open (no subscription required). I am not able to
do so due to my sort-of not-so subtle suggestions regarding Debian's
heavy handed CoC (Code of Conduct) application, which sadly caused
said heavy handed CoC application to be applied to me.
So if you're offended by such things, don't read my .sig.

So perhaps someone else can send an email to that bug report to link
this thread. It's pretty easy to do so.

Cheers,
Zenaan

-- 
Banned for life from Debian, for suggesting Debian's CoC
is being swung in our faces a little too vigorously.




From bascule at gmail.com  Fri Sep 26 19:05:10 2014
From: bascule at gmail.com (Tony Arcieri)
Date: Fri, 26 Sep 2014 19:05:10 -0700
Subject: Informing the user they have the wrong key
Message-ID: <CAHOTMVLTD27CCgUZOipr1+ERjpuYz2vX=ymP5rh6GXUucgm7Rw@mail.gmail.com>

If we build fancy systems to detect things like misadvertised keys or MitM
attacks, how can we reasonably inform an end user what is amiss in an
actionable way that won't confuse them with too many false positives to
avoid taking action when something bad actually happens?

I recently went to SOUPS and saw a number of presentations on the general
difficulty of communicating security-actionable information to users. From
what I saw I'd say the problem is twofold:

1) How does the system provide a high confidence level that when it tries
to communicate a security-actionable event, it's fairly certain it's not a
false positive? False positives condition users to ignore security warnings

2) How do you express what's happening to the user in such a way that they
will actually take action on it and not just click-through dismiss it?

Given the wide-ranging number of scenarios, the answer will of course be
contextual, and I'd be curious to hear any replies about how systems try to
solve the "right key" user experience problem in general.

That said, the messaging use-case (in conjunction with a "key directory"
system) is particularly interesting to me.

If an end-to-end encrypted messaging system which relies on a
centrally-managed key directory (e.g. iMessage) were to by coersion or
compromise publish a poison key to their directory to facilitate a MitM
attack, but the system creators wanted to make such action obvious to their
users, how can the systems reasonably detect and reflect this in such a way
that such users aren't conditioned to ignore such alerts for routine events
(e.g. the SSH "SOMETHING NASTY" message) and actually feel compelled to
take action on that knowledge?

And then what? How can we help someone who is a victim of an attack like
this actually compile all of the necessary information for someone to
figure out what actually happened? How can encryption tools compile
incident reports that experts can scrutinize to determine what happened?

-- 
Tony Arcieri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 2317 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140926/27b2b608/attachment.txt>

From hozer at hozed.org  Sat Sep 27 09:03:04 2014
From: hozer at hozed.org (Troy Benjegerdes)
Date: Sat, 27 Sep 2014 11:03:04 -0500
Subject: bashing your head against nation-state social engineering
Message-ID: <20140927160304.GC1755@nl.grid.coop>

the recent bash exploit seems to have all the hallmarks of a sophisticated
nation-state attempt to insert backdoors into debian and lots of embedded
devices.

Any thoughts? How do you defend against an adversary that uses social
engineering and psychology to convince developers to add a new feature to an
'essential' package that can then be exploited?

To any of you in the NSA and NNSA with clearances, here's a question for
you: how many US government systems have bash installed, and can your admins
running the world's largest supercomputers run them without having a pre-loaded
exploit train pre-installed?

This is like the mother-of-all advanced persistent threats, so it would be a
good idea to figure out a way for those of you might know, but can't publicly
disclose to figure out how to let the rest of us know how to defend against
this.

Maybe DARPA will post some interesting new RFPs?

-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer at hozed.org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash




From tbiehn at gmail.com  Sat Sep 27 11:48:24 2014
From: tbiehn at gmail.com (Travis Biehn)
Date: Sat, 27 Sep 2014 14:48:24 -0400
Subject: bashing your head against nation-state social engineering
In-Reply-To: <CAHWD2rKUxNKtXgQ8VtvW9_L4XcXKxrRXaCVF+fZiH9_o2jE3Ug@mail.gmail.com>
References: <20140927160304.GC1755@nl.grid.coop>
 <CAHWD2rKUxNKtXgQ8VtvW9_L4XcXKxrRXaCVF+fZiH9_o2jE3Ug@mail.gmail.com>
Message-ID: <CAKtE3zcZ9LuBKvJnFm_RJ3te=MotchXXDioJa17291uHUvFJFg@mail.gmail.com>

I'm partial to Joanna Rutkowska's statement that "Security by Isolation" is
the best course followed for -users- of software. [in addition to all the
patching and whatever.]

Developers of that software, ultimately, are responsible for securing their
stuff. As an aside - separating your complex system into multiple trust
zones, from a development standpoint, is de-rigueur for secure design.

Security heads have long been decrying cgi-bin. Most of the reason is that
the threat surface is insane - for binaries you have user input that's not
running in some sort of VM [php,perl,ruby,node.js, etc] and existing in
memory entangled with executable instructions.

Injection attacks, are, of course old-hat. The daemons could have done some
hand-holding in this respect before passing off headers to ENV variables.

The issue is that 'restricted chars' wasn't defined by a standard interface
between daemon and cgi-bin script. The called function has a completely
arbitrary set of restricted chars.
/bin/bash, of course, isn't written to withstand env attacks - since the
calling user controls the env / and bash is executed under that user's
privileges.
So it is, of a matter of course, inevitable to find vulnerability there.
With one process isolating the client from the env, modifying the env as a
result of the user's whims and then passing off to a sub-process that
trusts the env implicitly.

It is very unlikely that any TLA 'created' this vulnerability. The notion
is entirely incredible. The existence of vulnerability in such a design is
immediately obvious from anyone who takes more than a cursory look at it.
That isn't to say that this specific attack was trivial to identify - that
is to say from an architecture standpoint it should be evident that the
handoff between httpd and cgi-bin is a location of extreme vulnerability.

On a related note: Mirage OS looks like it's on a promising tack:
http://www.xenproject.org/developers/teams/mirage-os.html

-Travis

On Sat, Sep 27, 2014 at 12:49 PM, Lodewijk andré de la porte <l at odewijk.nl>
wrote:

> Know what you code, and what you run. Don't be fooled by words and shapes,
> code does what code does, that is all.
>
> We seriously need a way to detach code from mental models to expose hidden
> features. Basically, all computer law is rubbish because everything you run
> on your computer, exploits and all, is something you run by choice. But
> there's no way you could validate the sheer bulk of code. If you want to
> really solve security flaws it'll involve somehow validating the
> possibilities of the code run.
>
> It's a discipline that touches on visualization, automated testing and
> simplification. Simplification meaning, reducing possible states and
> "execution paths". And just making code easier to comprehend.
>
> The problem is that there's either no market for "truly secure" computing,
> or there's just nobody filling the gap. Banks with their Cobol are laughed
> at, mostly, and accused of lacking innovation. They do lack innovation in
> the technical field. And Cobol is definitely not an ideal language. But
> "truly secure" is worth a lot to them. L4 validated is a step in the right
> direction, but catches a lot of wind saying it's still imperfect and
> therefore worthless.
>
> I'm utterly bored by code review. Maybe it'd be better if there were some
> nicer tools to help out. I'm really sure someone has great recommendations
> regarding this. (That don't even require Cobol :)
>



-- 
Twitter <https://twitter.com/tbiehn> | LinkedIn
<http://www.linkedin.com/in/travisbiehn> | GitHub <http://github.com/tbiehn>
| TravisBiehn.com <http://www.travisbiehn.com> | Google Plus
<https://plus.google.com/+TravisBiehn>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 4889 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140927/fb6add10/attachment.txt>

From ban at unseen.is  Sat Sep 27 09:43:22 2014
From: ban at unseen.is (ban at unseen.is)
Date: Sat, 27 Sep 2014 16:43:22 +0000
Subject: Torrent of Cryptome archive 2014-06-02 (22GB)
Message-ID: <e2387c3c6be68c670ef4a5a7ceb9ba84@unseen.is>

https://thepiratebay.se/torrent/11113511/Cryptome_archive_2014-06-02

# Cryptome Archive from 2 June 2014
magnet:?xt=urn:btih:F5763EB5C5FFD8B40B9047CF72350D320A59BDAC&dn=cryptome-archive-2014-06-02&tr=udp%3a%2f%2ftracker.istole.it%3a80
https://zoink.it/torrent/F5763EB5C5FFD8B40B9047CF72350D320A59BDAC.torrent

#Donate to John from Cryptome.org for collecting this files:
http://www.cryptome.org/donations.htm

#This is the Cryptome Archive as provided by coderman on a Tor hidden
service:
The three wikileaks files mentioned in the post are included in the
USB-2.rar

#Verify with GnuGPG:
The files Update-13-1231.rar, USB-1.rar and USB-2.rar have a *.sig file
which can be used to verify the files.
That key 0xb650572b8b3bf75c is published on
http://www.cryptome.org/#Cryptome%20PK
and is available on keyservers like
http://pgpkeys.eu:11371/pks/lookup?op=vindex&search=0xb650572b8b3bf75c

#Torrent of old Cryptome Archive from 2011:
https://thepiratebay.se/torrent/7919294/Cryptome_Archive_2011_Unverified
magnet:?xt=urn:btih:ba401110a60ad844a09d4219e5f95a46385f7410&dn=Cryptome+Archive+2011+Unverified&tr=udp%3A%2F%2Ftracker.istole.it%3A80




From l at odewijk.nl  Sat Sep 27 09:49:25 2014
From: l at odewijk.nl (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?=)
Date: Sat, 27 Sep 2014 18:49:25 +0200
Subject: bashing your head against nation-state social engineering
In-Reply-To: <20140927160304.GC1755@nl.grid.coop>
References: <20140927160304.GC1755@nl.grid.coop>
Message-ID: <CAHWD2rKUxNKtXgQ8VtvW9_L4XcXKxrRXaCVF+fZiH9_o2jE3Ug@mail.gmail.com>

Know what you code, and what you run. Don't be fooled by words and shapes,
code does what code does, that is all.

We seriously need a way to detach code from mental models to expose hidden
features. Basically, all computer law is rubbish because everything you run
on your computer, exploits and all, is something you run by choice. But
there's no way you could validate the sheer bulk of code. If you want to
really solve security flaws it'll involve somehow validating the
possibilities of the code run.

It's a discipline that touches on visualization, automated testing and
simplification. Simplification meaning, reducing possible states and
"execution paths". And just making code easier to comprehend.

The problem is that there's either no market for "truly secure" computing,
or there's just nobody filling the gap. Banks with their Cobol are laughed
at, mostly, and accused of lacking innovation. They do lack innovation in
the technical field. And Cobol is definitely not an ideal language. But
"truly secure" is worth a lot to them. L4 validated is a step in the right
direction, but catches a lot of wind saying it's still imperfect and
therefore worthless.

I'm utterly bored by code review. Maybe it'd be better if there were some
nicer tools to help out. I'm really sure someone has great recommendations
regarding this. (That don't even require Cobol :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 1754 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140927/24d4186c/attachment.txt>

From hozer at hozed.org  Sat Sep 27 18:57:13 2014
From: hozer at hozed.org (Troy Benjegerdes)
Date: Sat, 27 Sep 2014 20:57:13 -0500
Subject: bashing your head against nation-state social engineering
In-Reply-To: <CAKtE3zcZ9LuBKvJnFm_RJ3te=MotchXXDioJa17291uHUvFJFg@mail.gmail.com>
References: <20140927160304.GC1755@nl.grid.coop>
 <CAHWD2rKUxNKtXgQ8VtvW9_L4XcXKxrRXaCVF+fZiH9_o2jE3Ug@mail.gmail.com>
 <CAKtE3zcZ9LuBKvJnFm_RJ3te=MotchXXDioJa17291uHUvFJFg@mail.gmail.com>
Message-ID: <20140928015713.GD1755@nl.grid.coop>

So every once in awhile I have fits of plausible paranoia, which lead me to
second guess the motives of everyone arguing why it's 'so hard' to simplify
things by doing something like removing bash from debian.

The fastest way for me to remove potential vulnerabilities in bash environment
handling is remove the code, and the side effect is this, as a policy will
hopefully make for more standard and maintainable code, rather than stuff 
that happens to rely on the specific implementation of a shell.

So yeah, it's probably unlikely this was intentionally created, however I
think it's a good bet it was intentionally exploited at least once, and
there is plenty of motivation for some social engineering to try to keep
it exploitable.

My hope, however, is that inter-departmental competition inside TLA agencies
and within nation-states is sufficient so that at least one security head 
who has similiar plausibly paranoid delusions, and decides to fund OpenBSD 
and/or bash-free debian as a short term, and some of the more interesting
security by isolation stuff on the horizon.


On Sat, Sep 27, 2014 at 02:48:24PM -0400, Travis Biehn wrote:
> I'm partial to Joanna Rutkowska's statement that "Security by Isolation" is
> the best course followed for -users- of software. [in addition to all the
> patching and whatever.]
> 
> Developers of that software, ultimately, are responsible for securing their
> stuff. As an aside - separating your complex system into multiple trust
> zones, from a development standpoint, is de-rigueur for secure design.
> 
> Security heads have long been decrying cgi-bin. Most of the reason is that
> the threat surface is insane - for binaries you have user input that's not
> running in some sort of VM [php,perl,ruby,node.js, etc] and existing in
> memory entangled with executable instructions.
> 
> Injection attacks, are, of course old-hat. The daemons could have done some
> hand-holding in this respect before passing off headers to ENV variables.
> 
> The issue is that 'restricted chars' wasn't defined by a standard interface
> between daemon and cgi-bin script. The called function has a completely
> arbitrary set of restricted chars.
> /bin/bash, of course, isn't written to withstand env attacks - since the
> calling user controls the env / and bash is executed under that user's
> privileges.
> So it is, of a matter of course, inevitable to find vulnerability there.
> With one process isolating the client from the env, modifying the env as a
> result of the user's whims and then passing off to a sub-process that
> trusts the env implicitly.
> 
> It is very unlikely that any TLA 'created' this vulnerability. The notion
> is entirely incredible. The existence of vulnerability in such a design is
> immediately obvious from anyone who takes more than a cursory look at it.
> That isn't to say that this specific attack was trivial to identify - that
> is to say from an architecture standpoint it should be evident that the
> handoff between httpd and cgi-bin is a location of extreme vulnerability.
> 
> On a related note: Mirage OS looks like it's on a promising tack:
> http://www.xenproject.org/developers/teams/mirage-os.html
> 
> -Travis
> 
> On Sat, Sep 27, 2014 at 12:49 PM, Lodewijk andré de la porte <l at odewijk.nl>
> wrote:
> 
> > Know what you code, and what you run. Don't be fooled by words and shapes,
> > code does what code does, that is all.
> >
> > We seriously need a way to detach code from mental models to expose hidden
> > features. Basically, all computer law is rubbish because everything you run
> > on your computer, exploits and all, is something you run by choice. But
> > there's no way you could validate the sheer bulk of code. If you want to
> > really solve security flaws it'll involve somehow validating the
> > possibilities of the code run.
> >
> > It's a discipline that touches on visualization, automated testing and
> > simplification. Simplification meaning, reducing possible states and
> > "execution paths". And just making code easier to comprehend.
> >
> > The problem is that there's either no market for "truly secure" computing,
> > or there's just nobody filling the gap. Banks with their Cobol are laughed
> > at, mostly, and accused of lacking innovation. They do lack innovation in
> > the technical field. And Cobol is definitely not an ideal language. But
> > "truly secure" is worth a lot to them. L4 validated is a step in the right
> > direction, but catches a lot of wind saying it's still imperfect and
> > therefore worthless.
> >
> > I'm utterly bored by code review. Maybe it'd be better if there were some
> > nicer tools to help out. I'm really sure someone has great recommendations
> > regarding this. (That don't even require Cobol :)
> >
> 
> 
> 
> -- 
> Twitter <https://twitter.com/tbiehn> | LinkedIn
> <http://www.linkedin.com/in/travisbiehn> | GitHub <http://github.com/tbiehn>
> | TravisBiehn.com <http://www.travisbiehn.com> | Google Plus
> <https://plus.google.com/+TravisBiehn>

-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer at hozed.org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash




From tbiehn at gmail.com  Sat Sep 27 20:21:50 2014
From: tbiehn at gmail.com (Travis Biehn)
Date: Sat, 27 Sep 2014 23:21:50 -0400
Subject: bashing your head against nation-state social engineering
In-Reply-To: <20140928015713.GD1755@nl.grid.coop>
References: <20140927160304.GC1755@nl.grid.coop>
 <CAHWD2rKUxNKtXgQ8VtvW9_L4XcXKxrRXaCVF+fZiH9_o2jE3Ug@mail.gmail.com>
 <CAKtE3zcZ9LuBKvJnFm_RJ3te=MotchXXDioJa17291uHUvFJFg@mail.gmail.com>
 <20140928015713.GD1755@nl.grid.coop>
Message-ID: <CAKtE3zcfTC9+sAgTaw2XUwPPE_EM1_XEsC-AB5v9fJOQ=1KWhw@mail.gmail.com>

As long as 'fixing the problem' is perceived to be more expensive than
'applying patches' then the problem will persist.

Meanwhile the rest of the cognoscenti can air-gap key signing activities
and use managed code / safe languages or throwaway VMs.

Troy, as an end user you may be interested in pursuing Qubes for your daily
OS if you're interested in 'browsing the internet' and 'remaining
reasonably safe from state level attackers.'

-Travis

On Sat, Sep 27, 2014 at 9:57 PM, Troy Benjegerdes <hozer at hozed.org> wrote:

> So every once in awhile I have fits of plausible paranoia, which lead me to
> second guess the motives of everyone arguing why it's 'so hard' to simplify
> things by doing something like removing bash from debian.
>
> The fastest way for me to remove potential vulnerabilities in bash
> environment
> handling is remove the code, and the side effect is this, as a policy will
> hopefully make for more standard and maintainable code, rather than stuff
> that happens to rely on the specific implementation of a shell.
>
> So yeah, it's probably unlikely this was intentionally created, however I
> think it's a good bet it was intentionally exploited at least once, and
> there is plenty of motivation for some social engineering to try to keep
> it exploitable.
>
> My hope, however, is that inter-departmental competition inside TLA
> agencies
> and within nation-states is sufficient so that at least one security head
> who has similiar plausibly paranoid delusions, and decides to fund OpenBSD
> and/or bash-free debian as a short term, and some of the more interesting
> security by isolation stuff on the horizon.
>
>
> On Sat, Sep 27, 2014 at 02:48:24PM -0400, Travis Biehn wrote:
> > I'm partial to Joanna Rutkowska's statement that "Security by Isolation"
> is
> > the best course followed for -users- of software. [in addition to all the
> > patching and whatever.]
> >
> > Developers of that software, ultimately, are responsible for securing
> their
> > stuff. As an aside - separating your complex system into multiple trust
> > zones, from a development standpoint, is de-rigueur for secure design.
> >
> > Security heads have long been decrying cgi-bin. Most of the reason is
> that
> > the threat surface is insane - for binaries you have user input that's
> not
> > running in some sort of VM [php,perl,ruby,node.js, etc] and existing in
> > memory entangled with executable instructions.
> >
> > Injection attacks, are, of course old-hat. The daemons could have done
> some
> > hand-holding in this respect before passing off headers to ENV variables.
> >
> > The issue is that 'restricted chars' wasn't defined by a standard
> interface
> > between daemon and cgi-bin script. The called function has a completely
> > arbitrary set of restricted chars.
> > /bin/bash, of course, isn't written to withstand env attacks - since the
> > calling user controls the env / and bash is executed under that user's
> > privileges.
> > So it is, of a matter of course, inevitable to find vulnerability there.
> > With one process isolating the client from the env, modifying the env as
> a
> > result of the user's whims and then passing off to a sub-process that
> > trusts the env implicitly.
> >
> > It is very unlikely that any TLA 'created' this vulnerability. The notion
> > is entirely incredible. The existence of vulnerability in such a design
> is
> > immediately obvious from anyone who takes more than a cursory look at it.
> > That isn't to say that this specific attack was trivial to identify -
> that
> > is to say from an architecture standpoint it should be evident that the
> > handoff between httpd and cgi-bin is a location of extreme vulnerability.
> >
> > On a related note: Mirage OS looks like it's on a promising tack:
> > http://www.xenproject.org/developers/teams/mirage-os.html
> >
> > -Travis
> >
> > On Sat, Sep 27, 2014 at 12:49 PM, Lodewijk andré de la porte <
> l at odewijk.nl>
> > wrote:
> >
> > > Know what you code, and what you run. Don't be fooled by words and
> shapes,
> > > code does what code does, that is all.
> > >
> > > We seriously need a way to detach code from mental models to expose
> hidden
> > > features. Basically, all computer law is rubbish because everything
> you run
> > > on your computer, exploits and all, is something you run by choice. But
> > > there's no way you could validate the sheer bulk of code. If you want
> to
> > > really solve security flaws it'll involve somehow validating the
> > > possibilities of the code run.
> > >
> > > It's a discipline that touches on visualization, automated testing and
> > > simplification. Simplification meaning, reducing possible states and
> > > "execution paths". And just making code easier to comprehend.
> > >
> > > The problem is that there's either no market for "truly secure"
> computing,
> > > or there's just nobody filling the gap. Banks with their Cobol are
> laughed
> > > at, mostly, and accused of lacking innovation. They do lack innovation
> in
> > > the technical field. And Cobol is definitely not an ideal language. But
> > > "truly secure" is worth a lot to them. L4 validated is a step in the
> right
> > > direction, but catches a lot of wind saying it's still imperfect and
> > > therefore worthless.
> > >
> > > I'm utterly bored by code review. Maybe it'd be better if there were
> some
> > > nicer tools to help out. I'm really sure someone has great
> recommendations
> > > regarding this. (That don't even require Cobol :)
> > >
> >
> >
> >
> > --
> > Twitter <https://twitter.com/tbiehn> | LinkedIn
> > <http://www.linkedin.com/in/travisbiehn> | GitHub <
> http://github.com/tbiehn>
> > | TravisBiehn.com <http://www.travisbiehn.com> | Google Plus
> > <https://plus.google.com/+TravisBiehn>
>
> --
>
> ----------------------------------------------------------------------------
> Troy Benjegerdes                 'da hozer'
> hozer at hozed.org
> 7 elements      earth::water::air::fire::mind::spirit::soul
> grid.coop
>
>       Never pick a fight with someone who buys ink by the barrel,
>          nor try buy a hacker who makes money by the megahash
>
>


-- 
Twitter <https://twitter.com/tbiehn> | LinkedIn
<http://www.linkedin.com/in/travisbiehn> | GitHub <http://github.com/tbiehn>
| TravisBiehn.com <http://www.travisbiehn.com> | Google Plus
<https://plus.google.com/+TravisBiehn>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 8295 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140927/e3160915/attachment.txt>

From contact at subrosa.io  Sun Sep 28 06:47:55 2014
From: contact at subrosa.io (Subrosa.io)
Date: Sun, 28 Sep 2014 06:47:55 -0700
Subject: bashing your head against nation-state social engineering
In-Reply-To: <mailman.89.1411907116.1882.cypherpunks@cpunks.org>
References: <mailman.89.1411907116.1882.cypherpunks@cpunks.org>
Message-ID: <148bc820a7e.125c6a9a537330.2596211938527105403@subrosa.io>

I think this vulnerability should have been discovered with any kind of basic fuzzing. I have little doubt that this has been discovered and has been exploited in the wild. 

How is Mirage OS promising and relevant here?

---- On Sat, 27 Sep 2014 14:48:24 -0400 Travis Biehn wrote ---- 
>From: Travis Biehn <tbiehn at gmail.com>
>To: Lodewijk andré de la porte <l at odewijk.nl>
>Cc: "cypherpunks at cpunks.org" <cypherpunks at cpunks.org>
>Subject: 
>Message-ID:
>    <CAKtE3zcZ9LuBKvJnFm_RJ3te=MotchXXDioJa17291uHUvFJFg at mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>I'm partial to Joanna Rutkowska's statement that "Security by Isolation" is
>the best course followed for -users- of software. [in addition to all the
>patching and whatever.]
>
>Developers of that software, ultimately, are responsible for securing their
>stuff. As an aside - separating your complex system into multiple trust
>zones, from a development standpoint, is de-rigueur for secure design.
>
>Security heads have long been decrying cgi-bin. Most of the reason is that
>the threat surface is insane - for binaries you have user input that's not
>running in some sort of VM [php,perl,ruby,node.js, etc] and existing in
>memory entangled with executable instructions.
>
>Injection attacks, are, of course old-hat. The daemons could have done some
>hand-holding in this respect before passing off headers to ENV variables.
>
>The issue is that 'restricted chars' wasn't defined by a standard interface
>between daemon and cgi-bin script. The called function has a completely
>arbitrary set of restricted chars.
>/bin/bash, of course, isn't written to withstand env attacks - since the
>calling user controls the env / and bash is executed under that user's
>privileges.
>So it is, of a matter of course, inevitable to find vulnerability there.
>With one process isolating the client from the env, modifying the env as a
>result of the user's whims and then passing off to a sub-process that
>trusts the env implicitly.
>
>It is very unlikely that any TLA 'created' this vulnerability. The notion
>is entirely incredible. The existence of vulnerability in such a design is
>immediately obvious from anyone who takes more than a cursory look at it.
>That isn't to say that this specific attack was trivial to identify - that
>is to say from an architecture standpoint it should be evident that the
>handoff between httpd and cgi-bin is a location of extreme vulnerability.
>
>On a related note: Mirage OS looks like it's on a promising tack:
>http://www.xenproject.org/developers/teams/mirage-os.html
>
>-Travis
>
>On Sat, Sep 27, 2014 at 12:49 PM, Lodewijk andré de la porte <l at odewijk.nl>
>wrote:
>
>> Know what you code, and what you run. Don't be fooled by words and shapes,
>> code does what code does, that is all.
>>
>> We seriously need a way to detach code from mental models to expose hidden
>> features. Basically, all computer law is rubbish because everything you run
>> on your computer, exploits and all, is something you run by choice. But
>> there's no way you could validate the sheer bulk of code. If you want to
>> really solve security flaws it'll involve somehow validating the
>> possibilities of the code run.
>>
>> It's a discipline that touches on visualization, automated testing and
>> simplification. Simplification meaning, reducing possible states and
>> "execution paths". And just making code easier to comprehend.
>>
>> The problem is that there's either no market for "truly secure" computing,
>> or there's just nobody filling the gap. Banks with their Cobol are laughed
>> at, mostly, and accused of lacking innovation. They do lack innovation in
>> the technical field. And Cobol is definitely not an ideal language. But
>> "truly secure" is worth a lot to them. L4 validated is a step in the right
>> direction, but catches a lot of wind saying it's still imperfect and
>> therefore worthless.
>>
>> I'm utterly bored by code review. Maybe it'd be better if there were some
>> nicer tools to help out. I'm really sure someone has great recommendations
>> regarding this. (That don't even require Cobol :)
>>
>
>
>
>-- 
>Twitter <https://twitter.com/tbiehn> | LinkedIn
><http://www.linkedin.com/in/travisbiehn> | GitHub <http://github.com/tbiehn>
>| TravisBiehn.com <http://www.travisbiehn.com> | Google Plus
><https://plus.google.com/+TravisBiehn>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://cpunks.org/pipermail/cypherpunks/attachments/20140927/fb6add10/attachment-0001.html>
>





From hozer at hozed.org  Sun Sep 28 08:49:21 2014
From: hozer at hozed.org (Troy Benjegerdes)
Date: Sun, 28 Sep 2014 10:49:21 -0500
Subject: bashing your head against nation-state social engineering
In-Reply-To: <1444859.TcufLiv13i@lapuntu>
References: <20140927160304.GC1755@nl.grid.coop>
 <CAKtE3zcZ9LuBKvJnFm_RJ3te=MotchXXDioJa17291uHUvFJFg@mail.gmail.com>
 <20140928015713.GD1755@nl.grid.coop> <1444859.TcufLiv13i@lapuntu>
Message-ID: <20140928154921.GG1755@nl.grid.coop>

On Sun, Sep 28, 2014 at 02:24:28PM +0200, rysiek wrote:
> Dnia sobota, 27 września 2014 20:57:13 Troy Benjegerdes pisze:
> > So every once in awhile I have fits of plausible paranoia, which lead me to
> > second guess the motives of everyone arguing why it's 'so hard' to simplify
> > things by doing something like removing bash from debian.
> 
> And that will solve the problem -- how? I am not convinced other shells would 
> be considerably better/safer (I may be wrong here, of course); the problem was 
> (as Travis pointed out) the mind-boggling clusterfsck of cgi-bin. If I were to 
> look for a radical move here, it would be abandoning cgi-bin as a matter of 
> policy.

Well, something like "() { true;}; rm -rf /var/lib/cgi-gin" solves that
problem quite nicely.

What gets the paranoia going is #!/bin/bash in dhclient-script

I'm at least somewhat encouraged by things like systemd and network-manager
that appear to be moving away from shell scripts for running the basic system.

-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer at hozed.org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash




From hozer at hozed.org  Sun Sep 28 08:53:39 2014
From: hozer at hozed.org (Troy Benjegerdes)
Date: Sun, 28 Sep 2014 10:53:39 -0500
Subject: bashing your head against nation-state social engineering
In-Reply-To: <148bc820a7e.125c6a9a537330.2596211938527105403@subrosa.io>
References: <mailman.89.1411907116.1882.cypherpunks@cpunks.org>
 <148bc820a7e.125c6a9a537330.2596211938527105403@subrosa.io>
Message-ID: <20140928155339.GH1755@nl.grid.coop>

Because it's a nice mirage conjured by nation-state social
engineers to get us to crawl further out into the desert? :)

Of course, hackers with stillsuits was probably outside the
social engineering requirements doc.

On Sun, Sep 28, 2014 at 06:47:55AM -0700, Subrosa.io wrote:
> I think this vulnerability should have been discovered with any kind of basic fuzzing. I have little doubt that this has been discovered and has been exploited in the wild. 
> 
> How is Mirage OS promising and relevant here?
> 
> ---- On Sat, 27 Sep 2014 14:48:24 -0400 Travis Biehn wrote ---- 
> >From: Travis Biehn <tbiehn at gmail.com>
> >To: Lodewijk andré de la porte <l at odewijk.nl>
> >Cc: "cypherpunks at cpunks.org" <cypherpunks at cpunks.org>
> >Subject: 
> >Message-ID:
> >    <CAKtE3zcZ9LuBKvJnFm_RJ3te=MotchXXDioJa17291uHUvFJFg at mail.gmail.com>
> >Content-Type: text/plain; charset="utf-8"
> >
> >I'm partial to Joanna Rutkowska's statement that "Security by Isolation" is
> >the best course followed for -users- of software. [in addition to all the
> >patching and whatever.]
> >
> >Developers of that software, ultimately, are responsible for securing their
> >stuff. As an aside - separating your complex system into multiple trust
> >zones, from a development standpoint, is de-rigueur for secure design.
> >
> >Security heads have long been decrying cgi-bin. Most of the reason is that
> >the threat surface is insane - for binaries you have user input that's not
> >running in some sort of VM [php,perl,ruby,node.js, etc] and existing in
> >memory entangled with executable instructions.
> >
> >Injection attacks, are, of course old-hat. The daemons could have done some
> >hand-holding in this respect before passing off headers to ENV variables.
> >
> >The issue is that 'restricted chars' wasn't defined by a standard interface
> >between daemon and cgi-bin script. The called function has a completely
> >arbitrary set of restricted chars.
> >/bin/bash, of course, isn't written to withstand env attacks - since the
> >calling user controls the env / and bash is executed under that user's
> >privileges.
> >So it is, of a matter of course, inevitable to find vulnerability there.
> >With one process isolating the client from the env, modifying the env as a
> >result of the user's whims and then passing off to a sub-process that
> >trusts the env implicitly.
> >
> >It is very unlikely that any TLA 'created' this vulnerability. The notion
> >is entirely incredible. The existence of vulnerability in such a design is
> >immediately obvious from anyone who takes more than a cursory look at it.
> >That isn't to say that this specific attack was trivial to identify - that
> >is to say from an architecture standpoint it should be evident that the
> >handoff between httpd and cgi-bin is a location of extreme vulnerability.
> >
> >On a related note: Mirage OS looks like it's on a promising tack:
> >http://www.xenproject.org/developers/teams/mirage-os.html
> >
> >-Travis
> >
> >On Sat, Sep 27, 2014 at 12:49 PM, Lodewijk andré de la porte <l at odewijk.nl>
> >wrote:
> >
> >> Know what you code, and what you run. Don't be fooled by words and shapes,
> >> code does what code does, that is all.
> >>
> >> We seriously need a way to detach code from mental models to expose hidden
> >> features. Basically, all computer law is rubbish because everything you run
> >> on your computer, exploits and all, is something you run by choice. But
> >> there's no way you could validate the sheer bulk of code. If you want to
> >> really solve security flaws it'll involve somehow validating the
> >> possibilities of the code run.
> >>
> >> It's a discipline that touches on visualization, automated testing and
> >> simplification. Simplification meaning, reducing possible states and
> >> "execution paths". And just making code easier to comprehend.
> >>
> >> The problem is that there's either no market for "truly secure" computing,
> >> or there's just nobody filling the gap. Banks with their Cobol are laughed
> >> at, mostly, and accused of lacking innovation. They do lack innovation in
> >> the technical field. And Cobol is definitely not an ideal language. But
> >> "truly secure" is worth a lot to them. L4 validated is a step in the right
> >> direction, but catches a lot of wind saying it's still imperfect and
> >> therefore worthless.
> >>
> >> I'm utterly bored by code review. Maybe it'd be better if there were some
> >> nicer tools to help out. I'm really sure someone has great recommendations
> >> regarding this. (That don't even require Cobol :)
> >>
> >
> >
> >
> >-- 
> >Twitter <https://twitter.com/tbiehn> | LinkedIn
> ><http://www.linkedin.com/in/travisbiehn> | GitHub <http://github.com/tbiehn>
> >| TravisBiehn.com <http://www.travisbiehn.com> | Google Plus
> ><https://plus.google.com/+TravisBiehn>
> >-------------- next part --------------
> >An HTML attachment was scrubbed...
> >URL: <http://cpunks.org/pipermail/cypherpunks/attachments/20140927/fb6add10/attachment-0001.html>
> >
> 
> 

-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer at hozed.org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash




From rysiek at hackerspace.pl  Sun Sep 28 05:24:28 2014
From: rysiek at hackerspace.pl (rysiek)
Date: Sun, 28 Sep 2014 14:24:28 +0200
Subject: bashing your head against nation-state social engineering
In-Reply-To: <20140928015713.GD1755@nl.grid.coop>
References: <20140927160304.GC1755@nl.grid.coop>
 <CAKtE3zcZ9LuBKvJnFm_RJ3te=MotchXXDioJa17291uHUvFJFg@mail.gmail.com>
 <20140928015713.GD1755@nl.grid.coop>
Message-ID: <1444859.TcufLiv13i@lapuntu>

Dnia sobota, 27 września 2014 20:57:13 Troy Benjegerdes pisze:
> So every once in awhile I have fits of plausible paranoia, which lead me to
> second guess the motives of everyone arguing why it's 'so hard' to simplify
> things by doing something like removing bash from debian.

And that will solve the problem -- how? I am not convinced other shells would 
be considerably better/safer (I may be wrong here, of course); the problem was 
(as Travis pointed out) the mind-boggling clusterfsck of cgi-bin. If I were to 
look for a radical move here, it would be abandoning cgi-bin as a matter of 
policy.

-- 
Pozdr
rysiek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 411 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140928/9ce8c7fd/attachment.sig>

From bluelotus at openmailbox.org  Mon Sep 29 05:20:16 2014
From: bluelotus at openmailbox.org (bluelotus at openmailbox.org)
Date: Mon, 29 Sep 2014 08:20:16 -0400
Subject: Manufacturing open hardware
Message-ID: <9517af22bf089e4247530ce18a690199@openmailbox.org>

http://www.datamation.com/open-source/what-linux-users-should-know-about-open-hardware-1.html




From stephan.neuhaus at tik.ee.ethz.ch  Sun Sep 28 23:58:24 2014
From: stephan.neuhaus at tik.ee.ethz.ch (Stephan Neuhaus)
Date: Mon, 29 Sep 2014 08:58:24 +0200
Subject: bashing your head against nation-state social engineering
In-Reply-To: <148bc820a7e.125c6a9a537330.2596211938527105403@subrosa.io>
References: <mailman.89.1411907116.1882.cypherpunks@cpunks.org>
 <148bc820a7e.125c6a9a537330.2596211938527105403@subrosa.io>
Message-ID: <54290310.3090903@tik.ee.ethz.ch>

On 2014-09-28 15:47, Subrosa.io wrote:
> I think this vulnerability should have been discovered with any kind of basic fuzzing.

If I understand the vulnerability correctly, it occurs in very specific 
circumstances, namely trailing data at the end of a function definition 
that's transported in an environment variable.

In that case, I'd venture that *no* kind of "basic fuzzing" could have 
uncovered this; the proportion of ShellShock-inducing environment 
variable definitions among all possible environment variables is simply 
too small.

What you would need instead is very specific syntax-directed fuzzing, 
and even then I'm not sure that you have a decent chance of discovering 
this without knowing already that it's there.

Fun,

Stephan




From dal at riseup.net  Mon Sep 29 07:08:48 2014
From: dal at riseup.net (Douglas Lucas)
Date: Mon, 29 Sep 2014 09:08:48 -0500
Subject: Radical-safest TLDs in 2007
Message-ID: <542967F0.4080207@riseup.net>

I have a historical question. In 2007, anywhere from January to
September, what TLDs were regarded as the most pirate-friendly or
journalism-friendly or safest from takedowns of whatever stripe, e.g.
the sort of DHS DMCA takedowns we have now, etc.?




From hozer at hozed.org  Mon Sep 29 21:24:49 2014
From: hozer at hozed.org (Troy Benjegerdes)
Date: Mon, 29 Sep 2014 23:24:49 -0500
Subject: Bitcoin mining ASIC decapped
In-Reply-To: <E1XYmxe-0007wX-Ej@login01.fos.auckland.ac.nz>
References: <E1XYmxe-0007wX-Ej@login01.fos.auckland.ac.nz>
Message-ID: <20140930042449.GL1755@nl.grid.coop>

On Tue, Sep 30, 2014 at 03:14:42PM +1300, Peter Gutmann wrote:
> In case anyone's interested, this site:
> 
> http://zeptobars.ru/en/read/bitfury-bitcoin-mining-chip
> 
> has some photos of what looks like a decapped Bitfury ASIC.  It's a pretty
> unique structure...
> 
> Peter.

Who can spot the trojan circuit that allows $SPY_GUYS to track every 
bitcoin mined from that asic? (Although that could just be in the 
power signature and not actually the silicon)




From grarpamp at gmail.com  Tue Sep 30 00:38:34 2014
From: grarpamp at gmail.com (grarpamp)
Date: Tue, 30 Sep 2014 03:38:34 -0400
Subject: Fwd: [Cryptography] "Spy Agencies Urge Caution on Phone Deal"
In-Reply-To: <31C18954-119C-4845-A747-DF1BC684F50F@lrw.com>
References: <31C18954-119C-4845-A747-DF1BC684F50F@lrw.com>
Message-ID: <CAD2Ti28o9XWtb04k8CaArVGKWJg8NAqOsHWxCM6PT3E4LcvhDg@mail.gmail.com>

Number portability and more... trivially redirected to anywhere
for MITM... courtesy Neustar.

http://en.wikipedia.org/wiki/PSTN_network_topology
http://en.wikipedia.org/wiki/Routing_in_the_PSTN
http://en.wikipedia.org/wiki/Intelligent_Network
http://en.wikipedia.org/wiki/Local_number_portability
http://en.wikipedia.org/wiki/RespOrg
http://en.wikipedia.org/wiki/Toll-free_number_portability
http://en.wikipedia.org/wiki/North_American_Numbering_Plan
http://en.wikipedia.org/wiki/Neustar
http://www.npac.com/
http://leap.neustar.biz/


---------- Forwarded message ----------
From: Jerry Leichter <leichter at lrw.com>
Date: Mon, Sep 29, 2014 at 11:51 PM
Subject: [Cryptography] "Spy Agencies Urge Caution on Phone Deal"
To: Cryptography <cryptography at metzdowd.com>


Not directly crypto-related, but an example of the tangle of
relationships that drive surveillance:
http://www.nytimes.com/2014/09/29/us/spy-agencies-urge-caution-on-phone-deal.html?_r=0&pagewanted=all
reports on a backstage argument going on in Washington about a special
network/database - oddly never named in the article - that "rout[es]
millions of phone calls and text messages in the United States".
Apparently this was a system created back in the late 1990's to
implement number portability.  It's not clear from the article whether
it's a database of number-to-carrier mappings, or actually routes call
based on such a database.

A small Virginia company named Neustar created the system and has
managed it ever since.  Recently, the major carriers recommended to
the FCC that Neustar be replaced by Telcordia, an American subsidiary
of Ericsson, which allegedly can do the job more cheaply.  The
"intelligence community" has been pushed to leave the job in Neustar's
hands, claiming that letting a European company run the system would
leak important information about how US surveillance of the phone
networks is implemented.

Neustar, obviously no stranger to the Washington inside game, has
hired good ol' Michael Chertoff to represent them.

The bullshit and inside baseball and lobbying here runs so deep you
can't see bottom.  And underneath it all, another piece of the vast
tapping network we've built in the US in the last 12 or so years is
revealed, just a little bit.

                                                        -- Jerry




From groundhog593 at riseup.net  Tue Sep 30 02:39:00 2014
From: groundhog593 at riseup.net (Bethany)
Date: Tue, 30 Sep 2014 10:39:00 +0100
Subject: Firechat, this =?UTF-8?B?wqtmcmVlZG9tIG9mIHNwZWVjaC1hcHDCuyBp?=
 =?UTF-8?B?cyBib2d1cw==?=
In-Reply-To: <20140930142309.2fc19ac4@xalunon>
References: <20140930142309.2fc19ac4@xalunon>
Message-ID: <542A7A34.9070402@riseup.net>

I'm mostly a lurker, too, but I'll remark that Firechat can't be bogus:
its use caught on in a massive way, and the ease of use and the P2P
connection feature is playing an active part in a community's SUCCESSFUL
self-organization in the face of real repression. While you're
absolutely right that an app can't call itself anonymous if it collects
Google Play information on its users, the question about whether the app
allows perfect anonymity isn't as important as: does the app allow
perfect anonymity from Beijing? Is there a danger that Google Co. Inc.
will help the government of China identify Firechat users in the case of
a retroactive crackdown? This is a political problem North Americans
could indeed work on, if it came down to that. This conversation reminds
me of Quinn Norton's "assess your adversary" talk at HOPE
(https://www.youtube.com/watch?v=RkjrbK3DyRM).

I'd also point out that I believe Firechat is open source. And on
Github: https://github.com/firebase/firechat They're working on adding
encryption:
http://www.forbes.com/sites/parmyolson/2014/09/29/firechat-prepares-encryption-feature-as-it-drives-hong-kong-protests/

On 30/09/14 07:23 AM, Xavier wrote:
> Hello there,
>
> Mostly I'm just a lurker here but for once I will ask some
> questions/make remarks about Firechat.
>
> As you may know, this app just got extensive media coverage due to
> their widespread use in Hong Kong «Occupy-central». Check on the
> Guardian for
> example: www.theguardian.com/world/2014/sep/29/firechat-messaging-app-powering-hong-kong-protests
>
> So, out of curiosity, I just downloaded the app. Below are my remarks
> on the process:
>
> - You can't directly download the apk from the website. For android,
>   the only link available is from the Google store. As if, if you
>   really need privacy and freedom of speech, the first thing that you
>   do is have a google account linked to your android device. I
>   downloaded the app from Aptoide, but well…
>
> - Once you download the app, required permissions include:
> 	- Localization
> 	- Read contacts
> 	- Search accounts on the device
>
> How are those permissions necessary ? I just want to connect to nearby
> people. I don't need firechat servers to point me to those people nor
> to know where I am or with whom I chat.
>
> - Once you launch the app, there comes the cherry on the cake, you need
>   to have properly activated and updated Google Play background
>   services in order to run the app. I suppose that it implies that you
>   must have a Google account linked to your device and that, thanks to
>   the «Search account» permission, Firechat just like Google are
>   perfectly aware of who you exactly are ??
>
> If my goal was just to chat with my neighbors without paying during
> the Worldcup, that would be fine, but the problem here is that this app
> is now also marketed in newspapers as a privacy app, thanks to Hong Kong
> protests.
>
> When the product was released a few month ago, I already tried it but
> abandoned immediately due to those privacy problems. What I want first
> of all is privacy, not to avoid paying my provider. Now I understand
> that for Hong Kong people this is a lesser evil solution because they
> fear an Internet shutdown, but well, I am disappointed to remark that
> «freedom-of-speech» and «privacy-aware» are so strongly disconnected
> even in a promising app like this one. 
>
> Xavier
>




From l at odewijk.nl  Tue Sep 30 02:55:55 2014
From: l at odewijk.nl (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?=)
Date: Tue, 30 Sep 2014 11:55:55 +0200
Subject: How worse is the shellshock bash bug than Heartbleed?
In-Reply-To: <20140930092602.GA2855@sivokote.iziade.m$>
References: <20140930092602.GA2855@sivokote.iziade.m$>
Message-ID: <CAHWD2rJAk6LH9=efwNTgyxXkc4uVhx8QQpHyr58Bw=Utze79Sg@mail.gmail.com>

Heartbleed was a memory leak that eventually, after carefully calculated
exploiting, can lead to a remote root.

Shellshock depends on a lot of environmental details, but is possible
little more than a hard to reach shell with elevated permissions.

I guess heartbleed was actually worse. Who runs webscripts and stuff in
root? That's really foolhardy. But using OpenSSL ... We usually thought it
good practice!
On Sep 30, 2014 11:41 AM, "Georgi Guninski" <guninski at guninski.com> wrote:

> Recently a bash(1) bug called shellsock died.
> It affected Apache, DHCP, SSH,qmail,Pure-FTPd and other stuff.
> Summary of affected:
> https://github.com/mubix/shellshocker-pocs/blob/master/README.md
>
> I find this _much_ worse than the passive Heartbleed.
>
> How worse is the shellshock bash bug than Heartbleed?
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 1205 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140930/4c65a23b/attachment.txt>

From rysiek at hackerspace.pl  Tue Sep 30 02:59:19 2014
From: rysiek at hackerspace.pl (rysiek)
Date: Tue, 30 Sep 2014 11:59:19 +0200
Subject: How worse is the shellshock bash bug than Heartbleed?
In-Reply-To: <20140930092602.GA2855@sivokote.iziade.m$>
References: <20140930092602.GA2855@sivokote.iziade.m$>
Message-ID: <11299235.eyLTRRrY2d@lapuntu>

Dnia wtorek, 30 września 2014 12:26:02 Georgi Guninski pisze:
> How worse is the shellshock bash bug than Heartbleed?

/me grabs some popcorn

Oh, this gonna be good.

-- 
Pozdr
rysiek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 411 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140930/14e93d2b/attachment.sig>

From guninski at guninski.com  Tue Sep 30 02:26:02 2014
From: guninski at guninski.com (Georgi Guninski)
Date: Tue, 30 Sep 2014 12:26:02 +0300
Subject: How worse is the shellshock bash bug than Heartbleed?
Message-ID: <20140930092602.GA2855@sivokote.iziade.m$>

Recently a bash(1) bug called shellsock died.
It affected Apache, DHCP, SSH,qmail,Pure-FTPd and other stuff.
Summary of affected: 
https://github.com/mubix/shellshocker-pocs/blob/master/README.md

I find this _much_ worse than the passive Heartbleed.

How worse is the shellshock bash bug than Heartbleed?




From cyberkiller8 at gmail.com  Tue Sep 30 03:30:57 2014
From: cyberkiller8 at gmail.com (=?UTF-8?B?IsWBdWthc3ogXCJDeWJlciBLaWxsZXJcIiBLb3JwYWxza2ki?=)
Date: Tue, 30 Sep 2014 12:30:57 +0200
Subject: How worse is the shellshock bash bug than Heartbleed?
In-Reply-To: <CAHWD2rJAk6LH9=efwNTgyxXkc4uVhx8QQpHyr58Bw=Utze79Sg@mail.gmail.com>
References: <20140930092602.GA2855@sivokote.iziade.m$>
 <CAHWD2rJAk6LH9=efwNTgyxXkc4uVhx8QQpHyr58Bw=Utze79Sg@mail.gmail.com>
Message-ID: <542A8661.7070904@gmail.com>

W dniu 30.09.2014 o 11:55, Lodewijk andré de la porte pisze:
> Heartbleed was a memory leak that eventually, after carefully calculated
> exploiting, can lead to a remote root.
> 
> Shellshock depends on a lot of environmental details, but is possible
> little more than a hard to reach shell with elevated permissions.
> 
> I guess heartbleed was actually worse. Who runs webscripts and stuff in
> root? That's really foolhardy. But using OpenSSL ... We usually thought
> it good practice!
> 

Agree, heartbleed was a bigger problem, though I think I know why so
many people panic because of this.

My theory is, with heartbleed most folks thought they were unaffected,
cause not many noob people run a webserver. But with shellshock they can
test this on their own machine, with just 1 line of code and see the
"vulnerable" message, so suddenly this is a big deal for them.

So, don't panic & stay cool, unless you have some badly configured
servers or have a habit of running everything on your workstation
without checking. But then you got bigger problems than this ;-).

-- 
Łukasz "Cyber Killer" Korpalski

mail: cyberkiller8 at gmail.com
xmpp: cyber_killer at jabster.pl
site: http://website.cybkil.cu.cc
gpgkey: 0x72511999 @ hkp://keys.gnupg.net

//When replying to my e-mail, kindly please
//write your message below the quoted text.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140930/9d0cfe44/attachment.sig>

From stephan.neuhaus at tik.ee.ethz.ch  Tue Sep 30 04:27:39 2014
From: stephan.neuhaus at tik.ee.ethz.ch (Stephan Neuhaus)
Date: Tue, 30 Sep 2014 13:27:39 +0200
Subject: Bitcoin mining ASIC decapped
In-Reply-To: <E1XYmxe-0007wX-Ej@login01.fos.auckland.ac.nz>
References: <E1XYmxe-0007wX-Ej@login01.fos.auckland.ac.nz>
Message-ID: <542A93AB.10001@tik.ee.ethz.ch>

On 2014-09-30 04:14, Peter Gutmann wrote:
> In case anyone's interested, this site:
>
> http://zeptobars.ru/en/read/bitfury-bitcoin-mining-chip
>
> has some photos of what looks like a decapped Bitfury ASIC.  It's a pretty
> unique structure...

The article mentions that it was the designer's first ASIC project. 
Maybe it's because of this?

Fun,

Stephan




From deatos at gmail.com  Tue Sep 30 11:04:05 2014
From: deatos at gmail.com (tim taylor)
Date: Tue, 30 Sep 2014 14:04:05 -0400
Subject: How worse is the shellshock bash bug than Heartbleed?
In-Reply-To: <20140930150524.GD2855@sivokote.iziade.m$>
References: <20140930092602.GA2855@sivokote.iziade.m$>
 <542A8661.7070904@gmail.com>
 <20140930112528.GB2855@sivokote.iziade.m$> <17223152.OU4snMSJSA@lapuntu>
 <20140930132603.GC2855@sivokote.iziade.m$>
 <CAHWD2rKQARd=9ucDORfsyqELFB3FiDafK_Wqah7rONXyuzPigA@mail.gmail.com>
 <20140930150524.GD2855@sivokote.iziade.m$>
Message-ID: <CAANL_4k7UtTU_3cp5kLk-TUX-cPoty=zMoyFFjRhM_wrXMM-eg@mail.gmail.com>

Or cpanels suid scripts that invoke bash? :)

On Tue, Sep 30, 2014 at 11:05 AM, Georgi Guninski <guninski at guninski.com>
wrote:

> On Tue, Sep 30, 2014 at 03:59:33PM +0200, Lodewijk andré de la porte wrote:
> > On Sep 30, 2014 3:40 PM, "Georgi Guninski" <guninski at guninski.com>
> wrote:
> > >
> > > If I had a budget for buying sploits, I would
> > > pay much more for shockshell than for HB, might be wrong.
> >
> > This is a really good metric. It instantly combines utility with
> potential
> > etc.
> >
> > HB obtains you the root password, too. Maybe you have to wait for the
> admin
> > to log in, but still. It also doesn't leave a trace, which is neat.
> >
>
> Is there a reference that HB _alone_ gets you the root password?
> Maybe I am dumb, but don't see way to get the root password in
>  sound setup even if I can ptrace() httpd.
>
>
> > HB gets you exploits for some very serious competitors. Shellshock only
> for
> > silly competition and, unless they're really silly, requires another
> > exploit for root.
> >
>
> Probably shellshock will give you root via DHCP and
> for another root exploit you might try to shock suid stuff :)
>
> On the web the myriads of buggy cgi's probably can compete
> with shellshock, though it is more universal and allegedly
> works for significant amount of daemons.
>
>
> > So.. it depends! On too much. For me personally shellshock is an easier
> > exploit but heartbleed can be way more fun. Hmm... have to go with
> > heartbleed in the end. Real users often use the same password, so that'd
> > let me take open wifi users by surprise. If you'd want you can take
> > servers, even though it's a tease harder.
>



-- 
--------
Phone: 1 (434) 933-2867
Skype: deatos2k
My Website: http://www.deatoslabs.com
My Security Blog: http://deatos.blogspot.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 2565 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140930/1004060c/attachment.txt>

From listes at sploing.be  Mon Sep 29 23:23:09 2014
From: listes at sploing.be (Xavier)
Date: Tue, 30 Sep 2014 14:23:09 +0800
Subject: Firechat, this =?UTF-8?B?wqtmcmVlZG9t?= of =?UTF-8?B?c3BlZWNoLWFw?=
 =?UTF-8?B?cMK7?= is bogus
Message-ID: <20140930142309.2fc19ac4@xalunon>

Hello there,

Mostly I'm just a lurker here but for once I will ask some
questions/make remarks about Firechat.

As you may know, this app just got extensive media coverage due to
their widespread use in Hong Kong «Occupy-central». Check on the
Guardian for
example: www.theguardian.com/world/2014/sep/29/firechat-messaging-app-powering-hong-kong-protests

So, out of curiosity, I just downloaded the app. Below are my remarks
on the process:

- You can't directly download the apk from the website. For android,
  the only link available is from the Google store. As if, if you
  really need privacy and freedom of speech, the first thing that you
  do is have a google account linked to your android device. I
  downloaded the app from Aptoide, but well…

- Once you download the app, required permissions include:
	- Localization
	- Read contacts
	- Search accounts on the device

How are those permissions necessary ? I just want to connect to nearby
people. I don't need firechat servers to point me to those people nor
to know where I am or with whom I chat.

- Once you launch the app, there comes the cherry on the cake, you need
  to have properly activated and updated Google Play background
  services in order to run the app. I suppose that it implies that you
  must have a Google account linked to your device and that, thanks to
  the «Search account» permission, Firechat just like Google are
  perfectly aware of who you exactly are ??

If my goal was just to chat with my neighbors without paying during
the Worldcup, that would be fine, but the problem here is that this app
is now also marketed in newspapers as a privacy app, thanks to Hong Kong
protests.

When the product was released a few month ago, I already tried it but
abandoned immediately due to those privacy problems. What I want first
of all is privacy, not to avoid paying my provider. Now I understand
that for Hong Kong people this is a lesser evil solution because they
fear an Internet shutdown, but well, I am disappointed to remark that
«freedom-of-speech» and «privacy-aware» are so strongly disconnected
even in a promising app like this one. 

Xavier




From rysiek at hackerspace.pl  Tue Sep 30 05:24:44 2014
From: rysiek at hackerspace.pl (rysiek)
Date: Tue, 30 Sep 2014 14:24:44 +0200
Subject: How worse is the shellshock bash bug than Heartbleed?
In-Reply-To: <20140930112528.GB2855@sivokote.iziade.m$>
References: <20140930092602.GA2855@sivokote.iziade.m$>
 <542A8661.7070904@gmail.com> <20140930112528.GB2855@sivokote.iziade.m$>
Message-ID: <17223152.OU4snMSJSA@lapuntu>

OHAI,

Dnia wtorek, 30 września 2014 14:25:28 Georgi Guninski pisze:
> > Agree, heartbleed was a bigger problem, though I think I know why so
> > many people panic because of this.
> > 
> > My theory is, with heartbleed most folks thought they were unaffected,
> > cause not many noob people run a webserver. But with shellshock they can
> > test this on their own machine, with just 1 line of code and see the
> > "vulnerable" message, so suddenly this is a big deal for them.
> > 
> > So, don't panic & stay cool, unless you have some badly configured
> > servers or have a habit of running everything on your workstation
> > without checking. But then you got bigger problems than this ;-).
> 
> Shellshock affects clients, including admins :)
> 
> Over DHCP you get instant root.
> 
> Over qmail local delivery, without any interaction
> you get the lusers $HOME and /var/mail and having
> in mind the state of current kernels the road
> to euid 0 is not very long.
> 
> It might affect some suid progies too.

Yeah, but that means the danger level is somewhere on the "client-side root" 
side, rather than "server-side root".

> AFAICT HB didn't allow code execution, just reading memory.

"Just" potentially reading plaintext passwords straight off of RAM, SSL/TLS 
certificates, GPG keys, etc., potentially (and demonstrably!) giving one a way 
not only to take over the given server, but to decrypt past saved 
communications with a given host, if the host used SSL without perfect forward 
secrecy.

Shellshock is more of a "personal client hygiene" kind of bug (a bad one, but 
still); HB was "we're *all* affected and fucked, change passwords NOW and hope 
for the best".

-- 
Pozdr
rysiek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 411 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140930/d8f1a181/attachment.sig>

From guninski at guninski.com  Tue Sep 30 04:25:28 2014
From: guninski at guninski.com (Georgi Guninski)
Date: Tue, 30 Sep 2014 14:25:28 +0300
Subject: How worse is the shellshock bash bug than Heartbleed?
In-Reply-To: <542A8661.7070904@gmail.com>
References: <20140930092602.GA2855@sivokote.iziade.m$>
 <CAHWD2rJAk6LH9=efwNTgyxXkc4uVhx8QQpHyr58Bw=Utze79Sg@mail.gmail.com>
 <542A8661.7070904@gmail.com>
Message-ID: <20140930112528.GB2855@sivokote.iziade.m$>

On Tue, Sep 30, 2014 at 12:30:57PM +0200, "Łukasz \"Cyber Killer\" Korpalski" wrote:
> W dniu 30.09.2014 o 11:55, Lodewijk andré de la porte pisze:
> > Heartbleed was a memory leak that eventually, after carefully calculated
> > exploiting, can lead to a remote root.
> > 
> > Shellshock depends on a lot of environmental details, but is possible
> > little more than a hard to reach shell with elevated permissions.
> > 
> > I guess heartbleed was actually worse. Who runs webscripts and stuff in
> > root? That's really foolhardy. But using OpenSSL ... We usually thought
> > it good practice!
> > 
> 
> Agree, heartbleed was a bigger problem, though I think I know why so
> many people panic because of this.
> 
> My theory is, with heartbleed most folks thought they were unaffected,
> cause not many noob people run a webserver. But with shellshock they can
> test this on their own machine, with just 1 line of code and see the
> "vulnerable" message, so suddenly this is a big deal for them.
> 
> So, don't panic & stay cool, unless you have some badly configured
> servers or have a habit of running everything on your workstation
> without checking. But then you got bigger problems than this ;-).
>

Shellshock affects clients, including admins :)

Over DHCP you get instant root.

Over qmail local delivery, without any interaction
you get the lusers $HOME and /var/mail and having
in mind the state of current kernels the road
to euid 0 is not very long.

It might affect some suid progies too.

AFAICT HB didn't allow code execution, just reading memory.






From rysiek at hackerspace.pl  Tue Sep 30 05:31:56 2014
From: rysiek at hackerspace.pl (rysiek)
Date: Tue, 30 Sep 2014 14:31:56 +0200
Subject: Firechat,
 this =?UTF-8?B?wqtmcmVlZG9tIG9mIHNwZWVjaC1hcHDCuw==?= is bogus
In-Reply-To: <542A99A1.6070107@fsfe.org>
References: <20140930142309.2fc19ac4@xalunon> <542A7A34.9070402@riseup.net>
 <542A99A1.6070107@fsfe.org>
Message-ID: <4037181.Rjf3TOrO40@lapuntu>

Dnia wtorek, 30 września 2014 14:53:05 Nikos Roussos pisze:
> On 09/30/2014 12:39 PM, Bethany wrote:
> > I'm mostly a lurker, too, but I'll remark that Firechat can't be bogus:
> > its use caught on in a massive way, and the ease of use and the P2P
> > connection feature is playing an active part in a community's SUCCESSFUL
> > self-organization in the face of real repression. While you're
> > absolutely right that an app can't call itself anonymous if it collects
> > Google Play information on its users, the question about whether the app
> > allows perfect anonymity isn't as important as: does the app allow
> > perfect anonymity from Beijing?
> 
> Well.. you can't be sure if you don't have the source code ;) (see below).
> 
> > I'd also point out that I believe Firechat is open source. And on
> > Github: https://github.com/firebase/firechat
> 
> I think that's a different app [1]. There is no mention for source code
> on the official website. [2]
> 
> [1] https://firechat.firebaseapp.com/
> [2] https://opengarden.com/firechat

Let me just add that a truly FLOSS and P2P Twitter replacement, Twister, got a 
huge number of new Chinese-speaking users during the last few days. Tags 
#occupycentral and #hkclassboycott are really active as far as what could be 
expected from a beta you have to compile yourself.

https://github.com/miguelfreitas/twister-core
http://twister.net.co/

You can search Twister from outside with this (warning: code unavailable, it's 
a 3rd-party service, might eat your dog, etc):
https://twisterio.com/

Examples:
https://twisterio.com/search?kw=hkclassboycott
https://twisterio.com/search?kw=occupycentral

-- 
Pozdr
rysiek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 411 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140930/49d12a96/attachment.sig>

From comzeradd at fsfe.org  Tue Sep 30 04:53:05 2014
From: comzeradd at fsfe.org (Nikos Roussos)
Date: Tue, 30 Sep 2014 14:53:05 +0300
Subject: Firechat, this =?UTF-8?B?wqtmcmVlZG9tIG9mIHNwZWVjaC1hcHDCuyBp?=
 =?UTF-8?B?cyBib2d1cw==?=
In-Reply-To: <542A7A34.9070402@riseup.net>
References: <20140930142309.2fc19ac4@xalunon> <542A7A34.9070402@riseup.net>
Message-ID: <542A99A1.6070107@fsfe.org>

On 09/30/2014 12:39 PM, Bethany wrote:
> I'm mostly a lurker, too, but I'll remark that Firechat can't be bogus:
> its use caught on in a massive way, and the ease of use and the P2P
> connection feature is playing an active part in a community's SUCCESSFUL
> self-organization in the face of real repression. While you're
> absolutely right that an app can't call itself anonymous if it collects
> Google Play information on its users, the question about whether the app
> allows perfect anonymity isn't as important as: does the app allow
> perfect anonymity from Beijing? 

Well.. you can't be sure if you don't have the source code ;) (see below).

> I'd also point out that I believe Firechat is open source. And on
> Github: https://github.com/firebase/firechat 

I think that's a different app [1]. There is no mention for source code
on the official website. [2]

[1] https://firechat.firebaseapp.com/
[2] https://opengarden.com/firechat


-- 
Nikos Roussos
http://www.roussos.cc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140930/6db9577f/attachment.sig>

From pgut001 at cs.auckland.ac.nz  Mon Sep 29 19:14:42 2014
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Tue, 30 Sep 2014 15:14:42 +1300
Subject: Bitcoin mining ASIC decapped
Message-ID: <E1XYmxe-0007wX-Ej@login01.fos.auckland.ac.nz>

In case anyone's interested, this site:

http://zeptobars.ru/en/read/bitfury-bitcoin-mining-chip

has some photos of what looks like a decapped Bitfury ASIC.  It's a pretty
unique structure...

Peter.




From l at odewijk.nl  Tue Sep 30 06:59:33 2014
From: l at odewijk.nl (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?=)
Date: Tue, 30 Sep 2014 15:59:33 +0200
Subject: How worse is the shellshock bash bug than Heartbleed?
In-Reply-To: <20140930132603.GC2855@sivokote.iziade.m$>
References: <20140930092602.GA2855@sivokote.iziade.m$>
 <542A8661.7070904@gmail.com>
 <20140930112528.GB2855@sivokote.iziade.m$>
 <17223152.OU4snMSJSA@lapuntu>
 <20140930132603.GC2855@sivokote.iziade.m$>
Message-ID: <CAHWD2rKQARd=9ucDORfsyqELFB3FiDafK_Wqah7rONXyuzPigA@mail.gmail.com>

On Sep 30, 2014 3:40 PM, "Georgi Guninski" <guninski at guninski.com> wrote:
>
> If I had a budget for buying sploits, I would
> pay much more for shockshell than for HB, might be wrong.

This is a really good metric. It instantly combines utility with potential
etc.

HB obtains you the root password, too. Maybe you have to wait for the admin
to log in, but still. It also doesn't leave a trace, which is neat.

HB gets you exploits for some very serious competitors. Shellshock only for
silly competition and, unless they're really silly, requires another
exploit for root.

So.. it depends! On too much. For me personally shellshock is an easier
exploit but heartbleed can be way more fun. Hmm... have to go with
heartbleed in the end. Real users often use the same password, so that'd
let me take open wifi users by surprise. If you'd want you can take
servers, even though it's a tease harder.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 1078 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/testlist/attachments/20140930/9e777197/attachment.txt>

From guninski at guninski.com  Tue Sep 30 06:26:03 2014
From: guninski at guninski.com (Georgi Guninski)
Date: Tue, 30 Sep 2014 16:26:03 +0300
Subject: How worse is the shellshock bash bug than Heartbleed?
In-Reply-To: <17223152.OU4snMSJSA@lapuntu>
References: <20140930092602.GA2855@sivokote.iziade.m$>
 <542A8661.7070904@gmail.com>
 <20140930112528.GB2855@sivokote.iziade.m$>
 <17223152.OU4snMSJSA@lapuntu>
Message-ID: <20140930132603.GC2855@sivokote.iziade.m$>

On Tue, Sep 30, 2014 at 02:24:44PM +0200, rysiek wrote:
> OHAI,
> 
> > Shellshock affects clients, including admins :)
> > 
> > Over DHCP you get instant root.
> > 
> > Over qmail local delivery, without any interaction
> > you get the lusers $HOME and /var/mail and having
> > in mind the state of current kernels the road
> > to euid 0 is not very long.
> > 
> > It might affect some suid progies too.
> 
> Yeah, but that means the danger level is somewhere on the "client-side root" 
> side, rather than "server-side root".
> 

Client side and server side are related.

Would you be comfortable to admin a server from
a rooted client? (I can offer you free shell to
ssh out of it ;).


> > AFAICT HB didn't allow code execution, just reading memory.
> 
> "Just" potentially reading plaintext passwords straight off of RAM, SSL/TLS 
> certificates, GPG keys, etc., potentially (and demonstrably!) giving one a way 
> not only to take over the given server, but to decrypt past saved 
> communications with a given host, if the host used SSL without perfect forward 
> secrecy.
> 
> Shellshock is more of a "personal client hygiene" kind of bug (a bad one, but 
> still); HB was "we're *all* affected and fucked, change passwords NOW and hope 
> for the best".
>

If I had a budget for buying sploits, I would
pay much more for shockshell than for HB, might
be wrong.

> -- 
> Pozdr
> rysiek





From guninski at guninski.com  Tue Sep 30 08:05:24 2014
From: guninski at guninski.com (Georgi Guninski)
Date: Tue, 30 Sep 2014 18:05:24 +0300
Subject: How worse is the shellshock bash bug than Heartbleed?
In-Reply-To: <CAHWD2rKQARd=9ucDORfsyqELFB3FiDafK_Wqah7rONXyuzPigA@mail.gmail.com>
References: <20140930092602.GA2855@sivokote.iziade.m$>
 <542A8661.7070904@gmail.com>
 <20140930112528.GB2855@sivokote.iziade.m$>
 <17223152.OU4snMSJSA@lapuntu>
 <20140930132603.GC2855@sivokote.iziade.m$>
 <CAHWD2rKQARd=9ucDORfsyqELFB3FiDafK_Wqah7rONXyuzPigA@mail.gmail.com>
Message-ID: <20140930150524.GD2855@sivokote.iziade.m$>

On Tue, Sep 30, 2014 at 03:59:33PM +0200, Lodewijk andré de la porte wrote:
> On Sep 30, 2014 3:40 PM, "Georgi Guninski" <guninski at guninski.com> wrote:
> >
> > If I had a budget for buying sploits, I would
> > pay much more for shockshell than for HB, might be wrong.
> 
> This is a really good metric. It instantly combines utility with potential
> etc.
> 
> HB obtains you the root password, too. Maybe you have to wait for the admin
> to log in, but still. It also doesn't leave a trace, which is neat.
> 

Is there a reference that HB _alone_ gets you the root password?
Maybe I am dumb, but don't see way to get the root password in
 sound setup even if I can ptrace() httpd.


> HB gets you exploits for some very serious competitors. Shellshock only for
> silly competition and, unless they're really silly, requires another
> exploit for root.
> 

Probably shellshock will give you root via DHCP and
for another root exploit you might try to shock suid stuff :)

On the web the myriads of buggy cgi's probably can compete
with shellshock, though it is more universal and allegedly
works for significant amount of daemons.


> So.. it depends! On too much. For me personally shellshock is an easier
> exploit but heartbleed can be way more fun. Hmm... have to go with
> heartbleed in the end. Real users often use the same password, so that'd
> let me take open wifi users by surprise. If you'd want you can take
> servers, even though it's a tease harder.




From coderman at gmail.com  Tue Sep 30 19:40:34 2014
From: coderman at gmail.com (coderman)
Date: Tue, 30 Sep 2014 19:40:34 -0700
Subject: Mu [was: How worse is the Shellshock bash bug than Heartbleed?]
Message-ID: <CAJVRA1Q1CVpS-QoWvV7QtN7OqPBa_ZdeJ4yGC=RRHN3DyM4E-g@mail.gmail.com>

On 9/30/14, Georgi Guninski <guninski at guninski.com> wrote:
> ...
> I find this _much_ worse than the passive Heartbleed.
>
> How worse is the shellshock bash bug than Heartbleed?


a simplistic "shellshock worse than heartbleed" is
mis-characterization of the situation.

first, this presents a vulnerability without context, by itself. in
the real world, we care about vulnerability with respect to
exploitation. usually many vulnerabilities are leveraged together in
exploitation of notoriety.

in the sense of best practice and conservative security posture,
heartbleed could be worse by far. a strongly keyed, defense in depth
surreptitiously bypassed via bleeding. e.g. bleed UDP DTLS VPN to
access internal network, bleed intranet HTTPS for admin credentials to
critical infrastructure services.

the ability to send things to a bash shell, even restricted shell,
even constrained behind  application layers, was always seen as bad
practice for security conscious configurations - insiders get shell,
not untrusted inputs.

last but not least, this is all bullshit speculation; risk is a
perspective and shellshock or heartbleed is better or worse depending
on what you're looking at.

best regards,


P.S. #langsec asked how long you earth humans will be exchanging risky
bits with strangers.  i channeled djb and bet on "Forever!". [c.f.
http://cr.yp.to/talks/2014.07.10/slides-djb-20140710-a4.pdf "Making
sure software stays insecure"]




From coderman at gmail.com  Tue Sep 30 21:06:46 2014
From: coderman at gmail.com (coderman)
Date: Tue, 30 Sep 2014 21:06:46 -0700
Subject: Offering free firmware rootkits perhaps even badBIOS
In-Reply-To: <509a1f5376f144106d9159547efcfd37@openmailbox.org>
References: <509a1f5376f144106d9159547efcfd37@openmailbox.org>
Message-ID: <CAJVRA1RyOaG-aV-DwoHW+POCbiwtC=wo=-ONLpr9sNLPEp96Ow@mail.gmail.com>

On 9/25/14, bluelotus at openmailbox.org <bluelotus at openmailbox.org> wrote:
> Want firmware rootkits, probably more sophisticated than FinFisher's,
> probably BadBiOS, emailed to you?


i think it is time to throw a malware party in a faraday hanger over a
weekend bender...

all in favor?


best only half joking regards,