Re: [cryptography] [cryptome] Re: snowman news
The Polk Award plaques have concealed cavity transmitters, so our Google glasses indicate. Back-up. we palmed a sliver RFID in GG's wide mouthed molar, another in Miranda's steely butt, Poitras's panoptic camera, Gellman's top-sekret OTR widget, MacAskill's brogue-decrytor (we saw him plant a 0-day craw deep inside James Ball's kisser). Our totally undoctored vids and transcripts are at Amazon, Utah, Four Eyes, RU, CN, BR, all of them on the same transceiving thieving pipe, each with a twinned JPmorgan, Goldman Sachs fiber, so reports ourr splitter at Ross Anderson's lab in Oxbridge-Cheltenham, centroid of the universe's gobbling inadvertencies. The fake one underskinned in Markus Kuhn's vestigal tail. Real one infected at Vatican, eternal cloud of the pipe of pipes. - On Mon, Apr 7, 2014 at 4:48 PM, John Young j...@pipeline.com wrote: Great that Snowden is getting another chance to speak for himself, speaking of speaking directly, i hear one fine JYA got to mingle with the leakers? how hard did you press for a mass doc drop, John? i would have donated toward such a bribe... looks like an interesting crowd! (who has .vid transcripts?) best regards, #JustALittleJealous c.f.: http://cryptome.org/greenwald-miranda-young.jpg ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] If not StartSSL, the next best CA for individuals?
On 12 April 2014 19:57, Jeffrey Goldberg jeff...@goldmark.org wrote: They also had a really nice statement about transparency back in September, but I can't find it now. https://www.globalsign.com/blog/trust-the-math-choose-your-friends-wisely.html ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] xkcd on Heartbleed
XKCD strikes again: https://xkcd.com/1354 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Is it time for a revolution to replace TLS?
http://clearcryptocode.org/tls/ Probably not going to happen, but it's nice to dream... -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Request - PKI/CA History Lesson
The more I read, the more bewildered I am by the state of the PKI. The trust model's unwieldy system[1] of protocols, dependencies, and outright assumptions begs to be exploited. Add to that the browser behavior for a self-signed certificate (RED ALERT! THE SKY IS FALLING!) compared to a trusted site and we're in bizarro world. I'd rather we close the gap and appreciate a secure transaction with an unauthenticated party than proclaim all is lost when a self-signed key is presented. I see no reason to trust VeriSign or Comodo any more than Reddit. Assuming trust in a top heavy system of Certificate Authorities, Subordinate Certificate Authorities[2], Registration Authorities, and Validation Authorities[3] in a post bulk data collection partnership world is a non-starter. The keys are compromised. With that, I ask for a history lesson to more fully understand the PKI's genesis and how we got here. Maybe a tottering complex recursive heirarchical system of trust is a really great idea and I just need to be led to the light. [1]http://csrc.nist.gov/publications/nistpubs/800-15/SP800-15.PDF, http://csrc.nist.gov/publications/nistpubs/800-32/sp800-32.pdf [2]https://www.eff.org/files/DefconSSLiverse.pdf, https://www.eff.org/files/ccc2010.pdf [3]http://en.wikipedia.org/wiki/Public-key_infrastructure ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Inevitable Security Critiques, Promises and Lemons
Gratifying to see a few of those here featured in NY Times today discussing inevitable failures and contradictions in security: http://www.nytimes.com/2014/04/19/technology/heartbleed-highlights-a-contradiction-in-the-web.html To be read with Schneier's 2007 account of inevitable security lemons (resurrected by Coderman): https://www.schneier.com/blog/archives/2007/04/a_security_mark.html Our security consumer advice based on frank, honest and distrustful discussions here for nearly 18 years: Unreliable SSL has been uninstalled. All security and privacy policies are unreliable. Protect yourself against security and privacy promise. Still hopeful Hettinga will plug these insider breaches of why marketing lemonade is so lucratively persuasive to those who know better. And who do not disclose here. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] NSA Said to Exploit Heartbleed Bug for Intelligence for Years
2. Score another 1 up for interpreted languages that handle array
allocation cleanly. This is more or less a buffer overflow, in a wider
sense.
Virtually the same bug can occur (and has occurred) in memory-safe
languages due to buffer reuse.
Go was mentioned elsewhere in this thread, so let's look at how it
handles I/O:
type Reader interface {
Read(p []byte) (n int, err error)
}
http://golang.org/pkg/io/#Reader
The return value n tells the caller that the indices p[0], p[1], …,
p[n-1] contain valid data, and n can be less than the length of p. So
if the caller, during parsing, reads beyond p[n-1], but not beyond
p[len(p)-1], the language runtime will not detect this and data which
depends on where and how the buffer has been used before will be
returned.
There is still a difference: Only data that was in the buffer before
can be returned. But depending on the buffer reuse mechanism, such
data may still include bits of cleartext from unrelated connections.
Buffer reuse is a commonly employed performance optimization in
garbage-collected languages because without it, the I/O speed is
constrained by the speed at which the garbage collector can collect
buffers used only once.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] OTR and XMPP
On 04/07/2014 11:29 PM, ianG wrote: On 8/04/2014 03:13 am, Pranesh Prakash wrote: Dear all, In the March IETF 89 meeting in London, there were renewed discussions around end-to-end encryption in XMPP. Here is the recording of the session: http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF89_XMPPchapter=part_5 There was basic agreement that OTR is a horrible fit for XMPP since it doesn't provide full stanza encryption. The very reasons for the benefits of OTR (its ability to be protocol-agnostic) are the reasons for its shortfalls too. However, there is no clear alternative. The closest is draft-miller-xmpp-e2e. The one clear verdict was that more contributors are required. Has anyone got a text-based summary of what this is about? I'm happy to read, but I find listening to recordings doesn't really work. Better late than never: From http://www.ietf.org/proceedings/89/minutes/minutes-89-saag : Matt Miller presents Securing XMPP End-to-End Matt Miller (XMPP): off the record (OTR). Problems: finding a stable reference for OTR. Only covers normal fonts, invents new crypto. Support lacking for multiple devices on-line simultaneously. Paul: document is nearly stable. XMPP end to end. Protects whole stanzas. Works with multiple devices on-line at the same time. Reuses JOSE. Issues: PFS undefined. No support for store and forward (i.e. when other party is off-line). Need security input and review. Open to ideas. Peter St Andre: XMPP designed for more than IM. So, ability to protect more than just the typed text is important. Hildebrand: non-normal fonts are not protected (e.g. Boldface). If helpers don't participate then this aspect will not be addressed. MM: there are drafts that attempt to protect everything. SF: suggest address a practical subset of all problems. DKG offers to help with protecting time and similar components. He also mentioned that the currently-defined algorithm is insufficiently secure. Paul: Don't want a complicated list of algorithms for users to choose from. RH: asking about support for agility. Paul: planning to implement new algorithms with a version change. Hannes: interesting to observe that some prefer software update mechanism for agility. Paul: algorithms are identified by number to support negotiation and agility. Peter SA: the community is quite tight, so it is practical to implement agility this way. PHB: algorithms don't break catastrophically. Steve Kent: presence procedure could announce algorithm support. Tim Polk: pull-downs are needed only when support still exists for weak algorithms. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
This thread pertains specifically to the use of P2P/DHT models to replace traditional email as we know it today. *Anonymous Email based on virtual institutions* What about this model? In a network you send your public email encryption key to an virtual institution. The institution is defined by a name (e.g. AES string) and postal address (e.g. hash key). Having this information added to your node, all your email to you or from you will be stored in the virtual email provider institution. This detaches your nodes IP and encrpytion key from the institution. That means, care-off (c/o) institutions will be able to house 3rd-party e-mail without needing to distribute their own public keys. To create a post office for your friends, two methods exist: 1) Define a common neighbor (e.g Alice and Bob connect to a common webserver as node, and all three have email encryption keys shared), then the webserver stores the emails, even if Alice or Bob are offline. 2) Or/additionally: Create an virtual institution and add the email key of a friend to your node. In case your friend adds the magnet link (which contains name and address of the virtual institution, aka AES key and Hash key) for the institution as well to his node, the institution will save all emails for him (as well from senders, which are not registered at the virtual institution). A Magnet Link allows to share the virtual institution easily. The magnet Uri would look like: *magnet:?in=Gmailct=aes256pa=dotcomht=sha512xt=urn:institution* With this method an email provider can be build without data retention and with the advantage of detached email encrpytion keys from node´s IP addresses. Next to TCP, you can use as well UDP and SCTP as protocol. Virtual Institutions (VI) have been - due to the homepage - introduced by the lib-version 0.9.04 of http://goldbug.sf.net email and chat application. If we understand this right, now everyone can create an email provider without data retention just as a service for friends. In case in a network of connected nodes everyone uses gmail as VI-name and dotcom as VI-address, everyone will host everyone for email, while all remains encrypted.. could be a nice net or p2p model in a testing. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Post-doc positions in software protection at UEL, London, UK
The Software Systems Engineering research group in the School of Architecture Computing and Engineering at the University of East London, is looking for two candidates to carry out research activities in the field of software protection. These research positions are funded by the FP7 European research project ASPIRE (Advanced Software Protection: Integration, Research and Exploitation) and are supervised by Dr Paolo Falcarin, who is ASPIRE's principal investigator in UEL. ASPIRE will establish trustworthy software execution on untrusted mobile platforms (such as tablets and smartphones) that lack custom secure hardware elements, but that have a persistent or occasional network connection to a trusted remote system. The Software Systems Engineering Research Group at UEL aims at investigating two strategic areas of software engineering and security: (1) Software protection diversity and renewability; (2) Security modelling and evaluation. In the first area, the research will explore software protection techniques such as anti-tampering, remote attestation, software diversity and renewability on mobile apps built with Android NDK. The scientific challenge is realizing dynamic renewability of a mobile application, by designing and implementing client-server support for secure code updates; such diversified run-time code updates will serve different purposes: contrasting static analysis, reducing the attacker's time-frame and implementing network-based protections (such as remote attestation). In the second area, a decision support system will be developed within the project to assist developers in adopting the configuration that best fits their specific protection requirements. The decision support system will rely on a knowledge base and attack models. The challenge is building a knowledge base of software protection related attacks and evaluating the effectiveness of protection by developing tools for attack analysis based on system modelling techniques, such as Petri nets and Bayesian networks. More information about the ASPIRE project is available at http://www.aspire-fp7.eu/ JOB DESCRIPTION: The candidates are expected to contribute original research results inside this leading edge international project. The aim of the project is to advance the state-of-the-art in software protection, by elaborating and implementing novel approaches to detect and prevent software tampering on mobile applications. Candidates must have a PhD degree (in Software Engineering, Software Security, Computer Science or related areas). The candidates are required to possess knowledge in one or more of the following essential skills: - Excellent software development skills (C/C++/Java) - Experience in Android Software Development (preferably Android NDK) - A proven track record of research and publications in Software Engineering or Software Security - Experience in knowledge modelling (OWL) and reasoning, and/or in system modelling (Petri Nets, Bayesian networks, attack graphs) Other desirable skills are in the following areas: - binary obfuscators and software protection tools - ARM assembly language - Disassembler tools (IDA Pro) and binary rewriting tools - Static and dynamic analysis of software EMPLOYMENT: Type of contract: Research Assistant FTC for 2 years (with possible extension until the end of the project) Number of positions: 2 Gross salary per year: £31,492 to £35,950 per annum inclusive of London Weighting Start date: from June to September 2014 End date: 31st October 2016 Place: London (UK) APPLICATION: To apply online, fill the application form at http://jobs.uel.ac.uk/Vacancy.aspx?ref=044R2014 and attach your detailed CV (in PDF format) including a list of publications, technical skills, statement of research interests and, possibly, up to 3 reference letters. For informal technical enquiries about the posts, feel free to contact Dr Paolo Falcarin by email at falca...@uel.ac.uk For any other enquiries contact the HR office by email: Reshma Begum at reshma.be...@uel.ac.uk Application deadline: 7th May 2014 For more information: http://www.aspire-fp7.eu/ http://jobs.uel.ac.uk/ http://www.uel.ac.uk/ace/ -- Paolo Falcarin, PhD Senior Lecturer School of Architecture, Computing and Engineering (ACE) University of East London Docklands Campus - 4/6 University Way, E16 2RD, London tel: +44 (0)20 8223 6086 http://www.uel.ac.uk/ace/staff/paolofalcarin/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
Message du 22/04/14 20:30 De : Randolph This thread pertains specifically to the use of P2P/DHT models to replace traditional email as we know it today. *Anonymous Email based on virtual institutions* What about this model? In a network you send your public email encryption key to an virtual institution. The institution is defined by a name (e.g. AES string) and postal address (e.g. hash key). Having this information added to your node, all your email to you or from you will be stored in the virtual email provider institution. This detaches your nodes IP and encrpytion key from the institution. That means, care-off (c/o) institutions will be able to house 3rd-party e-mail without needing to distribute their own public keys. To create a post office for your friends, two methods exist: 1) Define a common neighbor (e.g Alice and Bob connect to a common webserver as node, and all three have email encryption keys shared), then the webserver stores the emails, even if Alice or Bob are offline. 2) Or/additionally: Create an virtual institution and add the email key of a friend to your node. In case your friend adds the magnet link (which contains name and address of the virtual institution, aka AES key and Hash key) for the institution as well to his node, the institution will save all emails for him (as well from senders, which are not registered at the virtual institution). A Magnet Link allows to share the virtual institution easily. The magnet Uri would look like: *magnet:?in=Gmailct=aes256pa=dotcomht=sha512xt=urn:institution* With this method an email provider can be build without data retention and with the advantage of detached email encrpytion keys from node´s IP addresses. Next to TCP, you can use as well UDP and SCTP as protocol. Virtual Institutions (VI) have been - due to the homepage - introduced by the lib-version 0.9.04 of http://goldbug.sf.net email and chat application. If we understand this right, now everyone can create an email provider without data retention just as a service for friends. In case in a network of connected nodes everyone uses gmail as VI-name and dotcom as VI-address, everyone will host everyone for email, while all remains encrypted.. could be a nice net or p2p model in a testing. Although technical solutions are feasible, we ought to consider some things: - Email is older than the web itself; - Email has three times as many users as all social networks combined; - Email is entrenched in the offices, many a business is powered by it; Given the enormous energy necessary to remove such an appliance and replace it with something better. How could we make a secure solution that plays nicely with the current tools without disturbing too much what is already established? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Swap space (Re: It's all KR's fault)
In article e1wdnmx-00045q...@login01.fos.auckland.ac.nz you write: Nemo n...@self-evident.org writes: Well, Windows does not use fork()+exec(); it uses spawn() and its variants. Hence it avoids the whole vfork() / memory overcommit mess. Aren't many fork()s now pretty close to vfork(), via COW? Yes. Every modern Unix-ish system I know of does COW both for forks and for writable data segments. Also keep in mind that even if you have no swap space for writable memory, any read-only code can be discarded and then reloaded from the file it was originally loaded from, which permits RAM to be significantly overcommited and still not run out of space. For crypto, I think this means that whatever model you have for where your data are is likely wrong, so I wouldn't spend a lot of time obsessing about it. I sort of see the point of encrypted swap, although I don't really understand the threat model where the attacker can defeat file protections and look at the /dev/swap but not at /dev/mem. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Swap space (Re: It's all KR's fault)
That is, the purpose of vfork() was to let you implement spawn(). (Prior to Linux, no O/S even considered the overcommit_memory approach because, let's face it, it's idiotic.) Sort of. The vfork() call was added to 3BSD around 1980, while COW memory management was written for Mach in the late 1980s and wasn't merged into 4BSD until the mid 1990s. Like much of what Bill Joy added to Unix, vfork() was a hack. He noted that fork()/blah/exec() was a common idiom with a fairly small amount of blah, so he added vfork to handle that special case. It's still more general than spawn since the blah can be anything, not just whatever options spawn provides. Like every hack, it was quickly misused, often by the child process making changes to memory that the parent could see after the child's exec(). I wrote a history of COW a while ago: http://obvious.services.net/2011/01/history-of-copy-on-write-memory.html I would worry more about shared libraries with writable data pages that don't get copied when you fork. That's supposed to be a feature, to handle shared buffers for dbm style libraries, but wow, what a way to leak data. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
