- cypherpunks@lists.ogf.org

[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

Obama believes in strong encryption
by grarpamp 19 Feb '15

19 Feb '15

http://recode.net/2015/02/13/obama-theres-no-scenario-in-which-we-dont-want… https://www.youtube.com/watch?v=yaylQmnXztU http://it.slashdot.org/story/15/02/17/2230257/obama-says-hes-a-strong-belie… Contrast with many recent US administration and agency statements all on the record as well. Is this a mindshift, or a case of FUD then false savior?

3 2

Disastrous privacy consequences of Canada's terrorism bill
by grarpamp 19 Feb '15

19 Feb '15

http://yro.slashdot.org/story/15/02/19/1633223/the-disastrous-privacy-conse… http://www.michaelgeist.ca/2015/02/total-information-awareness-disastrous-p… http://www.parl.gc.ca/HousePublications/Publication.aspx?Language=E&Mode=1&…

2 1

[liberationtech] At Stanford on Friday, Feb. 20 -- Vitalik Buterin: Ethereum & Cryptoeconomic Mechanisms & Security
by Eugen Leitl 19 Feb '15

19 Feb '15

----- Forwarded message from Yosem Companys <companys(a)stanford.edu> ----- Date: Mon, 16 Feb 2015 12:27:19 -0800 From: Yosem Companys <companys(a)stanford.edu> To: Liberationtech Events <liberationtech-events(a)lists.stanford.edu>, Liberation Technologies <liberationtech(a)mailman.stanford.edu> Subject: [liberationtech] At Stanford on Friday, Feb. 20 -- Vitalik Buterin: Ethereum & Cryptoeconomic Mechanisms & Security Message-ID: <CANhci9E+pmyHwS_ya7giPFXuzbzYQfGWr9rcnHCWuCjsA65sBw(a)mail.gmail.com> Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> From: David Wu <dwu4(a)cs.stanford.edu> via security-seminar(a)lists.stanford.edu at https://mailman.stanford.edu/mailman/listinfo/security-seminar Introduction to Ethereum, and Cryptoeconomic Mechanisms and Security Vitalik Buterin Friday, February 20, 2015 Talk at 4:15pm Gates 463 Abstract: The presentation will provide an introduction to the Ethereum protocol from a technical perspective, including the high-level operation of the blockchain protocol, contract calling and gas mechanics, use of Patricia Merkle trees and other cryptography and light client proofs. I will then discuss some of the interplay between economics/game theory and cryptography both in consensus algorithm design (eg. proof of work, proof of stake) as well higher-level protocols like sidechains, challenge-response protocols and SchellingCoin, and will attempt to define and dissect different interpretations of the concept of "cryptoeconomic assurance". -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu. ----- End forwarded message -----

1 0

Twitter v. DOJ-FBI, Google to FBI
by grarpamp 19 Feb '15

19 Feb '15

https://freedom.press/blog/2015/02/our-brief-support-twitters-lawsuit-again… https://gigaom.com/2015/02/18/tech-and-media-firms-join-twitter-in-key-test… http://www.nationaljournal.com/tech/google-calls-fbi-s-plan-to-expand-hacki…

1 0