[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 fix, this might be the guide for you. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Better Crypto
On Sat, Jan 4, 2014 at 11:59 PM, ianG i...@iang.org 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.pdf If you're a busy sysadm with dozens of tools to fix, this might be the guide for you. this is an excellent resource! i've been impressed with the collective effort and end result in this guide. also mentioned bettercrypto in a thread about better defensive application randomness on the RNG list[0]. it would be awesome to have a similar effort focused on developers. this would detail the correct way to use various cryptography libraries and frameworks in a robust manner in the various languages and platforms in use today. there is a distinct lack of accessible resources for developers deploying crypto in their applications, even for platforms with usable crypto APIs in the standard libraries / OS frameworks! best regards, 0. http://lists.bitrot.info/pipermail/rng/2014-January/thread.html better defensive application randomness... 3) perhaps a best practice random library is needed for applications. it would keep a thread-specific-storage pool, mix multiple sources into it, combine with OS entropy where available, and then finally mix and fold before use. this way, even if the OS or framework entropy is horribly broken, you've got a source that is much more resilient in application. perhaps a bettercrypto.org like effort specifically for application developers who need to be proficient users of crypto APIs (not all devs applied cryptographers ;) ideally this would cover openssl, polartls, gnutls, crypto++, cryptlib, libnss, etc. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[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 newer families of curves, such as Edwards curves. There are several interesting aspects to this patent FUD. Notice that the FUD is being used to argue against switching to curves that improve ECC security. Notice also the complete failure to specify any patent numbers---so the FUD doesn't have any built-in expiration date, and there's no easy way for the reader to investigate further. http://www.certicom.com/index.php/licensing/certicom-ip says that Certicom discovered and patented many fundamental innovations and has more than 350 patents and patents pending worldwide. This sounds impressive until you look at what the portfolio actually contains. The reality is that Certicom has contributed essentially nothing to state-of-the-art ECC. Its patent portfolio consists of a few fringe ideas and a few obsolete ideas---nothing essential for mainstream ECC usage. Nobody needs MQV, for example: traditional DH achieves the same security goals in a much more straightforward way, and very few people notice the marginal performance benefit provided by MQV. The reason that Certicom has so many patents and patents pending worldwide, despite having contributed so few ideas, is that it keeps splitting its patent applications. For example, the original MQV patent filings in early 1995 ended up being split into an incredibly redundant collection of US patents 5761305, 5889865, 5896455, 5933504, 6122736, 6487661, 7243232, 7334127, 7779259, 8090947, and 8209533, not to mention the corresponding non-US patents CA2237688, DE69636815, EP0873617, etc. ---Dan ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[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 COMSEC in place, we are missing a timing correlation protection schema for XMPP traffic, to avoid an adversary monitoring your internet communication line to know when you have written something. POND is a super technology to prevent timing correlation attacks (https://pond.imperialviolet.org/tech.html), unfortunately it's a closed network so i don't think it would ever get diffused (it's also written in GO and my religion does not let me use anything written in GO). So i've been thinking that we need a method to achieve protection against time traffic correlation attacks on XMPP chat. It's possible that, by having a traffic-generator-robot (behaving like an XMPP buddy you connect to), and an XMPP client plug-in it would be possible to create some kind of constant traffic timing pattern to avoid an adversary being able to make timing correlation attacks. Something like that would be relatively easy to be implemented. This would bring timing correlation attack protection to the already existing security stack of XMPP: - Client TLS encrypted login - Server-to-Server TLS encrypted communication - end-to-end encrypted communication with OTR - Federated architecture -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
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 is sending (a messge) to User B. This can only be solved with sending the Message (originally addressed to A) to all connected people, so as well to B, C, D, E and F. A kind of echo would solve this. EMPP (library: http://spot-on.sf.net, echoed message and presence protocol) has this all and XMPP could benefit from it or - as some discuss - why not merge EMPP and XMPP or even send echo over an xmpp acccount? Would a XMPP connection allow a selfsigned SSL connection over/through it ? I still wounder, why XMPP is not adding end-to-end encryption and it must be done over a plugin (OTR). D/H key exchange / TLS can be attacked by a man in the middle, especially if you use : User A - TLS - Own Webserver - MITM / - Maybe: TLS - - Own Webserver - TLS - User B User A does not know, if the cert between two Webservers is compromised. Or elsewhere in the chain. Only End to End proves, that you have full continuity in your TLS chains. And: Is a D/H key exchange for OTR secure over a broken TLS? But: The problem is not securing xmpp, the problem with XMPP is, that you easily know, who is talking with whoom. This makes no sense to think about adding a scrambler to it, especially if you are not interested in the content, but in the social network one maintains. From the kids on the block perspective, XMPP is the glorification of open source. Nothing else has to be there. But is this a differentiating view? Form the developer side there are different views: http://harmful.cat-v.org/software/xml/xmpp/ If adding fancy helper tools like encryption or scramblers makes this more easy, dunno. Some Dinos have still homework to do and must be regarded outdated until not a native (and not only plugged) end to end encryption is in. This is not liked, we know, but us as XMPP server admins need to be taken away the possibility to read plaintext. And this is a transformation we after occurances of the last year have to bear. Jabber Servers without Plaintext is the Vision of 2014. And this becomes real Feb. 22 ? 2014/1/5 Fabio Pietrosanti (naif) li...@infosecurity.ch 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 COMSEC in place, we are missing a timing correlation protection schema for XMPP traffic, to avoid an adversary monitoring your internet communication line to know when you have written something. POND is a super technology to prevent timing correlation attacks (https://pond.imperialviolet.org/tech.html), unfortunately it's a closed network so i don't think it would ever get diffused (it's also written in GO and my religion does not let me use anything written in GO). So i've been thinking that we need a method to achieve protection against time traffic correlation attacks on XMPP chat. It's possible that, by having a traffic-generator-robot (behaving like an XMPP buddy you connect to), and an XMPP client plug-in it would be possible to create some kind of constant traffic timing pattern to avoid an adversary being able to make timing correlation attacks. Something like that would be relatively easy to be implemented. This would bring timing correlation attack protection to the already existing security stack of XMPP: - Client TLS encrypted login - Server-to-Server TLS encrypted communication - end-to-end encrypted communication with OTR - Federated architecture -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Preventing Timing Correlation Attacks on XMPP chats?
Den 5 jan 2014 13:23 skrev Randolph rdohm...@gmail.com: 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 is sending (a messge) to User B. This can only be solved with sending the Message (originally addressed to A) to all connected people, so as well to B, C, D, E and F. A kind of echo would solve this. EMPP (library: http://spot-on.sf.net, echoed message and presence protocol) has this all and XMPP could benefit from it or - as some discuss - why not merge EMPP and XMPP or even send echo over an xmpp acccount? Would a XMPP connection allow a selfsigned SSL connection over/through it ? I still wounder, why XMPP is not adding end-to-end encryption and it must be done over a plugin (OTR). D/H key exchange / TLS can be attacked by a man in the middle, especially if you use : User A - TLS - Own Webserver - MITM / - Maybe: TLS - - Own Webserver - TLS - User B User A does not know, if the cert between two Webservers is compromised. Or elsewhere in the chain. Only End to End proves, that you have full continuity in your TLS chains. And: Is a D/H key exchange for OTR secure over a broken TLS? But: The problem is not securing xmpp, the problem with XMPP is, that you easily know, who is talking with whoom. This makes no sense to think about adding a scrambler to it, especially if you are not interested in the content, but in the social network one maintains. From the kids on the block perspective, XMPP is the glorification of open source. Nothing else has to be there. But is this a differentiating view? Form the developer side there are different views: http://harmful.cat-v.org/software/xml/xmpp/ If adding fancy helper tools like encryption or scramblers makes this more easy, dunno. Some Dinos have still homework to do and must be regarded outdated until not a native (and not only plugged) end to end encryption is in. This is not liked, we know, but us as XMPP server admins need to be taken away the possibility to read plaintext. And this is a transformation we after occurances of the last year have to bear. Jabber Servers without Plaintext is the Vision of 2014. And this becomes real Feb. 22 ? 2014/1/5 Fabio Pietrosanti (naif) li...@infosecurity.ch 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 COMSEC in place, we are missing a timing correlation protection schema for XMPP traffic, to avoid an adversary monitoring your internet communication line to know when you have written something. POND is a super technology to prevent timing correlation attacks (https://pond.imperialviolet.org/tech.html), unfortunately it's a closed network so i don't think it would ever get diffused (it's also written in GO and my religion does not let me use anything written in GO). So i've been thinking that we need a method to achieve protection against time traffic correlation attacks on XMPP chat. It's possible that, by having a traffic-generator-robot (behaving like an XMPP buddy you connect to), and an XMPP client plug-in it would be possible to create some kind of constant traffic timing pattern to avoid an adversary being able to make timing correlation attacks. Something like that would be relatively easy to be implemented. This would bring timing correlation attack protection to the already existing security stack of XMPP: - Client TLS encrypted login - Server-to-Server TLS encrypted communication - end-to-end encrypted communication with OTR - Federated architecture There are the I2P method of everybody acting as anonymizing relays + layered end-to-end encryption make traffic analysis nearly impossible (you don't know where any packet originated from). There's already a chat program using it called I2P Messenger, and it's serverless. XMPP has also already been made to work over I2P. And there's the batching method (send everything at once in a fixed size message). Could work well with Moxie's axolotl ratcheting key exchange to establish PFS encrypted chats. Both of those can be strengthened by throwing in fake traffic. I don't like the option of *only* hiding your activity among fake activity generated only by your own node, it's too easy to attack with things like statistical means and watching what the node does if you disrupt it's Internet connection (such as making it somewhat unreliable through DDoS:ing it's router or whatever). (And FYI, OTR is secure independently of the channel it's used over if the keys are verified. But it ONLY protects the contents of the
Re: [cryptography] Better Crypto
ianG i...@iang.org 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 dozens of tools to fix, this might be the guide for you. 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 config line-noise correctly) PSK and SRP, which are the only mutual- auth mechanisms provided in TLS, they enable Camellia but disable 3DES (why?), they optionally allow ECC but only with P384 (which requires the oddball SHA-384, why not the universal P256 with SHA-256?), for OpenSSH they only allow a bunch of fashion-statement ciphers (aes256-...@openssh.com and some others) which is pretty much guaranteed to lock out the zillion third-party SSH implementations that do 3DES-CBC and AES-CBC (the same can apply for SSL in older systems that don't support the newer fashion-statement ciphers while still supporting the perfectly secure 3DES), I'm not seeing much (if anything) about actually verifying the certs and/or checking that the information in them matches what you think you're connecting to, the IPsec predefined suites seem to be restricted only to Suite B (that's the crypto designed and promoted by the nation-state adversary that we're supposed to be defending against), and so on. As a general observation, it also promotes the thinking that all we need to do is choose magic algorithm A instead of magic algorithm B and everything is fixed. The crypto is pretty much the last thing you need to worry about, since the attackers will ignore it and go for all the other weak points instead. So while disabling obviously dangerous settings (many of which are disabled by default anyway) is a good thing, obsessing over which colour of algorithm you're using is at best a distraction from securing other aspects of a system, and at worst a problem when restricting yourself to oddball algorithms breaks the ability of clients to connect. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
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/manifesto/blob/master/manifesto.txt Most IM client support end-to-end encryption with OTR by default. I would say that many (not most) IM clients support OTR, but that they do not enable it by default. The Federated Architecture make it very scalable and distributed. That was the idea, yes. :-) With all that goods of COMSEC in place, we are missing a timing correlation protection schema for XMPP traffic, to avoid an adversary monitoring your internet communication line to know when you have written something. POND is a super technology to prevent timing correlation attacks (https://pond.imperialviolet.org/tech.html), unfortunately it's a closed network so i don't think it would ever get diffused (it's also written in GO and my religion does not let me use anything written in GO). So i've been thinking that we need a method to achieve protection against time traffic correlation attacks on XMPP chat. It's possible that, by having a traffic-generator-robot (behaving like an XMPP buddy you connect to), and an XMPP client plug-in it would be possible to create some kind of constant traffic timing pattern to avoid an adversary being able to make timing correlation attacks. Something like that would be relatively easy to be implemented. This would bring timing correlation attack protection to the already existing security stack of XMPP: - Client TLS encrypted login - Server-to-Server TLS encrypted communication - end-to-end encrypted communication with OTR - Federated architecture Thanks for the pointer, I'll check it out. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSyYbBAAoJEOoGpJErxa2pysYP/2b53vGfdmyHBHVNgW32dAWg 4u0owXP0PHZnn/LVeDFsEFFHkSTky9DM8UGDHuc1BUQmKzkn8x8VngfrkzuuXZQ/ ctsJsd8RKYqC+QDgGBSCLePXXkqVN5wjOABOmA2rtKdvULrpAqo7vxP3CI8CpjPR RP4WLuJ+ggadIu7UuhYrXfpxfEGz8HC57HLfA+E+TRaevzuYXtjLFufhXRBEJqn2 vKFg8MTPUuOIEslwaSsqxaS5sxiru3fB69umeG8NNHJGXz8hPxbeXE43H84b6QCU BLIvxlncja9egdvJwRlD5BBrAZvFlu2EW9IZHb0CNdlCXnz8gbGlbrMEN6r5AoeG hdoQFM/2/3ckHHFe5EOBP+++QWKrSZX3TaRYykozFJotdGZFa64E0alwAtwOcZ9C ps1jod9zRdz+6y0a6Ng1lVretSS/eftKc1ZBidwtZsak2+XyjVeGbiLQ0+AxK40z zIbOvhexwfU1aMzAzehKp/QpZpmm9RKsn2XHOwJGohaNarcJLHm6yGyDVGkZNI3b byNHj1SEup1ajlj+TmRYZzoqKZc5nr0CwGwn87sEb/29JBpdsXbAScjlG8hRKtua Wqcvohy7IhhkcmhvkSrCnI+eHtbNHkZSMWiA9yQiAulWrOgB3Iw7PWRqMTAIdk0y nsqyf+5HXG7uIKNdwF7b =MM17 -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ECC patent FUD revisited
On Jan 5, 2014, at 1:36 AM, D. J. Bernstein d...@cr.yp.to 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 idea what impact the Certicom patents have on the use of newer families of curves, such as Edwards curves. There are several interesting aspects to this patent FUD. Notice that the FUD is being used to argue against switching to curves that improve ECC security. Notice also the complete failure to specify any patent numbers---so the FUD doesn't have any built-in expiration date, and there's no easy way for the reader to investigate further. The FUD provides good reasons to move to new curves. For example - curves that do not need to check if a provided public key is on the curve … Paul http://www.certicom.com/index.php/licensing/certicom-ip says that Certicom discovered and patented many fundamental innovations and has more than 350 patents and patents pending worldwide. This sounds impressive until you look at what the portfolio actually contains. The reality is that Certicom has contributed essentially nothing to state-of-the-art ECC. Its patent portfolio consists of a few fringe ideas and a few obsolete ideas---nothing essential for mainstream ECC usage. Nobody needs MQV, for example: traditional DH achieves the same security goals in a much more straightforward way, and very few people notice the marginal performance benefit provided by MQV. The reason that Certicom has so many patents and patents pending worldwide, despite having contributed so few ideas, is that it keeps splitting its patent applications. For example, the original MQV patent filings in early 1995 ended up being split into an incredibly redundant collection of US patents 5761305, 5889865, 5896455, 5933504, 6122736, 6487661, 7243232, 7334127, 7779259, 8090947, and 8209533, not to mention the corresponding non-US patents CA2237688, DE69636815, EP0873617, etc. ---Dan ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
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, especially on an expensive, warrantee-covered server product that may at some point in its useful life be sent back to Dell for repair. https://en.wikipedia.org/wiki/Joint_Test_Action_Group JTAG is a very common debugging and configuration port/interface that is used on all sorts of microchips and embedded systems. Sometimes there is an actual pinned header on the Printed Circuit Board but even if it is missing or covered, the JTAG circuitry can still be accessed on common pins or traces somewhere on the board. On a Dell motherboard there are probably dozens of JTAG and other debug pins… which could probably be used for various purposes, but it’s impossible to eliminate or turn off availability of this kind, they are inherent to the functionality of the device. Some manufacturers do obfuscate and encapsulate sensitive components of their machines (i.e., on military parts), but as with anything, physical access == ownership of hardware. (I am a hardware technician and have used JTAG and similar functionality to debug and repair electronic equipment in the field.) Thank you for your work, …quite eye opening. Pretty much, if something can be done, it has and will be done, by somebody out there. Isaac Gorton Spokane, WA ibgor...@gmail.com On Jan 5, 2014, at 9:31 AM, ianG i...@iang.org wrote: 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. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] To Protect and Infect Slides
On Tue, Dec 31, 2013 at 3:13 PM, Jacob Appelbaum ja...@appelbaum.netwrote: Kevin W. Wall: On Tue, Dec 31, 2013 at 3:10 PM, John Young j...@pipeline.com wrote: 30c3 slides from Jacob Appelbaum: http://cryptome.org/2013/12/appelbaum-30c3.pdf (3.8MB) And you can find his actual prez here: https://www.youtube.com/watch?v=b0w36GAyZIA Worth the hour, although I'm sure your blood pressure will go up a few points. 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. Jacob, Okay, here's a question for you that I hope you can answer. Unfortunately, it may be a little OT for this list, so I apologize for that in advance. In your talk, you mentioned about the interdiction that the NSA was using on laptops ordered online. I'm assuming it would be too expensive and of little return for them to do that on all laptops ordered online, so likely they are only doing this for certain targeted individuals. If indeed that is the case, my question is, do you have any idea of how common this interdiction practice is and how they pull it off? Specifically, with respect to the how part, I mean how do they learn of a person of interest ordering a new laptop online to begin with? If it is via the POI's already compromised system, that is one thing, but if they are doing this via snooping on all the orders of all vendors who handle online laptop orders, that is much more disturbing. Informed speculation is okay as well, although we would appreciate stating it as such. Thanks in advance for your response, -kevin -- Blog: http://off-the-wall-security.blogspot.com/ NSA: All your crypto bit are belong to us. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[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 systems. Several years ago at a friends house I for some reason got to looking around the house with a magnifying glass and discovered some very small perfectly straight scratches on objects around the house. I thought that I could determine whether or not they were man-made because they just appeared too straight and something about them just looked funny. I attempted to align several magnifying glasses with alligator clamps and a metal base so that I could study the scratches under a variety of different lights. I tried ultra violet, green and red light from varying angles. Immediately I noticed that what I thought to be scratches were actually microscopic inscriptions. Unable to read them I went to the hardware store and procured a small pen microscope. By holding the green light at a 45 degree angle I could make out the words THE UNITED STATES OF AMERICA written multiple times. The words themselves were inscribed so perfectly that they appeared to be a scratch to the naked eye. At 75x magnification in all caps they were barely legible. After finding this I began to wonder how it had been done. All that I can figure is that the NSA is using nanites to spy on us. If this is accurate then they have a device that is essentially comprised of millions of nanites that have cutting tools and exhibit swarm behavior that work collectively to infiltrate computer systems by cutting directly into our boards and chips. These devices are mobile hardware trojans. Dont ask me how something so small could be capable of transmitting but I have witnessed it. Whatever frequency they are emitting is not a standard electromagnetic frequency. I believe that they are emitting some other type of frequency that is maybe positronic or some other wierd science. The NSA has all the geniuses. Sent from Yahoo Mail on Android ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
