[cryptography] NSA Molecular Nanotechnology hardware trojan

I know that this is going to sound nearly impossible and I cannot fully explain how it works but after witnessing the evidence left behind by this technology I feel that it is necessary to inform the more intelligent out there of the reality of how the NSA is bridging the air gap on secure syste

Re: [cryptography] To Protect and Infect Slides

On Tue, Dec 31, 2013 at 3:13 PM, Jacob Appelbaum wrote: > Kevin W. Wall: > > On Tue, Dec 31, 2013 at 3:10 PM, John Young wrote: > > > >> 30c3 slides from Jacob Appelbaum: > >> > >> http://cryptome.org/2013/12/appelbaum-30c3.pdf (3.8MB) > >> > > > > And you can find his actual prez here: > >

Re: [cryptography] To Protect and Infect Slides

Hi Jacob, I just watched your 30c3 presentation on Youtube. About halfway through you described an exploit on Dell servers that uses the JTAG, and then asked; "Why did Dell leave a JTAG debugging interface on these servers?” There is nothing nefarious or uncommon about an active JTAG interface

Re: [cryptography] [Ach] Better Crypto

On Sun, Jan 5, 2014 at 8:10 PM, L. Aaron Kaplan wrote: > Hi coderman, hi Peter, hello cryptography list and ACH list, > >> > (...) > > I have followed your comments on our small project bettercrypto.org (which we > started only in Sept/Okt 2013) with great interest. In fact, comments like > thes

Re: [cryptography] ECC patent FUD revisited

On Jan 5, 2014, at 1:36 AM, D. J. Bernstein wrote: > NSA's Kevin Igoe writes, on the semi-moderated c...@irtf.org list: >> Certicom has granted permission to the IETF to use the NIST curves, >> and at least two of these, P256 and P384, have p = 3 mod 4. Not >> being a patent lawyer, I have no i

Re: [cryptography] Better Crypto

On Sun, Jan 5, 2014 at 7:28 AM, Peter Gutmann wrote: > > There are some pretty weird choices in there though, a number of which seem to > have been dictated mostly by fashion-statement requirements rather than any > security need. For example they recommend disabling (if I'm reading the > OpenSSL

Re: [cryptography] [Ach] Better Crypto

Hi coderman, hi Peter, hello cryptography list and ACH list, > (...) I have followed your comments on our small project bettercrypto.org (which we started only in Sept/Okt 2013) with great interest. In fact, comments like these are very valuable to our project and help us to write a better ver

Re: [cryptography] To Protect and Infect Slides

On 31/12/13 23:13 PM, Jacob Appelbaum wrote: I'm also happy to answer questions in discussion form about the content of the talk and so on. I believe we've now released quite a lot of useful information that is deeply in the public interest. Hi Jacob, thanks for the good work, I wish I could

Re: [cryptography] Better Crypto

On Sun, Jan 5, 2014 at 4:28 AM, Peter Gutmann wrote: > ... > There are some pretty weird choices in there though, a number of which seem to > have been dictated mostly by fashion-statement requirements rather than any > security need they enable Camellia but disable 3DES (why?), > they optiona

Re: [cryptography] Preventing Timing Correlation Attacks on XMPP chats?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/05/2014 04:28 AM, Fabio Pietrosanti (naif) wrote: > Hi, > > XMPP networks are now going to be default secured with TLS in > their client-to-server and server-to-server communications by 22th > Feb. Actually May 19th: https://github.com/stpeter

Re: [cryptography] Better Crypto

ianG writes: >Not sure if it has been mentioned here. The Better Crypto group at >bettercrypto.org have written a (draft) paper for many of those likely >configurations for net tools. The PDF is here: > >https://bettercrypto.org/static/applied-crypto-hardening.pdf > >If you're a busy sysadm with

Re: [cryptography] Preventing Timing Correlation Attacks on XMPP chats?

Den 5 jan 2014 13:23 skrev "Randolph" : > > Hi > > - a "scrambler" could send out from time to time fake messages. > - an "impersonator" could record your own chat behaviour and generate random time and lenght and content data, so it looks like your own chat > - the main problem remains that from a

Re: [cryptography] Preventing Timing Correlation Attacks on XMPP chats?

Hi - a "scrambler" could send out from time to time fake messages. - an "impersonator" could record your own chat behaviour and generate random time and lenght and content data, so it looks like your own chat - the main problem remains that from an external analysis you can always see, that User A

[cryptography] Preventing Timing Correlation Attacks on XMPP chats?

Hi, XMPP networks are now going to be default secured with TLS in their client-to-server and server-to-server communications by 22th Feb. Most IM client support end-to-end encryption with OTR by default. The "Federated Architecture" make it very scalable and distributed. With all that "goods of

[cryptography] ECC patent FUD revisited

NSA's Kevin Igoe writes, on the semi-moderated c...@irtf.org list: > Certicom has granted permission to the IETF to use the NIST curves, > and at least two of these, P256 and P384, have p = 3 mod 4. Not > being a patent lawyer, I have no idea what impact the Certicom patents > have on the use of n

Re: [cryptography] Better Crypto

On Sat, Jan 4, 2014 at 11:59 PM, ianG wrote: > Not sure if it has been mentioned here. The Better Crypto group at > bettercrypto.org have written a (draft) paper for many of those likely > configurations for net tools. The PDF is here: > > https://bettercrypto.org/static/applied-crypto-hardening.

[cryptography] Better Crypto

Not sure if it has been mentioned here. The Better Crypto group at bettercrypto.org have written a (draft) paper for many of those likely configurations for net tools. The PDF is here: https://bettercrypto.org/static/applied-crypto-hardening.pdf If you're a busy sysadm with dozens of tools to