- cypherpunks - lists.cpunks.org

FUCK jargon! [was Re: črypto is finished... and it's about time × (also: 'Balrog' malnet, firsthand view)]
by coderman 13 Jun '15

13 Jun '15

On 6/11/15, Seth <list(a)sysfu.com> wrote: >... a broader paper describing a global > surveillance technology we have dubbed Corruptor-Injector Networks why? FUCK jargon!

4 3

on many links [was Re: črypto is finished... and it's about time × (also: 'Balrog' malnet, firsthand view)]
by coderman 12 Jun '15

12 Jun '15

On 6/12/15, Zenaan Harkness <zen(a)freedbms.net> wrote: > ... > I am confident that local off-net PHY connections can go a long way to > increasing anonymity provided by anonymizing P2P networks - it's an > avenue unfortunately untapped, and even more so, not yet studied > academically. you need to remove some obstacles, like in-order delivery, and add some defenses, perhaps optimized dependent link padding and stochastic shaping. but the evidence is there, from the mesh network days - see multi-radio AODV optimizations highlighting the benefit of concurrent possible paths... then, as ever, the quintessential station wagon full of backup tape, "propinquitous discovery", "propinquitous delivery", best regards,

1 0

Helmholtz Tubes, CRT Signals (Was: Sigint Dumps)
by Wilfred Guerin 12 Jun '15

12 Jun '15

Helmholtz Tube, Beam Steering, EM field interaction, simple field dynamics, (and your oscilliscope) are all you need to create complex EM signals processors. No different than your antique crypto cracker, which uses an abstract field to solve complex pre-defined systems. "56-bit" https cracker was mass implemented as a 300mhz backplane EM field solver about the size of your desktop computer. Using the same technology, resolution, and methods, BTC Bitcoins are around 8m^3 of field to solve. No doubt the access and decoding to these sigint signals requires similar proessing before being steered to the digitiser. (Maxwell Tube, Helmholtz Tube, typical of high school physics classrooms)

4 4

[tor-talk] Additional hop before connecting to Tor
by Eugen Leitl 12 Jun '15

12 Jun '15

----- Forwarded message from dtm168(a)openmailbox.org ----- Date: Thu, 11 Jun 2015 13:52:40 +0200 From: dtm168(a)openmailbox.org To: tor-talk(a)lists.torproject.org Subject: [tor-talk] Additional hop before connecting to Tor Message-ID: <2a8f8c25121cbad6b4575ce5ddcd3d57(a)openmailbox.org> User-Agent: Roundcube Webmail/1.0.5 Reply-To: tor-talk(a)lists.torproject.org Hi, You often read that the fact you are using Tor is being monitored by the various intelligence services. I guess this works by recording which IP addresses connect to known entry relays and/or directory authorities. Since you usually also connect to facebook or gmail your identity can be easily linked to Tor usage. This is especially true if you have a static IP address. Currently I use a virtual server in a foreign country which I pay with Bitcoin. I use an ssh tunnel which I use to make connections to Tor, i.e. intelligence service see the IP of my server which connects to known Tor IP addresses. 1. How likely is it that they look at connecting IP addresses to my server (and identify me)? Probably very likely. Would it help to have an additional anon server as an additional hop to Tor? 2. Tor traffic has these characteristic traffic signatures (packet size, timings of packets when idle). Would these also "shine through" the ssh tunnel? 3. I guess making that server a private bridge will be worse than using ssh because of these typical Tor traffic patterns. 4. I am also afraid of running a Tor relay on my home internet connections because all members of my family who share that IP will be flagged as Tor users... I am interested to hear your opinions. Cheers, dtm168 -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message -----

2 1

Videos and slides for "Security in Times of Surveillance" 2015
by Seth 11 Jun '15

11 Jun '15

Some excellent talks by some of my favorite technical people, recommended viewing. https://projectbullrun.org/surveillance/2015/video-2015.html

1 0

Re: Helmholtz Tubes, CRT Signals (Was: Sigint Dumps)
by John Young 11 Jun '15

11 Jun '15

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

1 0

Best practice for safe viewing of PDFs posted to list
by Seth 11 Jun '15

11 Jun '15

Links to PDFs are not uncommon on this list but I never feel good about opening them up. Is the advice in this 2010 article still relevant? [1] ...How can you protect yourself from their inherent vulnerabilities? Hypponen suggests you completely avoid opening PDFs on your local machine, instead viewing them through Google Docs. If you're using Chrome, Firefox, or Opera, you can install the gPDF plug-in to automate the process for web-based PDFs. For your local files, he suggests you "use a PDF reader that's as unpopular as possible. The fewer users a product has, the less attacks it will attract."... I usually use an open source reader like muPDF on SumatraPDF in a VM, but it's a hassle. Curious if the advice given above is still relevant and also what other on the list recommend for safe viewing of PDFs. [1] http://www.pcmag.com/article2/0,2817,2362356,00.asp

4 4

Re: [Cryptography] Proposed US ITAR changes would require prepublication approval for most crypto research
by Peter Fairbrother 11 Jun '15

11 Jun '15

On 10/06/15 07:36, Adrian McCullagh wrote: > Dear All, > > I with 4 colleagues of mine (3 at the Queensland University of > Technology (Cryptographers all)and one from the University of > Queensland (Legal E-commerce researcher) have been working on a paper > dealing with the Australian Defence Trade Control Act which corresponds > to the proposed US ITAR changes. Sounds interesting, They are basically trying to reintroduce the "born secret" principle, which in US law exists only in an unchallenged part of the Atomic Energy Act; though that concept has not been tested against First Amendment rights as the only previous case of note (United States v. The Progressive, 1979) was dropped by the Government before it reached the Supreme Court. But it's "born again secret" as well as "born secret, again" - it applies to all previous technical data, whether widely disseminated or not. -- Peter Fairbrother > > Without giving everything away on our forthcoming paper, it appears to > me that if this type of regulation had been in place in Germany in 1938, > then it is highly likely that Einstein would never have read the Hahn - > Strassmann paper dealing with splitting a uranium atom. That paper > written in 1938 (December I believe) was read by Einstein in March 1939 > and it directly lead to Einstein sending a letter to Roosevelt, which in > turn resulted in 1942 to the establishment of the Manhattan project. > Now if NAZI Germany had restricted that publication NAZI Germany could > have developed the bomb itself which could have completely altered the > outcome. > > Basically, if regimes like the DCTA/ITAR rules are expanded then it > works both ways and there could be a stifling of publication research > due to bureaucratic mishandling. Though it could assist in the spy > business as in the cold war. > > > Dr. Adrian McCullagh > Ph.D. LL.B.(Hons) B. App. Sc. (Computing) > ODMOB Lawyers > Mobile 0401 646 486 > Skype. Admac57 > E: ajmccullagh57(a)gmail.com > E: amccullagh(a)live.com > The contents of this email are confidential between the sender and the > intended recipient. If you are not the intended recipient then no rights > are granted to you because of this error and as such you are requested > to promptly inform the sender of the error and to promptly destroy all > copies of the email in your power, possession or control. The sender > reserves all rights concerning this email and its contents including any > privilege, copyright and confidentiality associated with this email. > Even though an email signature block has been appended to this email, > and notwithstanding the Electronic Transactions Act (Qld) or the > Electronic Transactions Act (Cth), the signature block does not exhibit > the senders intention to be bound by an offer previously sent by the > intended recipient, unless the email in its body specifically indicated > that the sender hereby accepts such an offer previously sent by the > intended recipient. > > *From:* alfiej(a)fastmail.fm <mailto:alfiej@fastmail.fm> > *Sent:* ‎Wednesday‎, ‎10‎ ‎June‎ ‎2015 ‎1‎:‎54‎ ‎PM > *To:* Cryptography Mailing List <mailto:cryptography@metzdowd.com>, > cypherpunks(a)cpunks.org <mailto:cypherpunks@cpunks.org> > > Snap, from Australia: > > http://www.smh.com.au/it-pro/security-it/dangerous-minds-are-maths-teachers… > > "Australian academics who teach mathematics may need to run new > ideas by the Department of Defence before sharing them or risk > imprisonment. > > Some academics are set to become much more familiar with the > department's Defence Export Control Office (DECO), a unit that > enforces the Defence Trade Control Act 2012, Australia's end of a > 2007 pact with the US and UK over defence trade. > > Until recently, DECO only regulated physically exported weapons and > so-called "dual use" items such as encryption, computing hardware > and biological matter. > > However in March the act was updated to include "intangible supply", > which is intended to prohibit the transfer of knowledge from > Australia that could be used to produce weapons." > > Alfie > > On Tue, Jun 9, 2015, at 05:36 PM, pete wrote: > > Proposed US ITAR changes. New regs, for comment, not yet in law or > > in force. > > > > > http://www.washingtonexaminer.com/nra-gun-blogs-videos-web-forums-threatene… > > > > www.gpo.gov/fdsys/pkg/FR-2015-06-03/pdf/2015-12844.pdf > <http://www.gpo.gov/fdsys/pkg/FR-2015-06-03/pdf/2015-12844.pdf> > > > > > > Actually, it says, for the first time explicitly, that publishing > > widely on the internet would be enough to put data into the > > public domain > > [000]. Sounds good? > > > www.metzdowd.com/mailman/listinfo/cryptography > <http://www.metzdowd.com/mailman/listinfo/cryptography> > > > _______________________________________________ > The cryptography mailing list > cryptography(a)metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography >

1 0

Fwd: [Cryptography] Did Intel just execute its warrant canary ?
by grarpamp 10 Jun '15

10 Jun '15

---------- Forwarded message ---------- From: Henry Baker <hbaker1(a)pipeline.com> Date: Mon, Jun 8, 2015 at 6:24 PM Subject: [Cryptography] Did Intel just execute its warrant canary ? To: cryptography(a)metzdowd.com FYI -- I conjecture that the second GPU story following less than one month after the first GPU story is not just coincidence, but one of the requirements of a secret National Security Letter to Intel. The first story shows how GPU's can house malware, while the second story explains that Intel won't be sharing its GPU code where such malware will be housed. "no reverse engineering, decompilation, or disassembly of this software is permitted" As feared, the DMCA will be used against those who attempt to look for this malware in Intel GPU's. https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act -------- http://arstechnica.com/security/2015/05/gpu-based-rootkit-and-keylogger-off… GPU-based rootkit and keylogger offer superior stealth and computing power Proof-of-concept malware may pave the way for future in-the-wild attacks. by Dan Goodin - May 7, 2015 3:43 pm UTC Developers have published two pieces of malware that take the highly unusual step of completely running on an infected computer's graphics card, rather than its CPU, to enhance their stealthiness and give them increased computational abilities. Both the Jellyfish rootkit and the Demon keylogger are described as proofs-of-concept by their pseudo-anonymous developers, whom Ars was unable to contact. Tapping an infected computer's GPU allows malware to run without the usual software hooks or modifications malware makes in the operating system kernel. Those modifications can be dead giveaways that a system is infected. https://github.com/x0r1/jellyfish https://github.com/x0r1/Demon Here's how the developers describe their rootkit: Jellyfish is a Linux based userland gpu rootkit proof of concept project utilizing the LD_PRELOAD technique from Jynx (CPU), as well as the OpenCL API developed by Khronos group (GPU). Code currently supports AMD and NVIDIA graphics cards. However, the AMDAPPSDK does support Intel as well. Advantages of gpu stored memory: * No gpu malware analysis tools available on web * Can snoop on cpu host memory via DMA * Gpu can be used for fast/swift mathematical calculations like xor'ing or parsing * Stubs * Malicious memory is still inside gpu after shutdown Requirements for use: * Have OpenCL drivers/icds installed * Nvidia or AMD graphics card (intel supports amd's sdk) * Change line 103 in rootkit/kit.c to server ip you want to monitor gpu client from Stay tuned for more features: * client listener; let buffers stay stored in gpu until you send magic packet from server Disclaimer: Educational purposes only; authors of this project/demonstration are in no way, shape or form responsible for what you may use this for whether illegal or not. They provide no technical details about Demon keylogger other than to say it's a proof-of-concept that implements the malware described in this 2013 academic research paper titled You Can Type, but You Can’t Hide: A Stealthy GPU-based Keylogger. The Demon creators stress that they aren't associated with the researchers. http://www.cs.columbia.edu/~mikepo/papers/gpukeylogger.eurosec13.pdf "The key idea behind our approach is to monitor the system’s keyboard buffer directly from the GPU via DMA [direct memory access], without any hooks or modifications in the kernel's code and data structures besides the page table," the researchers behind the 2013 paper wrote. "The evaluation of our prototype implementation shows that a GPU-based keylogger can effectively record all user keystrokes, store them in the memory space of the GPU, and even analyze the recorded data in-place, with negligible runtime overhead." Aside from malware that taps GPUs to mint Bitcoin and other crypto currencies, Ars isn't aware of malicious software actively circulating in the wild that makes use of infected computers' graphics processors. And even then, most or all of those titles run mainly on the CPU and offload only the computationally intensive workloads to the GPU. In March, researchers from Kaspersky Lab documented highly sophisticated malware in the wild that infected firmware that runs 12 different models of hard drives. The group that created the malware had flown under the radar for 14 years. In its current form Jellyfish is likely to remain a highly niche undertaking, since it requires a dedicated GPU. Since many computers don't contain stand-alone graphics cards, such malware might greatly limit the machines that could be infected. Still, the approach may make sense in certain situations, say for attackers targeting gamers or video enthusiasts, or espionage campaigns where stealth is crucial. And as readers have pointed out in comments below, it's feasible malware could be developed that runs on graphics processors integrated into CPUs. Post updated to recast the last paragraph to account for integrated graphics processors, and to add details in the second-to-last paragraph about malware infecting hard-drive firmware. ---------------- https://www.phoronix.com/scan.php?page=news_item&px=Intel-SKL-BXT-Firmware-… Intel Skylake & Broxton To Require Graphics Firmware Blobs Published on 05 June 2015 06:20 PM EDT Written by Michael Larabel in Intel Intel's upcoming Skylake and Broxton hardware will require some binary-only firmware blobs by the i915 DRM kernel graphics driver. Rodrigo Vivi of Intel's Open-Source Technology Center sent in the pull request for landing these binary files into the linux-firmware repository. Up to now there's been no i915 blobs within the linux-firmware tree. These first i915 DRM firmware blobs are for Skylake and Broxton for the GuC and DMC. DMC in this context is the Display Microcontroller, which is present in Skylake (Gen9) and newer and used within the display engine to save and restore its state when entering into low-power states and then resuming. The DMC is basically saving/restoring display registers across low-power states separate of the kernel. The GuC engine on Skylake is responsible for workload scheduling on the parallel graphics engines. Intel explained on 01.org, "GuC is designed to perform graphics workload scheduling on the various graphics parallel engines. In this scheduling model, host software submits work through one of the 256 graphics doorbells and this invokes the scheduling operation on the appropriate graphics engine. Scheduling operations include determining which workload to run next, submitting a workload to a command streamer, pre-empting existing workloads running on an engine, monitoring progress and notifying host SW when work is done." This page also seems to indicate that these firmware blobs are required by the DRM driver rather than being an optional add-on. The license of these firmware blobs also indicate that redistribution is only allowed in binary form without modification. Beyond that, "no reverse engineering, decompilation, or disassembly of this software is permitted." These new firmware blobs will certainly have some open-source enthusiasts less excited now about Skylake, Broadwell's successor beginning to ship later this year, and Broxton meanwhile is the new Atom SoC built using the Goldmont architecture and will feature Skylake graphics. If there's any good news out of the situation, at least Intel is shipping these firmware files early rather than NVIDIA that with their months-old hardware still hasn't released their GTX 900 Maxwell firmware files needed by the Nouveau driver to provide open-source hardware acceleration. AMD also tends to be timely with the releasing of their necessary binary-only GPU firmware files for the open-source Linux driver. _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

5 6

The_Mystery_of_Duqu_2_0_a_sophisticated_cyberespionage_actor_returns [ED: duqu continued; they never left! ]
by coderman 10 Jun '15

10 Jun '15

https://securelist.com/files/2015/06/The_Mystery_of_Duqu_2_0_a_sophisticate…

1 0