On Sat, Jan 18, 2014 at 12:16 PM, gwen hastings <gwen@cypherpunks.to> wrote:
... Now in the secure phone case .. there is NO way to know that you are secure against NSA TAO even if ALL source code to the phone apps and the base band processor firmware is published.. not even if the VHDL code for the IC design is published..
does mean we stop trying and give up?? hell no...think of it as a economic problem even classifying enough crypto at realtime speeds for capture turns into a major pain the the ass even on Narus boxen.
indeed, useful as a cost deterrent even if fallible. and of course, it's fun trying to protect against these attacks (e.g. playing on "Hard Mode"). for some definition of "fun"...
but all claims of NSA proof are indeed basically somewhat fraudulent as its a guarantee that no one checked out the chip design software for auto insert logic additions to their cell libraries. And with TAO placing teams of engineers its almost a sure bet that the IC libs are contaminated either with active flaws or simply important ones that never got reported. And etc ad nauseam from the silicon on out..
the short list of mandatory steps to play the game: - never mess up! one mistake can be catastrophic. (this means developing habits) - source all hardware through retail outlets paid in cash. (avoid targeted supply chain inserts) - review all open source components related to key generation, management, derivation, zeroisation. or have someone you trust do so. (see also: crowd funded TrueCrypt audit) replace unsatisfactory parts with better ones. (still using my own rngd; so glad to not have to roll my own FDE boot and key mgmt anymore!) - use extensive defense in depth. Virtualization/Qubes, operating system DACLs, user space separation, network isolation, offline-only key management, the list is infinite! - monitor everything: network traffic pre-encryption, running processes, system calls, event logs, RF signals, sounds, power consumption, at the highest granularity possible. analyze what you monitor for anomalies and failures. (if you aren't watching, you won't know when you've caught something interesting, and/or need to harden some first line defenses) - custom build critical software components: kernel, crypto libs, secure applications (ssh,openvpn,etc), high risk browsers, email clients, chat clients, document viewers. (vast majority of exploits are tailored for common builds - if you build your own with custom configuration, suites, supported features, exploitation becomes a tailored and time consuming effort against your specific system) - employ camouflage to further thwart attempted attacks and increase the likelihood they'll be detected. look like WinXP but be a FreeBSD, claim to be Firefox with plugins such and such while actually running hardened chromium, spoof versions and platforms, etc. etc. - employ userspace entropy collection, hardware entropy sources, and strong entropy mixing across all applications, always! you may need libc hooking or dalvik interception to make built-in entropy sources not suck. (e.g. substrate for Android, LD_PRELOAD, etc.) entropy is a lucrative target, hard to verify, and often overlooked - make it a priority! - physical security is paramount: evil maid attacks, covert hw keyloggers, TEMPEST leaking cables. if they get their hands on it, it is pwned! (this may cramp your lifestyle) - operational security: don't even know where to begin with this one. bonus points for getting the fed chick[0] to take a bowl hit ;)
gh(who is now finally picking up the python language in a serious way)
excellent; i like Python quite a bit for many tasks, and you'll want to spend a week going through pypy/pip looking at useful modules. other languages on my short list: - C/C++ (it's everywhere. it will remain everywhere.) - Scheme/Lisp (for the perspective more than utility) - Ruby/PHP/PERL (good complements to Python. except PHP, which should be hated and ostracized :) - Bash/Csh/PowerShell (scripting++) - Go/C#/Java (you're going to want to know these sooner or later) what would you add, and why? best regards, 0. not trying to be a dick, but a dismissive chick label in this situation intentional. employing attractive women (or men?) to HUMINT targets may be par for the social engineering conference course, but subterfuge based in sexual wiles == cheap shots and disrespect. oh how hard i had to work to stifle a chuckle when $fed_chick explained she was "in desktop security but moving into laptops..." see also: "beware strangers with candy" best regards,