Slashdot Mirror

"not technically feasible"...well, go read A Formal Security Analysis of the Signal Messaging Protocol and get back to us. Depending on who he is calling, end-to-end encryption is very much technically feasible. Trump could install this app on his iPhone, and tell the people who he's calling to install it as well. Either he is just too stupid to do this, OR he really wants other parties to listen in. Halon's Razor in action.

For those who are wondering, here's how it works:

For those who are really wondering how it works, I believe this paper is the relevant one: https://eprint.iacr.org/2017/7...

Bram founded a new company, https://chia.net/ which is making a new bitcoin-derived crypto-currency based on Proof of Space and Time. Basically it fills the unused space on your drive with entropy, and uses this like a set of lottery tickets instead of Proof of Work mining. They're also focusing on features of the crypto-currency that will enhance "Layer 2" (like http://lightning.network/) to enable scalability. In an economic sense this construction shifts the costs of mining toward capital expenditure (for storage) instead of electricity consumption.

He and a collaborator recently won Best Paper at Eurocrypt 2018 for a Zero Knowledge Proof of Time https://eprint.iacr.org/2018/1... (presentation: https://cyber.stanford.edu/sit... )

Interesting things are coming from Bram.

To add to your points even experienced respected cryptographers fuck it up some times. Doing cryptography is hard and doing it right is even harder. Concepts like confusion and diffusion are difficult to master and implement. The a good bet for an amateur would be to take an existing block cipher and increase the round count if they wanted to roll their own but then they would need to also generate more round keys. So maybe the best course of action would be to take a 3DES approach to AES and create 3AES. If someone told me today to make some custom block cipher that is what I would do as it would be no worse than existing AES.

and then when it crashes and you can't slave it into another system to get data from it, you're hosed.

What are you talking about? You can decrypt a FileVault volume from any connected Mac machine, if you know (or can guess) the password. I've personally done this, it works fine.

As far as brute-force protection, the PBKDF is set to about 250ms. So depending on the entropy of the password could take anywhere from 20 computer days (or a few hours on a big AWS instance) to 8000 years (beyond all the computing power on planet earth).

I have for most of my life assumed processors had an infinite well of side channels vendors have not the will to ever address with exploitation of cache/prediction schemes being obvious.

I know for a fact people have been talking about this for decades. You can find publically available examples as this 2006 article attacking RSA using branch predictor side channel. https://eprint.iacr.org/2006/2...

Then we have all of the Power/RF tempest crap.

Vendors should address this with a holistic secure design rather than endless piecemeal drip drip drip of look what I found lets slap a label on it and slow shit down even more.

Vendors releasing unreliable code that makes things worse. Or solutions requiring new BIOS updates that manufacturers won't bother pushing or users won't bother installing leaving a bunch of people randomly vulnerable. The piecemeal reactionary approach sucks ass.

From my understanding, it's not even incompetence that brought this about in the first place. Lack of foresight more than anything else. No one imagined trying an exploit like these until recently. Unless they have, but have been
keeping it quiet, much like the Allies kept the cracking of Enigma quiet...

People did more than imagine. They wrote research papers on this very topic over a decade ago about the very thing the spectre ghost is holding in its hand.

https://eprint.iacr.org/2006/2...

These attacks are a sort of new category of security analysis--realizing that out of order execution can have side effects, and that programs can check for those side effects to leak program state and system memory.

They are not new in any shape or form.

https://eprint.iacr.org/2006/2...

Maybe you should read Section 6.6.5 of this document, which makes it likely - though hard to tell certainty, because Intel improperly documents the ME - that SGX can be compromised from a compromised ME, instead of quoting wikipedia?

Can we get a consumer-level tape drive, something that works with USB 3.x, costs around $1000, with media costing $10-25 a cartridge, with an actual archival life, and some basic features like AES-256 encryption and compression in hardware? Having WORM media would be nice as well.

This would solve a ton of storage/backup issues. A lot of people don't have the network connection to make cloud backups (much less complete disaster recoveries) feasible. People may not trust the cloud. Regulations may prohibit use of a remote backup provider. Or, someone just likes having the peace of mind of physical control of their data on media which might last past the end of this decade.

There are tons of high capacity optical offerings available (Sony has some)... but other than specialty markets, they are not worth it. What would be nice would be a tape or even an optical drive for backups.

Optical wouldn't be bad either. 400 CD jukeboxes are a solved problem, so having a BD-like format with 2-3 terabytes per disk would solve a lot of backup problems, especially with WORM capability to fend off ransomware.

Can we get a consumer-level tape drive, ... and some basic features like AES-256 encryption ...

This is an accident waiting to happen. Every vendor implements encryption as they see fit, usually storing keys on either an EEPROM, flash, or battery-backed RAM -- or if you're lucky, some unused or segregated part of the tape (might waste a few blocks but that's OK). It sounds great at first, until the product in question stops working / dies / goes EoL. You were using Vendor X's drive, but now you've found Vendor Y sells a drive that supports your OMG-2113 tape form factor... except none of their contents can be read because of vendor encryption incompatibility (i.e. the tapes are considered empty). Your only choice is to scour eBay to find a replacement tape drive from Vendor X, same model, same revision, same F/W, all while praying the encryption keys are stored on some part of the tape and not the drive itself.

This is an actual real-world problem that applies to more than just tape drives -- in actuality, USB hard disks (particularly those with USB/SATA bridges) have this exact problem. Take drive from Vendor X's product and stick it in Vendor Y's product -- or even Vendor X's own product but a different model/revision -- and you'll find none of your data is accessible (i.e. drive's contents either look blank or are gobbledegook). If you think I'm kidding, I recommend reading, not skimming, this paper -- this is why I don't buy USB/SATA enclosures that have AES encryption on them (and as someone who does data recovery, they're a nightmare!). Do the encryption using software on the host, i.e. something you have control over. Don't get screwed by vendor lock-in -- your data = your responsibility!

On older tape drives, toggling this type of feature (ex. encryption, compression, etc.) was done with physical DIP switches -- which is exactly how it would be need to be implemented today. Implementing it through software, through some vendor-specific SCSI CDB, would be a nightmare of a different type (some drives do implement this, but as I said, it's usually through a custom SCSI CDB that isn't described in documentation, i.e. "black box magic smoke").

At an old job in the late 90s, we used Sony AIT SDX-500C drives in a Qualstar TLS-4000 library, and I explicitly toggled (disabled) drive-level compression via the DIP switches for this exact reason. We didn't need the space (50GB on non-compressed AIT-2) was perfectly fine at the time. I didn't want to take the chance of a newer model of Sony drive would consider our tapes blank, if the SDX-500C went EoL.

All that said: I fully agree that we need a consumer-grade backup device **that doesn't involve MHDDs**, is fairl

By which I mean, they're not environmentally sustainable. The current volume of Bitcoin is $9 billion, and it's estimated that the power used to mine the coins and keep the currency afloat requires the full output of a mid-sized nuclear power plant. There's no reason to think the Ether would be any different.

The cryptocurrency that wins is the one that uses "proof of useful work" instead of "proof of work" to secure the blockchain. One such scheme is REM, but even that requires trusting Intel.

This can only be done with a collision attack if the CA is really, really stupid. Proper CAs should include chain-length restrictions in their certificates.

Please correct me if I'm wrong, but it appears that most CAs are really, really stupid. Here's a list of the CAs included in Firefox: https://mozillacaprogram.secur... . I split the PEMs into a pile of files, and checked them:

$ for pem in * ; do openssl x509 -text -in $pem | grep pathlen ; done
        CA:TRUE, pathlen:4
        CA:TRUE, pathlen:1
        CA:TRUE, pathlen:1
        CA:TRUE, pathlen:7
        CA:TRUE, pathlen:7
        CA:TRUE, pathlen:3
        CA:TRUE, pathlen:5
        CA:TRUE, pathlen:12
        CA:TRUE, pathlen:12
        CA:TRUE, pathlen:12
        CA:TRUE, pathlen:12
        CA:TRUE, pathlen:3
        CA:TRUE, pathlen:10
        CA:TRUE, pathlen:3

So out of 172 root CAs only 14 include any path length restrictions, and even the ones who do still allow some chaining. This is what allowed the beautiful Short Chosen-Prefix Collisions for MD5 and the Creation of a Rogue CA Certificate to succeed.

I don't think the SHApocalypse will be tomorrow. This was an identical-prefix attack instead of a chosen-prefix which constrains the attacker considerably, and the computation required is much higher even to generate simple collisions. However, (again, please correct me if I'm missing something) it does seem plausible that that further weaknesses will be found which provide just enough leverage to forge a signature with one of those 172 CAs, and we may eventually see a rogue sha1WithRSAEncryption CA issued.

Taking the MD5 and the SHA1 of something isn't significantly more secure than just taking the SHA1 of said something. This was demonstrated in 2004 here: http://link.springer.com/chapt... This was then further elaborated and improved upon here: http://eprint.iacr.org/2008/07... So, don't concatenate hashes kids. It doesn't do what you think it does. Using a proper hash from the start is the only safe way to do things. Even if nobody has figured out how to do it yet the math conclusively shows that breaking SHA1+MD5 is not significantly harder than just breaking SHA1. This is why TLS 1.1 and earlier need to go away.

That's for concatenated hashes. As in, you hash the two hashes to form one number, usually by XOR'ing the numbers together. Which can be shown to increase the solution space considerably.

What I've been curious about, is if you maintain two hashes separately.

You have blob X here, with SHA-1 of S(X) and MD5 M(X). Can you find a blob Y with both a SHA-1 of S(X) and MD5 of M(X)?

It's easy to see if you XOR S(X) and M(X) you make it much easier - but what if we kept them separate, so the SHA-1 AND MD5 has to match. (With concatenation, you don't have to match, the final result has to match, but individually inside you have to find a S(Y)+M(Y) that equals S(X)+M(X), and not S(Y)==S(X) AND M(Y)==M(X).

The only concatenation that wouldn't be easier is if you literally concatenated the bytes together - so 128 bits of MD5 followed by 160 bits of SHA-1 to form a 288 bit MD5/SHA-1 hash that enforces the property that the two hashes individually MUST match simultaneously.

Taking the MD5 and the SHA1 of something isn't significantly more secure than just taking the SHA1 of said something. This was demonstrated in 2004 here: http://link.springer.com/chapt... This was then further elaborated and improved upon here: http://eprint.iacr.org/2008/07... So, don't concatenate hashes kids. It doesn't do what you think it does. Using a proper hash from the start is the only safe way to do things. Even if nobody has figured out how to do it yet the math conclusively shows that breaking SHA1+MD5 is not significantly harder than just breaking SHA1. This is why TLS 1.1 and earlier need to go away.

If you are not a crypto expert, you are going to rely on libraries or APIs or continue on to roll your own anyway. Crypto from scratch is hard to do correctly... look at all of the SSL vulnerabilities over the years. The math may be perfectly understood by this hypothetical person, but implementing that knowledge perfectly is another matter entirely.

My understanding of the OpenSSL and SSL issues you reference was not due to the cypto, well there was a lot of legacy crap that could be fallen back to (thanks Bill Clinton), but instead mostly due to the huge amount of crap in OpenSSL and that weird heartbleed bug. Now if you want to talk about screwing the pooch on crypto algorithms there is this little one that went unnoticed from 1998 to 2009. Basically it means that the confusion in the SERPENT cipher isn't as strong as was initially thought having a non-linear order of 2 instead of the claimed 3. This was something one would have thought would have been easily caught by all the experts doing the evaluation of the AES finalists but was missed. Granted the large number of rounds used should make up for this overlooked weakness.

they don't have a working exploit.

Yes they do. The abstract of the linked paper states clearly: "we exploit this flaw to define a forgery attack"

Their demo exploit is an app, malware, and could be used by any other user, criminal, three-letter agency capable of such advanced techniques as *getting malware* onto target device. The linked article further expands on this to point with comments from the author, highlighting that anyone with a 0-day or known exploit would be able to degrade KeyStore encryption to crackable levels, without first having to trick a user into installing their app.

Qualcomm isn't mentioned at all in the fucking paper itself

Shut your filthy Commie Islam loving pie hole. /sarcasm

Although it does look like AES 256 has some problems with related key attacks.

As someone who has recently had my interest in this topic reignited you are correct that it is mostly about understating how to break crypto that leads to better crypto. Understanding the math isn't all that difficult if you have an applied math (CS) degree and a willingness to learn as when I was first interested in crypto about 20 years ago there wasn't as much info freely available to learn from and what was there was difficult to find. All of the major symmetric key crypto algorithms are just variations on the Feistel Network structure going back to the early 70s. Here is a paper I was reading just last night on the evaluation on all 16! 4x4bit s-boxes but most ciphers use 8x8-bit S-boxes. There is also a lot that can be learned by looking back at the NIST evaluations of the AES finalists and reading and understanding them.

Apparently the older RSA-and-imitators fobs were a bit shaky; so there would be real reason for concern if anyone is still making authentication 'apps' based on it(recording the token's output every 60 seconds for a couple of months to a year, depending on your luck, would be a serious pain in the ass with a hardware token in someone else's possession; but becomes much more viable if the phone OS allows(whether by design or failure) your application to access the display output of another application. Though, as you mention, in the case of 'soft tokens', if you are privileged enough on the phone to be reading over the target's shoulder, you can probably just grab the initialization value directly; and once you have that absolutely nothing distinguishes your cloned token from the 'real' one.

The SATA interface is exposed on most of these PCBs at solder points E71 (XMT/A+), E72 (XMT/A-), E73 (XMT/B-), and E75 (XMT/B+). For these to work, a few nearby capacitors need be desoldered, which in turn "disables" the chip that handles the USB chip/interface. The drives themselves still fully support native ATA protocol. Sometimes, alternately you can find drop-in replacement PCBs that provide a native SATA interface (usually taken mobile 2.5" drives). You can find most of this information online (try www.hddoracle.com).

What isn't immediately disclosed on most (all?) of the sites is the fact that on these USB-interface-only WD drives, the USB chip is also what's doing transparent hardware encryption/decryption of the data that goes to the MCU to be written to/read from the platters. This is usually enabled/in place regardless of what's stated on the box (i.e. WD USB 3.0 2TB Passport "Silver" drives make no mention of encryption yet its being done). So even if you do all the wiring legwork or go through the pain of getting a SATA-based PCB (and dump the contents of two SPI EEPROM chips, U12 and U14, and move the contents of U12 to the SATA-based PCB's U12 -- these are either 8-pin SOIC or VSOP chips, i.e. SMT, and if they're VSOP you can't use a SOIC clip to dump/flash them due to the smaller-height form factor), and everything "magically works", your data is still encrypted.

There are several ways to deal with this, none of which are economically feasible for most end-users. The most common recommendation is to invest in a US$8000+ hardware/software tool called PC-3000 from ACE Labs. Another you'll seen thrown around is to use a SATA/USB bridge adapter used in WD MyBook drives (which is like playing roulette -- you don't know what adapter/conversion board you're going to get when you buy one of these things, so the odds of it being 100% compatible with your drive's PCB is unlikely).

What isn't immediately disclosed about the latter is that there are several USB ICs WD chooses to use, none of which are compatible with one another, and there's no standard/commonality in the encryption methods. Sometimes they switch IC vendors on the same product line (e.g. that Silver drive you bought 3 months ago might use a different chip than the one you bought yesterday). The most common I've seen are JMicron (there are two common ICs), and Initio (there are several ICs).

A full paper was published about some (not all) the different chips used and their encryption, several of which are "half-ass" -- but regardless of being such, still make it painful to get data from the platters in the case the main PCB fails. To my knowledge there is still no mainstream (e.g. free) software that can do this decryption if you were to give the software, say, a raw disk image (e.g. using dd) of the encrypted drive (still surprising, since at least for the older JMS538S it looks like it should be doable).

What also isn't disclosed about the "SATA replacement PCB" drop-ins is that they aren't always compatible with the physical hard disk enclosure. For example, it's stated that the SATA PCB version of the 2060-771961-001 is the 771960, however this isn't drop-in compatible due to use of physically larger SPI EEPROM chips. Why would the physically-larger chip be a problem? Because the actual metal/steel of the hard disk enclosure itself doesn't have a deep or wide enough cut-out where the chip would normally sit (when the PCB is mounted), so the PCB can't actually sit flush with the 18-pin I/O interconnect used between the drive and the PCB.

Source: my own experience, when attempting to recover data from two WD My Passport 2TB drives for a friend of a friend as a favour. (I restored 100% of the data off the Silver drive after doing a bit of work writing some scripts for hddsupertool that did VSC (vendor-specific) ATA commands, but wasn't able to with the Black due to what was likely likely a stuck head -- I don't do head stack replacements). I post

International Association for Cryptologic Research : https://www.iacr.org/petitions...

" We are deeply concerned about Australia's Defence Trade Controls Act (DTCA). The act prohibits the "intangible supply" of encryption technologies, and hence subjects many ordinary teaching and research activities to unclear, potentially severe, export controls. As an international organization of cryptographic researchers and educators, we are concerned that the DTCA criminalizes the very essence of our association: to advance the theory and practice of cryptography in the service of public welfare.

We affirm that the public welfare of Australians — and society in general — is best served by open research and education in cryptography and cybersecurity. Open, international scientific collaboration is responsible for the encryption technologies that are now vital to individuals, businesses, and world governments alike. The current legislation cuts off Australia from the international cryptographic research community and jeopardizes the supply of qualified workforce in Australia's growing cybersecurity sector.

We call on Australia to amend their export control laws to include clear exemptions for scientific research and for education."

It's actually really difficult to run relay attacks over any kind of distance due to latency. There's a few papers on it, I found one with a brief google: https://eprint.iacr.org/2010/228.pdf. The technology they used was Bluetooth, they considered and discarded SMS and GPRS/3G as having too high a latency to meet the NFC spec.

Australian banks rolled out contactless payments years ago, there's been concern on and off since, but no major incidents reported. The kind of attack pictured in the photoshopped article is technically possible though difficult (about as difficult as physical pickpocketing - you have to get within a couple of centimeters and hold still for 2-3 seconds).

However, even if they can pull it off, there's a couple of other issues. Firstly, the charges are easily reversible and the merchant account will get canned well before settlement, it's unlikely they can receive any money from the effort. There's a good chance that if they've stolen or "borrowed" a machine serviced by a bank or larger payment processor, they will simply pause payments and notify the AFP, and they'll be able to track the machine's location when it connects for online processing or offline batch.

Secondly, contactless payment readers don't like it when more than one card is in range. I've had various NFC/RFID library cards, public transport passes, health insurance, student IDs, driver's licenses, etc in my wallet for at least 12 years (just looking at the issue dates for cards in there right now). Most adults would have at least 2. I only realised my bank had issued a contactless card (about 7 years ago now) when my GO card (public transport) stopped working when I slapped my whole wallet against the reader.

I personally have a nice-looking NFC-shielded leather wallet because it really doesn't cost anything extra to be sure. You can reduce your no-verification payment limit down to $1 if you want, and some banks will remove the option altogether. I actually really like the convenience. Plus, the card is rarely out of my hand during a transaction, I'm more likely to notice a missing/stolen card than someone copying a stripe under the desk and eyeballing my PIN.

AU processors no longer accept signature verification, so it's all swipe & PIN, chip & PIN or contactless (no PIN $100 by default).

This is an area that has seen quite a bit of research and there are ways to hash fingerprints. I little google searching led to Fuzzy Extractors which create a cryptographic key from biometric data and Fuzzy Vaults that store fingerprints in a secure way.

https://en.wikipedia.org/wiki/...
http://www.cse.buffalo.edu/tec...
https://eprint.iacr.org/2004/0...

The story is here:

http://www.theregister.co.uk/2015/10/09/sha1_75k_attack

The research paper is here:

http://eprint.iacr.org/2015/967.pdf If one takes time to read the paper, which obviously the writer(s) for the Register did not, you will find the only computational work reported is on a cluster of 64 GTX970 GPU's. Table 5-1 of the paper reports on the run time on this cluster to compute the disturbance vectors they used.

The authors estimated it would take $2K in Amazon EC2 time to compute the DV's computed on their cluster. From this an additional extrapolation was made to come up with an estimated value of $75-125K to actually carry out the computational effort required to locate a second pre-image collision against SHA-1.

No EC2 computing time was used in this paper and there was no $75K dollars spent. The time on the Tesla cluster was donated by a collaborator. Most of all a second pre-image collision was not reported in this paper. In fact the authors purposefully call out in the abstract that their findings do not directly imply a SHA-1 collision.

None of this minimizes that the days of SHA-1's utility as a cryptographic hashing function with a strong second pre-image guarantee are limited. It also doesn't imply that as an industry we should move quickly to SHA-2 and preferably SHA-3/Keccak.

It does indicate, however, that the security industry would benefit from reporting by individuals who have strong grounding in engineering and the scientific method.

I'm wondering if they really fixed this kind of vulnerability too. If you read the paper it seems that that device they added to the card was not fully compliant with the spec, not by a long way. So the most obvious and quick mitigation is to test for something that it is not compliant in. Such a test could be quickly bypassed once discovered, and turn the whole thing in to a game of cat-and-mouse like the fake cable TV cards became.

Given neat tricks like recovering the RSA key GnuPG is using with nothing but a relatively unexceptional microphone recording of the noise emitted by the computer's power circuitry actually work; it seems quite plausible that you could detect abnormalities in operation based on measurements of the device's sound, heat, and so on.

What seems markedly trickier is dealing with devices whose behavior is variable enough that defining 'abnormality' is hard and generating a baseline 'fingerprint' isn't obvious. If the device's behavior is nice and predictable, you could theoretically force the attacker's malware to be extraordinarily similar to the legitimate software in order to evade detection. If not, though, the really nasty challenge would seem to be less in the measurement and more in knowing what signals to freak out about.

Unelected ignorant arrogant public servants in Australia are censoring bioresearch http://victimsofdsto.byethost3...

Censoring teaching encryption too https://www.iacr.org/S=Jl1

Censoring everything http://www.cla.asn.au/News/def... http://defencereport.com/austr... http://science.slashdot.org/st...

What is your motivation for saying these things?

Distrust of an untustworthy government, I'd imagine.

How about you prove him wrong, if you feel so strongly about Intel's virtue?

Proof is for mathematicians. Oh look, here's one: https://eprint.iacr.org/2014/5...

What is that method? How does it differ from current encryption techniques? Why is that well suited to encrypting against quantum computers? How did you come to that conclusion, given that you don't have one to test against?

I'm one of the authors of the research that was discussed. Unfortunately, the MIT Technology Review article doesn't contain much detail. Here's a link to our research paper: https://eprint.iacr.org/2014/5....

The scheme uses a mathematical primitive called the "ring learning with errors (RLWE) problem". Rather than multiplying large prime numbers together like in RSA encryption or using points on a curve like in elliptic curve cryptography, here the mathematical operation is based on multiplying polynomials together, and then adding small random noise. An analog of this is solving systems of linear equations: if you took first year linear algebra, you might remember that if I give you a matrix A and a vector b, you can use Gaussian elimination (row reduction) to find a vector x such that Ax=b. But it turns out that if I add a small random noise vector e, and give you A and (Ax+e), it becomes much harder to find x. Our work is about actually using RLWE, seeing how to design a key exchange protocol that's suitable for use in SSL/TLS and then implementing and testing it. (Here are some slides from a recent talk I gave about the research, which try to explain the problem in more detail: http://files.douglas.stebila.c...)

RLWE isn't our invention -- we build on existing research by Regev, Peikert, and others, and RLWE has been studied for a few years now. RSA and elliptic curve cryptography can be broken by quantum computers because they have a certain periodic structure that can be easily detected by a quantum computer using a quantum algorithm invented by Shor. But RLWE, and several related problems, don't seem to be susceptible to Shor's algorithm, nor to any of the other quantum algorithms that give an exponential speedup over normal classical computers. No one in the research community today knows if RLWE is hard for quantum computers, but right now people accept it as a promising candidate, and it is being explored for a variety of uses. If after years of cryptanalytic research no one manages to break it, then it may achieve the corresponding levels of confidence that the research community has in the difficulty of currently accepted problems, like factoring or elliptic curve discrete log.

I'm one of the authors of the research that was described in the article. Here's a link to our research paper for more information: https://eprint.iacr.org/2014/5...

You probably didn't understand. You being able to prove that a given ballot is yours is not the same thing as someone else being able to prove that a given ballot is yours. There are elaborate protocols for individual people to speak up and prove that their votes have been miscounted without compromising everyone else's secrecy. See Remotegrity for example: https://eprint.iacr.org/2013/2... (I'm not advocating this as it's ridiculously complex; but some seemingly impossibly problems really can be solved using advanced crypto.)

Such as this?

https://eprint.iacr.org/2013/4...

"We demonstrate the efficacy of the FLUSH+RELOAD
attack by using it to extract the private encryption keys
from a victim program running GnuPG 1.4.13. We tested
the attack both between two unrelated processes in a sin-
gle operating system and between processes running in
separate virtual machines. On average, the attack is able
to recover 96.7% of the bits of the secret key by observ-
ing a single signature or decryption round"

Rgds

Damon

It's not so useless, Mr. Cafe. Case in point:

Bitcoin attack: https://eprint.iacr.org/2014/1...

GnuPG attack: http://www.nicta.com.au/pub-do...

ASLR attack: http://www.internetsociety.org...

All of these are cache-based side-channel attacks.

Stealing Keys from PCs using a Radio:
Cheap Electromagnetic Attacks on Windowed Exponentiation

http://www.cs.tau.ac.il/~trome...

"Overview

We demonstrate the extraction of secret decryption keys from laptop computers, by nonintrusively measuring electromagnetic emanations for a few seconds from a distance of 50 cm. The attack can be executed using cheap and readily-available equipment: a consumer-grade radio receiver or a Software Defined Radio USB dongle. The setup is compact and can operate untethered; it can be easily concealed, e.g., inside pita bread. Common laptops, and popular implementations of RSA and ElGamal encryptions, are vulnerable to this attack, including those that implement the decryption using modern exponentiation algorithms such as sliding-window, or even its side-channel resistant variant, fixed-window (m-ary) exponentiation.

We successfully extracted keys from laptops of various models running GnuPG (popular open source encryption software, implementing the OpenPGP standard), within a few seconds. The attack sends a few carefully-crafted ciphertexts, and when these are decrypted by the target computer, they trigger the occurrence of specially-structured values inside the decryption software. These special values cause observable fluctuations in the electromagnetic field surrounding the laptop, in a way that depends on the pattern of key bits (specifically, the key-bits window in the exponentiation routine). The secret key can be deduced from these fluctuations, through signal processing and cryptanalysis."

###

Cryptology ePrint Archive: Report 2015/170

http://eprint.iacr.org/2015/17...

"Stealing Keys from PCs using a Radio: Cheap Electromagnetic Attacks on Windowed Exponentiation

Daniel Genkin and Lev Pachmanov and Itamar Pipman and Eran Tromer
Abstract: We present new side-channel attacks on RSA and ElGamal implementations that use the popular sliding-window or fixed-window (m-ary) modular exponentiation algorithms. The attacks can extract decryption keys using a very low measurement bandwidth (a frequency band of less than 100 kHz around a carrier under 2 MHz) even when attacking multi-GHz CPUs.

We demonstrate the attacks' feasibility by extracting keys from GnuPG, in a few seconds, using a nonintrusive measurement of electromagnetic emanations from laptop computers. The measurement equipment is cheap and compact, uses readily-available components (a Software Defined Radio USB dongle or a consumer-grade radio receiver), and can operate untethered while concealed, e.g., inside pita bread.

The attacks use a few non-adaptive chosen ciphertexts, crafted so that whenever the decryption routine encounters particular bit patterns in the secret key, intermediate values occur with a special structure that causes observable fluctuations in the electromagnetic field. Through suitable signal processing and cryptanalysis, the bit patterns and eventually the whole secret key are recovered.

Category / Keywords: side channel, electromagnetic analysis, RSA, ElGamal

Date: received 27 Feb 2015, last revised 3 Mar 2015

Contact author: tromer at cs tau ac il"

#####
EOF

Stealing Keys from PCs using a Radio:
Cheap Electromagnetic Attacks on Windowed Exponentiation

http://www.cs.tau.ac.il/~trome...

"Overview

We demonstrate the extraction of secret decryption keys from laptop computers, by nonintrusively measuring electromagnetic emanations for a few seconds from a distance of 50 cm. The attack can be executed using cheap and readily-available equipment: a consumer-grade radio receiver or a Software Defined Radio USB dongle. The setup is compact and can operate untethered; it can be easily concealed, e.g., inside pita bread. Common laptops, and popular implementations of RSA and ElGamal encryptions, are vulnerable to this attack, including those that implement the decryption using modern exponentiation algorithms such as sliding-window, or even its side-channel resistant variant, fixed-window (m-ary) exponentiation.

We successfully extracted keys from laptops of various models running GnuPG (popular open source encryption software, implementing the OpenPGP standard), within a few seconds. The attack sends a few carefully-crafted ciphertexts, and when these are decrypted by the target computer, they trigger the occurrence of specially-structured values inside the decryption software. These special values cause observable fluctuations in the electromagnetic field surrounding the laptop, in a way that depends on the pattern of key bits (specifically, the key-bits window in the exponentiation routine). The secret key can be deduced from these fluctuations, through signal processing and cryptanalysis."

#####

Cryptology ePrint Archive: Report 2015/170

http://eprint.iacr.org/2015/17...

"Stealing Keys from PCs using a Radio: Cheap Electromagnetic Attacks on Windowed Exponentiation

Daniel Genkin and Lev Pachmanov and Itamar Pipman and Eran Tromer
Abstract: We present new side-channel attacks on RSA and ElGamal implementations that use the popular sliding-window or fixed-window (m-ary) modular exponentiation algorithms. The attacks can extract decryption keys using a very low measurement bandwidth (a frequency band of less than 100 kHz around a carrier under 2 MHz) even when attacking multi-GHz CPUs.

We demonstrate the attacks' feasibility by extracting keys from GnuPG, in a few seconds, using a nonintrusive measurement of electromagnetic emanations from laptop computers. The measurement equipment is cheap and compact, uses readily-available components (a Software Defined Radio USB dongle or a consumer-grade radio receiver), and can operate untethered while concealed, e.g., inside pita bread.

The attacks use a few non-adaptive chosen ciphertexts, crafted so that whenever the decryption routine encounters particular bit patterns in the secret key, intermediate values occur with a special structure that causes observable fluctuations in the electromagnetic field. Through suitable signal processing and cryptanalysis, the bit patterns and eventually the whole secret key are recovered.

Category / Keywords: side channel, electromagnetic analysis, RSA, ElGamal

Date: received 27 Feb 2015, last revised 3 Mar 2015

Contact author: tromer at cs tau ac il"

####
EOF

I mean, why are these keys not just broadcasting an "I'm here" signal (possibly with a unique id), and then doing some challenge/response authentication ala SRP that can't have the key reverse engineered from the transmissions to actually perform the unlock.

How did the car companies think they could get away with such crappy security?

Many cars actually implement the exact protocol you describe. But they are not secure at all. With such systems, you can just relay the signals between the key and the car, and the car will happily unlock the door even if the owner of the key is potentially some kilometers away.
So either you have a key fob where you have to actively push a button to open the car, or you need some kind of distance-bounding protocol that ensures that the key is in vicinity of the car by measuring the time it takes to respond to some query, and relating this to the speed of light to ensure that no attacker who is farther away could have sent the signal.

It is pretty common to "vet" academic papers before publishing, so that other people can give a qualified input etc. So it is hardly surprising that Lennart had "early access" to the paper. As I understand it, then "Forward security" is a pretty old crypto concept. What Marson and Poettering did was tweaking the concept to log files which represents special problems to more static texts like emails, and use the concept for sealing, not encryption. The concept seems sound and have been formally peer reviewed.

Here is the paper in case you haven't read it:
https://eprint.iacr.org/2013/3...

The objective of "mathematically proven security properties" via program obfuscation is definitely not achievable. After all, it's a given security principle of "security through obfuscation" is unsupportable. If an adversary is capable of obtaining the executable of a program, they can also reverse engineer that same executable. It may take a lot of effort, but it is always achievable.

That is the standard consensus view in the software industry, yes. I'm afraid to tell you though, that it's wrong.

Last year there was a mathematical breakthrough in the field of what is called "indistinguishability obfuscation". This is a mathematical approach to program obfuscation which has sound theoretical foundations. This line of work could in theory yield programs whose functioning cannot be understood no matter how skilled the reverse engineer is.

It is important to note here a few important caveats. The first is that iO (to use the cryptographers name) is presently a theoretical technique. A new paper came out literally 5 days ago that claims to discuss an implementation of the technique but I haven't read it yet. Will do so after posting this comment. Indeed, it seems nobody is quite sure how to make it work with practical performance at this time.

The second caveat is that the most well explored version of it only applies to circuits which can be seen as a kind of pure functional program only. Actually a circuit is closer to a mathematical formula than a real program e.g. you cannot write circuits in C or any other programming language we mortals are familiar with. Researchers are now starting to look at the question of obfuscating "RAM programs" i.e. programs that look like normal imperative programs written in dialects of, say, C. But this work is still quite early.

The third caveat is that because the techniques apply to pure functions only, they cannot do input or output. This makes them somewhat less than useful for obfuscation of the sort of programs that are processed with commercial obfuscators today like video games.

Despite those caveats the technique is very exciting and promising for many reasons, none of which have to do with DRM. For example iO could provide a unifying framework for all kinds of existing cryptographic techniques, and enable cryptographic capabilities that were hereto only conjectured. For example timelock crypto can be implemented using and iO obfuscator and Bitcoin.

The objective of "mathematically proven security properties" via program obfuscation is definitely not achievable. After all, it's a given security principle of "security through obfuscation" is unsupportable. If an adversary is capable of obtaining the executable of a program, they can also reverse engineer that same executable. It may take a lot of effort, but it is always achievable.

That is the standard consensus view in the software industry, yes. I'm afraid to tell you though, that it's wrong.

Last year there was a mathematical breakthrough in the field of what is called "indistinguishability obfuscation". This is a mathematical approach to program obfuscation which has sound theoretical foundations. This line of work could in theory yield programs whose functioning cannot be understood no matter how skilled the reverse engineer is.

It is important to note here a few important caveats. The first is that iO (to use the cryptographers name) is presently a theoretical technique. A new paper came out literally 5 days ago that claims to discuss an implementation of the technique but I haven't read it yet. Will do so after posting this comment. Indeed, it seems nobody is quite sure how to make it work with practical performance at this time.

The second caveat is that the most well explored version of it only applies to circuits which can be seen as a kind of pure functional program only. Actually a circuit is closer to a mathematical formula than a real program e.g. you cannot write circuits in C or any other programming language we mortals are familiar with. Researchers are now starting to look at the question of obfuscating "RAM programs" i.e. programs that look like normal imperative programs written in dialects of, say, C. But this work is still quite early.

The third caveat is that because the techniques apply to pure functions only, they cannot do input or output. This makes them somewhat less than useful for obfuscation of the sort of programs that are processed with commercial obfuscators today like video games.

Despite those caveats the technique is very exciting and promising for many reasons, none of which have to do with DRM. For example iO could provide a unifying framework for all kinds of existing cryptographic techniques, and enable cryptographic capabilities that were hereto only conjectured. For example timelock crypto can be implemented using and iO obfuscator and Bitcoin.

The objective of "mathematically proven security properties" via program obfuscation is definitely not achievable. After all, it's a given security principle of "security through obfuscation" is unsupportable. If an adversary is capable of obtaining the executable of a program, they can also reverse engineer that same executable. It may take a lot of effort, but it is always achievable.

That is the standard consensus view in the software industry, yes. I'm afraid to tell you though, that it's wrong.

Last year there was a mathematical breakthrough in the field of what is called "indistinguishability obfuscation". This is a mathematical approach to program obfuscation which has sound theoretical foundations. This line of work could in theory yield programs whose functioning cannot be understood no matter how skilled the reverse engineer is.

It is important to note here a few important caveats. The first is that iO (to use the cryptographers name) is presently a theoretical technique. A new paper came out literally 5 days ago that claims to discuss an implementation of the technique but I haven't read it yet. Will do so after posting this comment. Indeed, it seems nobody is quite sure how to make it work with practical performance at this time.

The second caveat is that the most well explored version of it only applies to circuits which can be seen as a kind of pure functional program only. Actually a circuit is closer to a mathematical formula than a real program e.g. you cannot write circuits in C or any other programming language we mortals are familiar with. Researchers are now starting to look at the question of obfuscating "RAM programs" i.e. programs that look like normal imperative programs written in dialects of, say, C. But this work is still quite early.

The third caveat is that because the techniques apply to pure functions only, they cannot do input or output. This makes them somewhat less than useful for obfuscation of the sort of programs that are processed with commercial obfuscators today like video games.

Despite those caveats the technique is very exciting and promising for many reasons, none of which have to do with DRM. For example iO could provide a unifying framework for all kinds of existing cryptographic techniques, and enable cryptographic capabilities that were hereto only conjectured. For example timelock crypto can be implemented using and iO obfuscator and Bitcoin.

I wouldn't use RSA and I don't need SHA (though your assertion that SHA is difficult to fit in a uC is absurd). And like I said I don't need or want HTTP in my light sockets.

Having said that there are fucktons of uC that implement AES in hardware, particularly ones that integrate 802.15.4 PHYs which is exactly the sort of thing you would use in a wireless light or telethermometer.

For example, ok so 9x9mm is not exactly tiny, but there aren't many uCs smaller than that implementing radio PHYs. It has hardware AES, an 802.15.4 PHY, 128kb of program flash and 16kb of ram, plenty enough to implement an Edwards curve ECC scheme like Ed25519, or even RSA if you wanted to. I don't know why you would use RSA when it is slower, less secure and requires more memory than Elliptic curve crypto. It's also important to remember that you only need to compute a digital signature once for each association of the mote with the aggregator. Once you have agreed on an AES key for the association, you only need to use the hardware's AES instructions and compute a UMAC digest (fast) for each message. I would definitely use UDP. TCP is complex and not robust even when implemented correctly.

but you won't even have the flash and RAM space to properly fit a SHA or RSA algorithm in the smaller ones.

Oh really?

Recently a lot of authors studied the efficiency of elliptic curve cryptosystems on microcontrollers which are used in wireless sensor motes. They focus on the TI MSP430 and the ATmega128 developed by Atmel. Gura et al. first reported the efficiency of elliptic curve cryptosystems defined over prime fields on the ATmega128 in [16]. They used curves published in the recommendations of SEC[8]. The execution time of one ECDSA signature generation is 810 ms at 8MHz. Work by Uhsadel and Scott [22,26] further improves speed results on the ATmega128.

In this paper we will study the efficiency of optimal extension fields, prime fields as well as binary fields for the ATmega128. We will show, that the run times for a multiplication in GF(2^167) takes less than 1ms, if the memory accesses are decreased as much as possible. Furthermore we will take side channel attacks into account and measure the run times of elliptic curve scalar multiplication resistant to simple side channel attacks for several finite fields of different characteristic. It turns out, that binary fields are the optimal choice for elliptic curve cryptography if the Montgomery-Ladder can be used.

captcha: provoked

It's really not that hard to design a provably secure random number generator without a backdoor. My colleagues at Waterloo did it. Here's another construction. And another. For that matter, you could even backdoor-proof Dual-EC-DRBG itself, by reducing the output rate by 16 to 33%, depending on the curve size (so that it's 5/6th to 2/3rds as fast as before). Any of these choices would be more appropriate than simply keeping the algorithm as-is.

cryptanalysis can break your encryption even without access to your encryption algorithm

I doubt it. That may have been true back when people used substitution ciphers and encrypted plain text. Today's ciphers scramble large blocks and precompress to increase data entropy. I seriously doubt anybody but a top-notch cryptoanalyst can decrypt even the simplest attempt at a cipher from anybody who knows anything at all about cipher design.

Such a cryptoanalyst is likely to be found only at some high level government agency like the NSA and he will likely be too busy to spare any time to decrypt your inane emails to your mistress. Consequently, I would postulate that if you design your own cipher and avoid becoming the next Snowden, your data will be just as safe as if you had used AES.

Which is how we end up with things like the weak Zip File and early MS-Office encryption. Companies think they can roll their own, or take shortcuts and end up with weak security.

Published algorithms have withstood scrutiny by actual experts, don't assume that your home-grown super-secret encryption will stand up to scrutiny - it may leave patterns in the data that can be exploited to decypt it

Switch to ring learning-with-errors, which was proven by Regev to reduce in the average case to the hardness of some worst case integer lattice problems. Crypto systems built in this way are believed to not be affected by quantum computers and research is proceeding fast as a result. The fact that the NSA is no further ahead than anyone else is reassuring - we know how to build post-quantum crypto systems, the work that remains is largely in the "maturing" phase rather than the "wtf do we do now" phase.

There really isn't any way of knowing. The possibility of a weakness with the elliptic curve cryptography is only suspected, suggested, not proven.

Wrong.

Weaknesses have already been academically shown. Both the fact that it's remarkably slow (for the quality of the produced pseudorandom bitstream) and the fact that it displays backdoor-like properties has been shown elsewhere. Contrast that with DES which, although there were suspicions that the design of its S-boxes might have had ulterior motives (which, again, is a FAIR assumption whenever the design guidelines of cryptographic primitives is not transparent), has never been actually proven to actually contain backdoor-like properties (unlike Dual_EC_DRBG).

And, well... I'm not even taking into account the Snowden leaks that strongly suggest that NSA has been subverting standards and coercing companies to weaken their cryptographic algorithms (like this one by Reuters).

Good 'ol Bruce has said that there is nothing in the Snowden leaks to prove that the actual crypto algorithms have been weakened. As far as anyone knows all that NSA has done is try to spread the use of it, which may be because they think that it is better.

[citation needed] on that one. Besides, "good ol' Bruce" has been, from the start, one of the people that kept warning against the use of Dual_EC_DRBG. Why use a slow and inefficient PRNG that has known biases (and possible number-theoretical backdoors), when you can use something more extensively tested (i dunno... Salsa20 or whatever).

Look, either Dual_EC_DRBG is a decent and secure PRNG, within reasonable parameters of computational complexity, or it's not. If it is, why the fuck is NSA paying security companies to adopt it? If it's that good, it should stand on its own and surely people will naturally adopt it (similarly to what happened with DES).

The fact that NSA has paid RSA to give priority to this PRNG is HIGHLY suspect, to put it mildly.

In a way this is no different than the fixes they made to make DES proof against differential cryptanalysis. Everyone suspected that NSA had weakened DES when in fact they made it stronger, but it took 15-20 years for people to see that.

Back then, people _suspected_ that DES might contain a backdoor. Today, we _know_ that Dual_EC_DRBG contains backdoor-like properties: it's not simply a suspicion. Do you understand the difference, or do you prefer to keep invoking this flawed comparison?

Since you like talking about DES, shouldn't you also refer how the US gov, back then, artificially forced DES key length to be ridiculously low, to the point where the keyspace could be directly bruteforced? Oh, let's not talk about that small detail...

For all we know the elliptic stuff only looks like it might be weak, but it may be perfectly fine and strong, but it may have been chosen since the form looks weak as a troll against anyone that would try to crack it. Square the circle, you can do it!

Hello? Are you paying attention? Dual_EC_DRBG has been SHOWN (not suspected) to display biases and to be particularly slow for the quality of its output bitstream (AND display backdoor-like properties). It's not optimal or transparent, and it's certainly NOT "fine and strong": it's shit.

A five-year-old could make a better PRNG using any vaguely-decent stream cipher, block cipher in counter mode or cryptographically-secure ha

There really isn't any way of knowing. The possibility of a weakness with the elliptic curve cryptography is only suspected, suggested, not proven.

Wrong.

Weaknesses have already been academically shown. Both the fact that it's remarkably slow (for the quality of the produced pseudorandom bitstream) and the fact that it displays backdoor-like properties has been shown elsewhere. Contrast that with DES which, although there were suspicions that the design of its S-boxes might have had ulterior motives (which, again, is a FAIR assumption whenever the design guidelines of cryptographic primitives is not transparent), has never been actually proven to actually contain backdoor-like properties (unlike Dual_EC_DRBG).

And, well... I'm not even taking into account the Snowden leaks that strongly suggest that NSA has been subverting standards and coercing companies to weaken their cryptographic algorithms (like this one by Reuters).

Good 'ol Bruce has said that there is nothing in the Snowden leaks to prove that the actual crypto algorithms have been weakened. As far as anyone knows all that NSA has done is try to spread the use of it, which may be because they think that it is better.

[citation needed] on that one. Besides, "good ol' Bruce" has been, from the start, one of the people that kept warning against the use of Dual_EC_DRBG. Why use a slow and inefficient PRNG that has known biases (and possible number-theoretical backdoors), when you can use something more extensively tested (i dunno... Salsa20 or whatever).

Look, either Dual_EC_DRBG is a decent and secure PRNG, within reasonable parameters of computational complexity, or it's not. If it is, why the fuck is NSA paying security companies to adopt it? If it's that good, it should stand on its own and surely people will naturally adopt it (similarly to what happened with DES).

The fact that NSA has paid RSA to give priority to this PRNG is HIGHLY suspect, to put it mildly.

In a way this is no different than the fixes they made to make DES proof against differential cryptanalysis. Everyone suspected that NSA had weakened DES when in fact they made it stronger, but it took 15-20 years for people to see that.

Back then, people _suspected_ that DES might contain a backdoor. Today, we _know_ that Dual_EC_DRBG contains backdoor-like properties: it's not simply a suspicion. Do you understand the difference, or do you prefer to keep invoking this flawed comparison?

Since you like talking about DES, shouldn't you also refer how the US gov, back then, artificially forced DES key length to be ridiculously low, to the point where the keyspace could be directly bruteforced? Oh, let's not talk about that small detail...

For all we know the elliptic stuff only looks like it might be weak, but it may be perfectly fine and strong, but it may have been chosen since the form looks weak as a troll against anyone that would try to crack it. Square the circle, you can do it!

Hello? Are you paying attention? Dual_EC_DRBG has been SHOWN (not suspected) to display biases and to be particularly slow for the quality of its output bitstream (AND display backdoor-like properties). It's not optimal or transparent, and it's certainly NOT "fine and strong": it's shit.

A five-year-old could make a better PRNG using any vaguely-decent stream cipher, block cipher in counter mode or cryptographically-secure ha

spurious char ruined the link

Precisely...NIST is saying that out of 4 levels of security (224, 256, 384, 512), they are going to drop the 224 and 384 as they don't offer enough benefit for the added complexity. They are keeping the strongest option (512). The briefer was just stating that this is equivalent to 256 bits of security. Think the hash-equivalent of AES 256.

You mix up n with c, where n is the output (digest) length and c is the internal parameter "capacity". You can tell from http://keccak.noekeon.org/NoteOnKeccakParametersAndUsage.pdf section 3 that the capacity specifies the security (read preimage complexity) of the algorithm.

In fact the idea to cripple Keccak came from its creators. In their original submission they used for (n,c) the values (224, 448), (256, 512), (384, 768) or (512, 1024). In their Sakura (section 6.2) proposal they had lowered c to allow only values of 256 and 512 (Why there is no n in the second proposal: In this proposal they treated Keccak as a sponge function, where the output n may be any length (you get a PRNG and masking for free)).
In the CHES presentation, Slide 45 already uses crippled capacities.
You can read in slide 49 that NIST overtook Sakura's padding scheme.

I have to admit I didn't know much about the controversy so I went and found some articles.

Here is an article showing some weaknesses in Linux's random generation: Analysis of the Linux Random Number Generator

As reported by Bruce Schneier for this Wired article: http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115