This is not going to be implemented and for a good reason.
For starters, this requires creating per-line hashes for every single file of every single version of every single plugin. I say per line because a file can be uploaded with different line endings if you use FTP on Windows (or you're using Git to work on your site on Windows).
Then you have to ship all these hashes with Admin Tools. We're talking about several Gigabytes. This is impractical. It's also daft because if your site gets hacked the attacker can very easily modify a couple of hashes that affect him and you'll never notice because they are lost in a sea of hashes which needs to be updated dozens of times per day.
In practical terms this means that the scanner needs to be a service, not software running on your site. The whole point of Admin Tools is that it's not a service. If you want a service there are plenty, they have funding, we can't compete with them. I know that myJoomla.com is about to go into WordPress and they have a more robust platform than WordFence. I know what they do, I know what it'd take to compete with them, I know it'd make no sense for us to do that. Cool features are not very cool when they require a capital expense twice as much as the company's assets and carry an 80% risk of failure. It's a bet I am not willing to take.
Even if that was not a problem, we'd have two major problems. One, "vetted" files are actually not safe. We assume they are safe because they are on the WordPress Plugin Directory. As we already know, the Directory does not proactively stop malware. So we'd just be lulling you into a fake sense of security. Manually vetting every file requires several thousand human developers on staff which is, of course, impractical. In my opinion this fake sense of security alone is the show stopper for this feature. Telling you a file is safe when it's definitely not just because someone uploaded it in an unvetted repository is insane.
The second major problem is that this approach only covers free of charge plugins on the directory. What about premium versions and plugins not on the directory? Trying to trawl the web and purchase them just to include them in an index is a massively complicated and expensive operation. In fact, it would not be practical at all. We did the same analysis with Joomla! where at lest discovery was much easier as over 90% of the extensions, free or paid, were listed on the Joomla! Extensions Directory. WordPress doesn't even have that.
So how do scanning services provide defaults for safe files? Well, it's a popularity contest. If the same file is present with the same size and content hashes in the same location of many sites and passes an automatic inspection (or a manual inspection, in case it seems fishy) it is marked as safe automatically. That still has the same problem with underhanded popular extensions bought out and backdoored by sneaky attackers. Some will be caught, some will not. It's better than nothing but I'm not convinced it's a safe approach I'd like to follow on my site.
Also, this is missing the point. We have written a PHP file change scanner. The whole point is answering the question "have my files changed without me expecting it to happen". If the answer is "yes", you are hacked. If the answer is "no" we do a secondary analysis of code patterns to draw your attention towards files which might be problematic. That secondary analysis only makes sense either on an existing site OR to have a human developer identify the interesting files in a new and untested plugin which you don't necessarily trust.
Finally, regarding diff, there is an option to show only the changes in DIFF format. I wrote that about five years ago. I believe we have ported it to the WordPress version as well. It's usually good enough for a quick scan but most people don't understand it. It also requires basically storing every .php file in the database. That's why it's disabled by default.
Nicholas K. Dionysopoulos
Lead Developer and Director