- cypherpunks - lists.cpunks.org

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

Re: VMs without Administrator rights [was: Threat model: Parents]
by coderman 10 Jun '15

10 Jun '15

On 5/31/15, Barton Gellman <otr(a)riseup.net> wrote: > ... > * A virtual machine may be possible on the monitored host, if the required > drivers are already present. Probably not. See http://www.vbox.me/. If > anyone knows a VM that works without admin rights, speak up. in the Tor VM experiment from years back (2007) Qemu was used because it could be run as a restricted user once the Windown Tap and Pcap drivers were installed. throughput was poor, and this is the crux of a non-admin virtualization environment - performance demands privileges! less a problem for headless network appliances - a real big problem for interactive graphical user interfaces... best regards,

2 2

Re: [Cryptography] Proposed US ITAR changes would require prepublication approval for most crypto research
by Alfie John 10 Jun '15

10 Jun '15

Thanks for the comments Adrian. What concerns me is that from what I've seen, it only talks about Australian academics publishing novel ideas. What is completely missing is how these ammendments may affect Australian open source developers, who are also non-academics, working on cryptosystems. If they publish a novel cipher on GitHub without getting approval by DECO, is that a GOTO Jail card? Alfie On Wed, Jun 10, 2015, at 04:15 PM, 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. > > > 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 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: Alfie John Sent: ‎Wednesday‎, ‎10‎ ‎June‎ ‎2015 ‎1‎:‎54‎ ‎PM To: > Cryptography Mailing List, cypherpunks(a)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 > > > > > > 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? > > > > However, there is a great big kicker: posting ITAR technical data > > for the first time would be an export, and you wouldn't be allowed > > to do it without prior authorization [17]. > > > > Reposting already-posted technical data is also making it available, > > and you wouldn't be allowed to do that unless the initial posting > > was authorised. > > > > Neither would you be allowed to sell a book or magazine or > > periodical, even within the US, unless it had been made available > > with an authorisation [23]. > > > > Phil Zimmerman's trick, publishing the source to PGP in printed form > > to put it in the public domain, would no longer work. > > > > > > > > > > > > There is also some trickery about redefining software as an item, > > rather than as data; one effect of which is to put software which is > > the result of fundamental research into the control regime. > > > > Of course, as "fundamental research" only means research done in the > > US by US centers of learning, or US Government funded .. > > > > I get confused, but it would seem to me that eg if there is a crypto > > conference in the US with published proceedings, the publishers > > would need export permission for the work of foreign authors, but > > not the work of most US authors. > > > > > > > > > > > > [000] "Public domain" here is not the same thing as "public domain" > > in copyright law. The use the same words, but they are defined > > completely differently. > > > > [17] To get pernickity: data which has been made publicly > > available, including by widespread posting, would be exempt. > > > > However, data which hadn't been made available with proper > > authorisation would not be exempt. This would apply to data which is > > now in the public domain too. > > > > If you saw some posted data or data in a book, and you didn't > > actually know that it hadn't been released with proper > > authorisation, you couldn't be prosecuted for reposting it, or > > selling the books it was in. Though you could be prevented from > > doing it again, if someone told you its initial release has not been > > authorised. > > > > > > [23] the relevant bits: > > > > > > § 120.11 Public domain. > > > > (a) Except as set forth in paragraph (b) of this section, > > unclassified information and software are in the public domain, > > and are thus not technical data or software subject to the ITAR, > > when they have been made available to the public without > > restrictions upon their further dissemination such as through > > any of the following: > > > > (1) Subscriptions available without restriction to any individual > > who desires to obtain or purchase the published information; > > > > (2) Libraries or other public collections that are open and > > available to the public, and from which the public can obtain > > tangible or intangible documents; > > > > (3) Unlimited distribution at a conference, meeting, seminar, trade > > show, or exhibition, generally accessible to the interested > > public; > > > > (4) Public dissemination (i.e., unlimited distribution) in any form > > (e.g.,not necessarily in published form), including posting on > > the Internet on sites available to the public; or > > > > (5) Submission of a written composition, manuscript or presentation > > to domestic or foreign co-authors, editors, or reviewers of > > journals, magazines, newspapers or trade publications, or to > > organizers of open conferences or other open gatherings, with > > the intention that the compositions, manuscripts, or > > publications will be made publicly available if accepted for > > publication or presentation. > > > > > > (b) Technical data or software,whether or not developed with > > government funding, is not in the public domain if it has been > > made available to the public without authorization from: > > > > (1) The Directorate of Defense Trade Controls; > > > > (2) The Department of Defense’s Office of Security Review; > > > > (3) The relevant U.S. government contracting entity with authority > > to allow the technical data or software to be made available to > > the public; or > > > > (4) Another U.S. government official with authority to allow the > > technical data or software to be made available to the public. > > > > > > > > § 127.1 Violations. [...] > > (6) To export, reexport, retransfer, or otherwise make available to > > the public technical data or software if such person has > > knowledge that the technical data or software was made publicly > > available without an authorization described in § 120.11(b) of > > this subchapter. > > > > > > > > > > > > ps: there is yet another ITAR change on the way about exploits and > > technical data concerning security and hacking tools. see eg; > > http://www.theregister.co.uk/2015/06/06/whats_up_with_wassenaar/ > > > > -- Peter Fairbrother > > > > _______________________________________________ > > The cryptography mailing list cryptography(a)metzdowd.com > > http://www.metzdowd.com/mailman/listinfo/cryptography > > > -- > Alfie John alfiej(a)fastmail.fm > _______________________________________________ > The cryptography mailing list cryptography(a)metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography -- Alfie John alfiej(a)fastmail.fm

1 0

Encryption article from Yahoo
by jim bell 10 Jun '15

10 Jun '15

By Richard CowanWASHINGTON (Reuters) - As Washington weighs new cybersecurity steps amid a public backlash over mass surveillance, U.S. tech companies warned President Barack Obama not to weaken increasingly sophisticated encryption systems designed to protect consumers' privacy.In a strongly worded letter to Obama on Monday, two industry associations for major software and hardware companies said, "We are opposed to any policy actions or measures that would undermine encryption as an available and effective tool."The Information Technology Industry Council and the Software and Information Industry Association, representing tech giants, including Apple Inc, Google Inc, Facebook Inc, IBM and Microsoft Corp, fired the latest salvo in what is shaping up to be a long fight over government access into smart phones and other digital devices.Obama administration officials, led by the FBI, have pushed the companies to find ways to let law enforcement bypass encryption to investigate illegal activities, including terrorism threats, but not weaken it so that criminals and computer hackers could penetrate the defenses.So far, however, the White House has not spelled out specific regulatory or legislative steps it might seek.View gallery Some cybersecurity experts are skeptical that Congress will take legislative action to expand the administration's powers anytime soon, noting recent lopsided votes in the House of Representatives to rein in surveillance.White House spokesman Josh Earnest, responding to Reuters' inquiries, said the administration "firmly supports the development and robust adoption of strong encryption."But he added there were concerns about "the use of encryption by terrorists and other criminals to conceal and enable crimes and other malicious activity."FBI'S INTENTIONS KEYKate Martin, director of the Center for National Security Studies, a civil liberties watchdog group, said, "The ultimate question is whether the FBI is going to seek legislation that would put limits on development of encryption tools."View gallery The Obama administration is in the midst of an internal debate on the matter. Martin said the recent naming of Ed Felten, a computer science and public affairs expert, as deputy U.S. chief technology officer was an indication that Obama "takes seriously the privacy concerns."But at the same time, she noted, "Technology, and especially the globalization of communications, has outpaced U.S. law."The debate over whether there should be limits on encryption should include the question of whether there should be limits on when the government can lawfully get access to people's private information, Martin said.The industry letter to Obama also was sent to FBI Director James Comey, Homeland Security Secretary Jeh Johnson, Attorney General Loretta Lynch and other Cabinet heads.Days earlier, the United States enacted legislation that will curtail the government's ability to scoop up huge volumes of data related to records of Americans' telephone calls.View gallery At the same time, Washington is being battered by computer hacks. Last week a massive breach was disclosed at the U.S. Office of Personnel Management, with records of up to 4 million current and former federal employees possibly compromised.An explosion in government surveillance was an outgrowth of the Sept. 11, 2001, attacks on the United States and was exposed by former National Security Agency contractor Edward Snowden.The industry groups noted that online commerce has flourished in part because consumers believed their payment information would be secure."Consumer trust in digital products and services is an essential component enabling continued economic growth of the online marketplace," the industry wrote."Accordingly, we urge you not to pursue any policy or proposal that would require or encourage companies to weaken these technologies, including the weakening of encryption or creating encryption 'work-arounds'."(Additional reporting by Roberta Rampton; Editing by Kevin Drawbaugh and Tom Brown)

1 0

Re: [Cryptography] Proposed US ITAR changes would require prepublication approval for most crypto research
by Alfie John 10 Jun '15

10 Jun '15

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 > > > 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? > > However, there is a great big kicker: posting ITAR technical data for > the first time would be an export, and you wouldn't be allowed to do > it without prior authorization [17]. > > Reposting already-posted technical data is also making it available, > and you wouldn't be allowed to do that unless the initial posting was > authorised. > > Neither would you be allowed to sell a book or magazine or periodical, > even within the US, unless it had been made available with an > authorisation [23]. > > Phil Zimmerman's trick, publishing the source to PGP in printed form > to put it in the public domain, would no longer work. > > > > > > There is also some trickery about redefining software as an item, > rather than as data; one effect of which is to put software which is > the result of fundamental research into the control regime. > > Of course, as "fundamental research" only means research done in the > US by US centers of learning, or US Government funded .. > > I get confused, but it would seem to me that eg if there is a crypto > conference in the US with published proceedings, the publishers would > need export permission for the work of foreign authors, but not the > work of most US authors. > > > > > > [000] "Public domain" here is not the same thing as "public domain" in > copyright law. The use the same words, but they are defined > completely differently. > > [17] To get pernickity: data which has been made publicly available, > including by widespread posting, would be exempt. > > However, data which hadn't been made available with proper > authorisation would not be exempt. This would apply to data which is > now in the public domain too. > > If you saw some posted data or data in a book, and you didn't actually > know that it hadn't been released with proper authorisation, you > couldn't be prosecuted for reposting it, or selling the books it was > in. Though you could be prevented from doing it again, if someone told > you its initial release has not been authorised. > > > [23] the relevant bits: > > > § 120.11 Public domain. > > (a) Except as set forth in paragraph (b) of this section, unclassified > information and software are in the public domain, and are thus > not technical data or software subject to the ITAR, when they have > been made available to the public without restrictions upon their > further dissemination such as through any of the following: > > (1) Subscriptions available without restriction to any individual who > desires to obtain or purchase the published information; > > (2) Libraries or other public collections that are open and available > to the public, and from which the public can obtain tangible or > intangible documents; > > (3) Unlimited distribution at a conference, meeting, seminar, trade > show, or exhibition, generally accessible to the interested > public; > > (4) Public dissemination (i.e., unlimited distribution) in any form > (e.g.,not necessarily in published form), including posting on the > Internet on sites available to the public; or > > (5) Submission of a written composition, manuscript or presentation to > domestic or foreign co-authors, editors, or reviewers of journals, > magazines, newspapers or trade publications, or to organizers of > open conferences or other open gatherings, with the intention that > the compositions, manuscripts, or publications will be made > publicly available if accepted for publication or presentation. > > > (b) Technical data or software,whether or not developed with > government funding, is not in the public domain if it has been > made available to the public without authorization from: > > (1) The Directorate of Defense Trade Controls; > > (2) The Department of Defense’s Office of Security Review; > > (3) The relevant U.S. government contracting entity with authority to > allow the technical data or software to be made available to the > public; or > > (4) Another U.S. government official with authority to allow the > technical data or software to be made available to the public. > > > > § 127.1 Violations. [...] > (6) To export, reexport, retransfer, or otherwise make available to > the public technical data or software if such person has knowledge > that the technical data or software was made publicly available > without an authorization described in § 120.11(b) of this > subchapter. > > > > > > ps: there is yet another ITAR change on the way about exploits and > technical data concerning security and hacking tools. see eg; > http://www.theregister.co.uk/2015/06/06/whats_up_with_wassenaar/ > > -- Peter Fairbrother > > _______________________________________________ > The cryptography mailing list cryptography(a)metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography -- Alfie John alfiej(a)fastmail.fm

1 0

Re: Threat Model: Parents
by Softy 09 Jun '15

09 Jun '15

Arguably a category of child which would benefit from a concerned adults supervision. I would never assert an alcoholic should choose a bar as their favourite hangout - nor would I claim they have no right to choose to do so. However, I would assert (to the alcoholic) they would be better off going to said bar with a helpful supervisor/friend. > Their specific situation is that they're about 15, autistic and bipolar, > > >

11 22

IMEI changed - any RTL-SDR sniff way to check it was properly changed?
by Virilha 05 Jun '15

05 Jun '15

Due to the recent events envolving planes and FBI, I was wondering. Changing SIMs (so IMSI) is an easy task. Change IMEI with some knowledge I believe its too. There are some tutorials on IMEI changing on rooted android, I dont known if actually works, suppose yes: http://www.technostall.com/how-to-change-imei-number-android/ http://www.plusdroid.com/Blogandnews/how-to-change-restore-imei-no-on-andro… Knowing we can get TMSI / IMSI (sometimes) via RTL-SDR software + proper dongles: http://www.rtl-sdr.com/rtl-sdr-cell-phone-imsi-tmsi-key-sniffer/ https://ferrancasanovas.wordpress.com/cracking-and-sniffing-gsm-with-rtl-sd… And knowing the IMEI is used / exchanged with the network before authentication is granted to a certain phone (network can block IMEIs, so they are sent/exchanged) Do someone know if is it possible to check if the original IMEI was really changed and is not being exchanged with the provider, by using RTL-SDR + proper device to sniff the frequency? http://www.rtl-sdr.com/ regards, --Virilha

1 0