February 2015 - cypherpunks - lists.cpunks.org

Fwd: [Cryptography] trojans in the firmware
by grarpamp 23 Feb '15

23 Feb '15

> http://www.recover.co.il/SA-cover/SA-cover.pdf Since the firmware rules over everything, all the spare sectors for block reallocation must be considered too, not just the service areas. Then there is the per sector CRC space that could perhaps be reutilized if CRC is implemented as software function. Kernel options to permit only your approved list of opcodes and block all else by default would seem useful to have. > http://www.spiegel.de/media/media-35661.pdf Again, look at the list of Unix operating systems and file systems. These guys are calling Unix out by name, and soon the common script kid will be too. Unix is under attack and this stuff can't be ignored as "too rare and/or hard and/or low market share to be relavent" anymore. ---------- Forwarded message ---------- Date: Mon, Feb 23, 2015 at 12:10 PM Subject: Re: [Cryptography] trojans in the firmware FYI -- CMU has been hacking disk drive firmware since the 1990's for "smart disks" and "performance"; UCSD has been hacking flash drive firmware more recently. I believe that DARPA has also openly solicited for disk drive/flash drive firmware hacking capabilities. Both CMU & UCSD are hotbeds of NSA recruitment activity. We now know that in NSA parlance "smart" anything = "spying" anything; e.g., "smart disks" = "spying disks"; "smart phones" = "spying phones", etc. BTW, hiding stuff in a flash memory stick is even easier than in a hard drive. This is because flash memory is so unreliable, that there is typically a huge percentage of unused space; the cheaper the flash memory, the smaller the fraction of usable reliable memory space. So it wouldn't be at all surprising to find that your 32GB flash drive is really constructed from 64GB chips, and that 50% of the device is unavailable for use. It is highly unlikely that _all_ of this unused space is unreliable, so this leaves plenty of room for NSA lurking. But even if the device were 100% reliable, noticing that only 50% was actually in use would be unremarkable, given the typical degree of unreliability of these types of devices. For these reasons, it is critical for flash memory devices to _open up_ their API's, so that the raw memory (with all of its warts) can be inspected and verified. http://www.wired.com/2015/02/nsa-firmware-hacking/ How the NSA’s Firmware Hacking Works and Why It’s So Unsettling By Kim Zetter 02.22.15 8:09 pm One of the most shocking parts of the recently discovered spying network Equation Group is its mysterious module designed to reprogram or reflash a computer hard drive’s firmware with malicious code. The Kaspersky researchers who uncovered this said its ability to subvert hard drive firmware—-the guts of any computer—-“surpasses anything else” they had ever seen. The hacking tool, believed to be a product of the NSA, is significant because subverting the firmware gives the attackers God-like control of the system in a way that is stealthy and persistent even through software updates. The module, named “nls_933w.dll”, is the first of its kind found in the wild and is used with both the EquationDrug and GrayFish spy platforms Kaspersky uncovered. It also has another capability: to create invisible storage space on the hard drive to hide data stolen from the system so the attackers can retrieve it later. This lets spies like the Equation Group bypass disk encryption by secreting documents they want to seize in areas that don’t get encrypted. Kaspersky has so far uncovered 500 victims of the Equation Group, but only five of these had the firmware-flashing module on their systems. The flasher module is likely reserved for significant systems that present special surveillance challenges. Costin Raiu, director of Kaspersky’s Global Research and Analysis Team, believes these are high-value computers that are not connected to the internet and are protected with disk encryption. Here’s what we know about the firmware-flashing module. How It Works Hard drive disks have a controller, essentially a mini-computer, that includes a memory chip or flash ROM where the firmware code for operating the hard drive resides. When a machine is infected with EquationDrug or GrayFish, the firmware flasher module gets deposited onto the system and reaches out to a command server to obtain payload code that it then flashes to the firmware, replacing the existing firmware with a malicious one. The researchers uncovered two versions of the flasher module: one that appears to have been compiled in 2010 and is used with EquatinoDrug and one with a 2013 compilation date that is used with GrayFish. The Trojanized firmware lets attackers stay on the system even through software updates. If a victim, thinking his or her computer is infected, wipes the computer’s operating system and reinstalls it to eliminate any malicious code, the malicious firmware code remains untouched. It can then reach out to the command server to restore all of the other malicious components that got wiped from the system. Even if the firmware itself is updated with a new vendor release, the malicious firmware code may still persist because some firmware updates replace only parts of the firmware, meaning the malicious portions may not get overwritten with the update. The only solution for victims is to trash their hard drive and start over with a new one. The attack works because firmware was never designed with security in mind. Hard disk makers don’t cryptographically sign the firmware they install on drives the way software vendors do. Nor do hard drive disk designs have authentication built in to check for signed firmware. This makes it possible for someone to change the firmware. And firmware is the perfect place to conceal malware because antivirus scanners don’t examine it. There’s also no easy way for users to read the firmware and manually check if it’s been altered. The firmware flasher module can reprogram the firmware of more than a dozen different hard drive brands, including IBM, Seagate, Western Digital, and Toshiba. “You know how much effort it takes to land just one firmware for a hard drive? You need to know specifications, the CPU, the architecture of the firmware, how it works,” Raiu says. The Kaspersky researchers have called it “an astonishing technical accomplishment and is testament to the group’s abilities.” Once the firmware is replaced with the Trojanized version, the flasher module creates an API that can communicate with other malicious modules on the system and also access hidden sectors of the disk where the attackers want to conceal data they intend to steal. They hide this data in the so-called service area of the hard drive disk where the hard disk stores data needed for its internal operation. Hidden Storage Is the Holy Grail The revelation that the firmware hack helps store data the attackers want to steal didn’t get much play when the story broke last week, but it’s the most significant part of the hack. It also raises a number of questions about how exactly the attackers are pulling this off. Without an actual copy of the firmware payload that gets flashed to infected systems, there’s still a lot that’s unknown about the attack, but some of it can be surmised. The ROM chip that contains the firmware includes a small amount of storage that goes unused. If the ROM chip is 2 megabytes, the firmware might take up just 1.5 megabytes, leaving half a megabyte of unused space that can be employed for hiding data the attackers want to steal. This is particularly useful if the computer has disk encryption enabled. Because the EquationDrug and GrayFish malware run in Windows, they can grab a copy of documents while they’re unencrypted and save them to this hidden area on the machine that doesn’t get encrypted. There isn’t much space on the chip for a lot of data or documents, however, so the attackers can also just store something equally as valuable to bypass encryption. “Taking into account the fact that their GrayFish implant is active from the very boot of the system, they have the ability to capture the encryption password and save it into this hidden area,” Raiu says. Authorities could later grab the computer, perhaps through border interdiction or something the NSA calls “customs opportunities,” and extract the password from this hidden area to unlock the encrypted disk. http://cryptome.org/2014/05/nsa-customs.htm Raiu thinks the intended targets of such a scheme are limited to machines that are not connected to the internet and have encrypted hard drives. One of the five machines they found hit with the firmware flasher module had no internet connection and was used for special secure communications. “[The owners] only use it in some very specific cases where there is no other way around it,” Raiu says. “Think about Bin Laden who lived in the desert in an isolated compound—-doesn’t have internet and no electronic footprint. So if you want information from his computer how do you get it? You get documents into the hidden area and you wait, and then after one or two years you come back and steal it. The benefits [of using this] are very specific.” Raiu thinks, however, that the attackers have a grander scheme in mind. “In the future probably they want to take it to the next level where they just copy all the documents [into the hidden area] instead of the password. [Then] at some point, when they have an opportunity to have physical access to the system, they can then access that hidden area and get the unencrypted docs.” They wouldn’t need the password if they could copy an entire directory from the operating system to the hidden sector for accessing later. But the flash chip where the firmware resides is too small for large amounts of data. So the attackers would need a bigger hidden space for storage. Luckily for them, it exists. There are large sectors in the service area of the hard drive disk that are also unused and could be commandeered to store a large cache of documents, even ones that might have been deleted from other parts of the computer. This service area, also called the reserved are or system area, stores the firmware and other data needed to operate drives, but it also contains large portions of unused space. An interesting paper (.pdf) published in February 2013 by Ariel Berkman, a data recovery specialist at the Israeli firm Recover, noted “not only that these areas can’t be sanitized (via standard tools), they cannot be accessed via anti-virus software [or] computer forensics tools.” http://www.recover.co.il/SA-cover/SA-cover.pdf Berkman points out that one particular model of Western Digital drives has 141 MB reserved for the service area, but only uses 12 MB of this, leaving the rest free for stealth storage. To write or copy data to service area requires special commands that are specific to each vendor and are not publicly documented, so an attacker would need to uncover what these are. But once they do, “[b]y sending Vendor Specific Commands (VSCs) directly to the hard-drive, one can manipulate these [service] areas to read and write data that are otherwise inaccessible,” Berkman writes. It is also possible, though not trivial, to write a program to automatically copy documents to this area. Berkman himself wrote a proof-of-concept program to read and write a file of up to 94 MB to the service area, but the program was a bit unstable and he noted that it could cause some data loss or cause the hard drive to fail. One problem with hiding large amounts of data like this, however, is that its presence might be detected by examining the size of the used space in the service area. If there should be 129 MB of unused space in this sector but there’s only 80 MB, it’s a dead giveaway that something is there that shouldn’t be. But a leaked NSA document that was written in 2006 but was published by Der Spiegel last month suggests the spy agency might have resolved this particular problem. NSA Interns to the Rescue The document (.pdf) is essentially a wish list of future spy capabilities the NSA hoped to develop for its so-called Persistence Division, a division that has an attack team within it that focuses on establishing and maintaining persistence on compromised machines by subverting their firmware, BIOS, BUS or drivers. The document lists a number of projects the NSA put together for interns to tackle on behalf of this attack team. Among them is the “Covert Storage” project for developing a hard drive firmware implant that can prevent covert storage on disks from being detected. To do this, the implant prevents the system from disclosing the true amount of free space available on the disk. http://www.spiegel.de/media/media-35661.pdf “The idea would be to modify the firmware of a particular hard drive so that it normally only recognizes, say, half of its available space,” the document reads. “It would report this size back to the operating system and not provide any way to access the additional space.” Only one partition of the drive would be visible on the partition table, leaving the other partitions—-where the hidden data was stored—-invisible and inaccessible. The modified firmware would have a special hook embedded in it that would unlock this hidden storage space only after a custom command was sent to the drive and the computer was rebooted. The hidden partition would then be available on the partition table and accessible until the secret storage was locked again with another custom command. How exactly the spy agency planned to retrieve the hidden data was unclear from the eight-year-old document. Also unclear is whether the interns ever produced a firmware implant that accomplished what the NSA sought. But given that the document includes a note that interns would be expected to produce a solution for their project within six months after assignment, and considering the proven ingenuity of the NSA in other matters, they no doubt figured it out. _______________________________________________

1 0

Re: [Cryptography] trojans in the firmware
by Peter Gutmann 22 Feb '15

22 Feb '15

Henry Baker <hbaker1(a)pipeline.com> writes: >BTW, what's the point of AES encryption on this pre-p0wned device? More >security theatre? Almost. Its sole use is for very fast "drive erasure", i.e. you change the key and the data on it becomes inaccessible. Have a look at this presentation: http://www.snia.org/sites/default/education/tutorials/2012/spring/security/… which describes what Samsung (and others) are doing, in particular slide 18. The decryption key (DEK) is stored in the drive, and is unlocked using a password (and "authentication key", AK). So to decrypt the drive you extract the encrypted DEK, brute-force the password (AK), and you're in. In any case though it doesn't protect against an attack that occurs when the drive is mounted since it looks like an unencrypted drive at that point (and presumably the AK is hardcoded into a startup script or something similar in order to survive power outages, so you can grab that if you really need it). It's actually hard to see what purpose this "encryption" is serving (the vendors studiously avoid providing a threat model), it doesn't protect live data, it barely protects data at rest (say if you decide to Fedex the contents of your data centre across town), the only thing it really does is allow for fast erasure of contents, and protect against casual snooping of the "buy a batch of drives on ebay and see what's on them" kind. So I guess if ebay is your threat, it's good enough. OTOH a BIOS password set for the drive will do the same thing. As a more general response to "what's the point", regulatory compliance ("our drives were encrypted so we don't have to disclose the 40M credit card breach from last week"), buzzword-compliance, CYA, it's not a bad idea from a marketing point of view. Peter.

1 0

Re: [cryptography] OT: THE GREAT SIM HEIST
by grarpamp 22 Feb '15

22 Feb '15

On Thu, Feb 19, 2015 at 3:50 PM, Jeffrey Walton <noloader(a)gmail.com> wrote: > https://firstlook.org/theintercept/2015/02/19/great-sim-heist/ > > AMERICAN AND BRITISH spies hacked into the internal computer network > of the largest manufacturer of SIM cards in the world, stealing > encryption keys used to protect the privacy of cellphone > communications across the globe > On January 17, 2014, President Barack Obama gave a major address on the NSA spying scandal. “The bottom line is that people around the world, regardless of their nationality, should know that the United States is not spying on ordinary people who don’t threaten our national security and that we take their privacy concerns into account in our policies and procedures,” he said. > adding that the agency’s work is conducted within a “strict legal and policy framework” ... The agency also said, “[T]he UK’s interception regime is entirely compatible with the European Convention on Human Rights.” The NSA declined to offer any comment. > The monitoring of the lawful communications of employees of major international corporations shows that such statements by Obama, other U.S. officials and British leaders — that they only intercept and monitor the communications of known or suspected criminals or terrorists — were untrue. “The NSA and GCHQ view the private communications of people who work for these companies as fair game,” says the ACLU’s Soghoian. “These people were specifically hunted and targeted by intelligence agencies, not because they did anything wrong, but because they could be used as a means to an end.” > “It is governments massively engaging in illegal activities,” says Sophie in’t Veld, a Dutch member of the European Parliament. “If you are not a government and you are a student doing this, you will end up in jail for 30 years.” Veld, who chaired the European Parliament’s recent inquiry into mass surveillance exposed by Snowden, told The Intercept: “The secret services are just behaving like cowboys. Governments are behaving like cowboys and nobody is holding them to account.” > The U.S. represents Gemalto’s single largest market, accounting for some 15 percent of its total business. This raises the question of whether GCHQ, which was able to bypass encryption on mobile networks, has the ability to access private data protected by other Gemalto products created for banks and governments. > “It would mean that with a few antennas placed around Washington DC, the Chinese or Russian governments could sweep up and decrypt the communications of members of Congress, U.S. agency heads, reporters, lobbyists and everyone else involved in the policymaking process and decrypt their telephone conversations,” says Soghoian. > “I can only imagine how much money you could make if you had access to the calls made around Wall Street,” You're all being raped and used... how does it feel?

2 1

Crypto Museum
by grarpamp 21 Feb '15

21 Feb '15

http://cryptomuseum.com/

1 0

[Comp-neuro] RA position – Computer vision and automated behavioral analysis – Brown University (Providence, RI)
by Eugen Leitl 21 Feb '15

21 Feb '15

----- Forwarded message from Thomas Serre <Thomas_Serre(a)brown.edu> ----- Date: Sat, 21 Feb 2015 04:21:00 -0500 From: Thomas Serre <Thomas_Serre(a)brown.edu> To: connectionists(a)cs.cmu.edu, imageworld(a)diku.dk, visionlist <visionlist(a)visionscience.com>, comp-neuro(a)neuroinf.org Subject: [Comp-neuro] RA position – Computer vision and automated behavioral analysis – Brown University (Providence, RI) Message-ID: <CAHzuFjWxb+cBMA_cCehR7Ka3=yvDGCQuygnZvn9ZwSbt2aVMcg(a)mail.gmail.com> RA position – Computer vision and automated behavioral analysis – Brown University (Providence, RI) Computational (Thomas Serre) and developmental (Dima Amso) labs in the Department of Cognitive, Linguistic, & Psychological Sciences at Brown university are seeking an NIH-funded research assistant to work on the development of machine learning and computer vision tools, appropriate to examining naturalistic interactions in typical and atypical development. Candidates are expected to have some knowledge of computer vision and/or machine learning methods. The initial appointment is for 12 months, renewable for another year, and potentially longer depending on funding. The start date is negotiable though an early start is strongly preferred. Salary is commensurate with experience and is competitive. Research groups: Our research groups are located within the Department of Cognitive Linguistic & Psychological sciences at Brown University. We maintain strong ties with the computer science, engineering and applied math departments as part of the Brain Institute. Through Brown’s Center for Computation and Visualization (https://www.ccv.brown.edu) our groups have access to a state-of-the-art computing facility with includes over 300K GPU cores and over 500 Teraflops of GPU computing power. Information about Dr. Serre and his research group can be found at http://serre-lab.clps.brown.edu. Information about Dr. Amso and her research group can be found at http://research.clps.brown.edu/dcnl. Requirements: Applicants are expected to have finished, or be about to finish a BS or MSc in computer science or related discipline. They must have some background in computer vision and/or machine learning. Excellent programming skills are required (C/C++/Matlab/Python). Application: Please send your applications by email to dima_amso(a)correct_university_name.edu where correct_university_name should be replaced by ‘brown'. Please include a brief statement of interests, a curriculum vita and contact details for 2-3 letters of reference (no letters required at this stage). There is no deadline for the application but applicants are encouraged to apply as soon as possible as the position will be filled as soon as a suitable applicant is found. _______________________________________________ Comp-neuro mailing list Comp-neuro(a)neuroinf.org http://www.neuroinf.org/mailman/listinfo/comp-neuro ----- End forwarded message -----

1 0

Re: [Cryptography] trojans in the firmware
by Jon Callas 20 Feb '15

20 Feb '15

On Feb 19, 2015, at 8:12 AM, Henry Baker <hbaker1(a)pipeline.com> wrote: > I would love to be able to program this device myself, instead of relying on Samsung's firmware. > > BTW, what's the point of AES encryption on this pre-p0wned device? More security theatre? NAND memory runs faster when the hamming weight of the data is approximately even between zeroes and ones. You can speed up NAND flash by running the data through a suitable whitening function. AES is a great whitening function. If you then go to the extra effort to do key management, you have security. It's a simple matter of architecture and programming. :) Jon

1 0

Re: [Cryptography] trojans in the firmware
by grarpamp 20 Feb '15

20 Feb '15

On Wed, Feb 18, 2015 at 8:57 PM, Henry Baker <hbaker1(a)pipeline.com> wrote: > At 03:12 PM 2/18/2015, grarpamp wrote: >>Afaik, all vm's today simply pass through all drive commands. >> >>It seems a move all the BSD's and Linux could make today, >>without waiting on untrustable hardware vendors to roll out signature >>verification in hardware, is to simply kernel block all commands >>unnecessary to actual production use of the disk. Permit only >>from a list of READ, WRITE, ERASE, INQ, TUR, RST, and so on. >>Thus every other command component, including firmware update, >>vendor specific, and binary fuzzing, gets dropped and logged. > > ???? If the disk drive or flash drive firmware has already > been compromised, none of this will work, because the firmware > simply waits for the appropriate "legitimate" read & write > commands, and does its thing. Obviously. This is only meant to help protect clean systems, or prevent subsequent malicious commands if they happen to go through a user to kernel path that has for some reason not yet been compromised (say through the usual /dev to driver to hardware path). > BTW, what happens with "emulated" disks -- e.g., .vdi files -- > in vm's ? Presumably these emulated disks have no firmware to > update, so any attempt would either be ignored or crash the > system. Depends on how the vm is coded. My guess is vm's that emulate say disk devices, munge those opcodes too. Yes, looking at how virtualbox and even lightweight instances like jails code/handle it could be useful. Try it and see :) In all cases, having the logging capability for non production opcodes without having to postfilter them out of some debugging stream would be nice. Obviously again caveat parts of the system that have not been compromised, and defense in depth.

3 8

writing code and mails at the same time! woohooo - one-way encryption
by stef 20 Feb '15

20 Feb '15

apparently on mailing lists it's common to write mails, even cypherpunks do that instead of code. allow me to combine the two things. i thought it trough, and figured, that with openssl i have no AD crypto, with gpg i have this MDC thingy and the rfc4880 strongselector beacon strongselector, and with nacl and it's key derivation using ecdh make them all unsuitable on first sight for the use-case. re my 7 rules, i think i need to work on the threat model to have 100% score pls enjoy (also as contributions to the copyleft/permissive licensing thread) and comment: #!/usr/bin/env python # # implements simple one-way encryption pipe using rsa and keccak-based # spongewrap # # useful at least in the following use-case: you have an untrusted # host on which plaintext data arrives, which you want to encrypt # before it is forwarded in a hostile environment to the final # recipient holding a private key in a safe location. In this one-way # setting the recipient is never talking to the host doing the # encryption. # # Example: take photos in a hostile situation, encrypt the the photos # and being unable to recover them until arrival in the save location # with the the private key. (note, this does not protect against # forensics!) # # crypto: a random 32 byte message key is encrypted with the public # key of the recipient in oaep padded RSA, then this message key is # fed into SpongeWrap, which is then used to authenticated encrypt the # message. # # output format: # 2 bytes - the length of the RSA encrypted message key # n bytes - the RSA encrypted message key # m bytes - the encrypted message # 16 bytes - the "MAC" # # depends: `pip install m2crypto spongeshaker SecureString` # # create keys using openssl: # `openssl genrsa -out my.key 4096` # `openssl rsa -in my.key -pubout >> my.pub` # `cat my.key my.pub >>my.pem` # `srm -fll my.key` # # deploy my.pub on the encrypting host, secure my.pem in a safe # location for decryption. # # test with: # # for i in {0..42} {8170..8210} 1000000; do # echo -ne "\r$i " # dd if=/dev/zero bs=$i count=1 2>/dev/null | # ./ondir.py e my.pub | # ./ondir.py d my.pem >/dev/null || # break # done # # (C) 2015 by Stefan Marsiske, <s(a)ctrlc.hu>, GPLv3 import M2Crypto as m2c from spongeshaker.spongewrap import SpongeWrap from SecureString import clearmem import sys, struct TAGLEN = 16 BUFLEN = 8192 def encrypt(to): # load recipient pk key = m2c.RSA.load_pub_key(to) # gen message key mkey = m2c.Rand.rand_bytes(32) # encrypt message key cmkey = key.public_encrypt(mkey, m2c.RSA.pkcs1_oaep_padding) # output message key sys.stdout.write(struct.pack("H", len(cmkey))) sys.stdout.write(cmkey) # encrypt message ctx = SpongeWrap(1536) # with mkey ctx.add_header(mkey) # mkey not needed anymore clearmem(mkey) # buffered encrypt of stdin to stdout while 1: buf = sys.stdin.read(BUFLEN) if not buf: break sys.stdout.write(ctx.encrypt_body(buf)) # calculate tag tag=ctx.digest(TAGLEN) # output tag sys.stdout.write(tag) def decrypt(to): # load recipient pk key = m2c.RSA.load_key(to) # read msg key klen = struct.unpack('H', sys.stdin.read(2))[0] if klen>1024: print >>sys.stderr, "probably corrupt file" sys.exit(1) cmkey = sys.stdin.read(klen) # decrypt message key try: mkey = key.private_decrypt(cmkey, m2c.RSA.pkcs1_oaep_padding) except: # twarth timing attacks mkey = 'couldntdecryptkey' # todo clear private RSA key from memory # decrypt with mkey ctx = SpongeWrap(1536) ctx.add_header(mkey) # mkey not needed anymore clearmem(mkey) zero = True # to detect empty files rest = '' # buffered reading of stdin, since we need to catch the last # bytes for the tag, we always retain the last n bytes for # this purpose in rest while 1: buf = sys.stdin.read(BUFLEN) if zero and len(buf)>TAGLEN: zero=False tag=buf[-TAGLEN:] if len(buf)>TAGLEN: # prepend the retained last bytes to the next decrypt, if # there's enough more bytes read sys.stdout.write(ctx.decrypt_body(rest+buf[:-TAGLEN])) elif len(buf)>0: if len(tag)==TAGLEN: # we have exactly the tag read in buf, decrypt the # rest sys.stdout.write(ctx.decrypt_body(rest)) else: # truncate the last bytes, as we have a boundary # spanning tag sys.stdout.write(ctx.decrypt_body(rest[:-TAGLEN+len(tag)])) if len(buf)<BUFLEN: # this is the last buffer if len(tag)<TAGLEN: # we have a tag spanning a buffer boundary, we must # patch it up tag = ''.join((rest, buf[:-TAGLEN], tag))[-TAGLEN:] # verify if tag is valid if not zero and tag!=ctx.digest(TAGLEN): print >>sys.stderr, "couldn't decrypt message" sys.exit(1) break rest=tag if __name__ == '__main__': if sys.argv[1]=='e': encrypt(sys.argv[2]) elif sys.argv[1]=='d': decrypt(sys.argv[2]) else: print "usage: %s <e|d> <pub|key>" -- otr fp: https://www.ctrlc.hu/~stef/otr.txt

1 0

List Administrivia
by grarpamp 19 Feb '15

19 Feb '15

Can you add the To: and Cc: headers to the list of headers that eventually end up in the 'Downloadable version' of the archives linked below. Along with the already included Messsage-ID, In-Reply-To, and References... that should make those versions more fully threadable, sortable and searchable by MUA's and provide more understandable participant context. Thanks. https://cpunks.org/pipermail/cypherpunks/

2 5

LEA should not amass giant databases of genetic material they find lying around
by grarpamp 19 Feb '15

19 Feb '15

https://www.eff.org/press/releases/eff-supreme-court-fourth-amendment-cover… https://www.youtube.com/results?search_query=gattaca

1 0