ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Main Area and Open Discussion > General Software Discussion

This week's episode of the suicide of Microsoft: Helping gov't exploit your pc

(1/2) > >>

From an article today:

Microsoft Corp. (MSFT), the world’s largest software company, provides intelligence agencies with information about bugs in its popular software before it publicly releases a fix, according to two people familiar with the process. That information can be used to protect government computers and to access the computers of terrorists or military foes.

Redmond, Washington-based Microsoft (MSFT) and other software or Internet security companies have been aware that this type of early alert allowed the U.S. to exploit vulnerabilities in software sold to foreign governments, according to two U.S. officials.

--- End quote ---

Maybe start with this summary on TechDirt:

from TechDirt

Why the surprise?

Remember the Windows 95 era in which Microsoft was facing a billion dollar fine becuase of its antitrust practices?
Remember how the 1 billon was forgiven? How many times have government forgiven you any fine?

Some kind of deal was made. Given the current information. I suspect that it was adding backdoors to Windows. So that governments can spy on their general population.

More good advertising for Linux etc.

More good advertising for Linux etc.
-tomos (July 05, 2013, 03:47 AM)
--- End quote ---

If so it's only hastening the day when Ballmer makes good on his threats to haul Linux into court for allegedly violating "hundreds" of Microsoft's patents.



"On data storage and applications going cloud (Surfulater, Mindjet et al.)
« on: January 13, 2013, 06:35:34 AM »":

first post there, by "helmut85":

"2. On the other hand, there's cloud-as-storage-repository, for individuals as for corporations. Now this is not my personal assertion, but common sense here in Europe, i.e. the (mainstream) press here regularly publishes articles convening about the U.S. NSA (Edit: here and afterwards, it's NSA and not NAS, of course) having their regular (and by U.S. law, legal) look into any cloud material stored anywhere in the cloud on U.S. servers, hence the press's warning European corporations should at least choose European servers for their data - whilst of course most such offerings come from the U.S. (Edit: And yes, you could consider developers of cloud sw and / or storage as sort of a Fifth Column, i.e. people that get us to give away our data, into the hands of the enemy, who should be the common enemy.)

3. Then there is encryption, of course (cf. 4), but the experts / journalists convene that most encryption does not constitute any prob for the NSA - very high level encryption probably would but is not regularly used for cloud applications, so they assume that most data finally gets to NSA in readable form. There are reports - or is it speculations? - that NSA provides big U.S. companies with data coming from European corporation, in order to help them save cost for development and research. And it seems even corporations that have a look upon rather good encryption of their data-in-files, don't apply these same security standards to their e-mails, so there's finally a lot of data available to the NSA. (Even some days ago, there's been another big article upon this in Der Spiegel, Europe's biggest news magazine, but that wasn't but another one in a long succession of such articles.) (Edit: This time, it's the European Parliament (!) that warns: - of course, it's debatable if anybody then should trust European authorities more, but it's undebatable that U.S. law / juridiction grants patents to the first who comes and brings the money in order to patent almost anything, independently of any previous existence of the - stolen - ideas behind this patent, i.e. even if you can prove you've been using something for years, the patent goes to the idea-stealing corporation that offers the money to the patent office, and henceforward, you'll pay for further use of your own ideas and procedures, cf. Edit of number 1 here - this for the people who might eagerly assume that "who's nothing got to hide shouldn't worry".)

4. It goes without saying that those who say, if you use such cloud services, use at least European servers, get asked what about European secret services then doing similar scraping, perhaps even for non-European countries (meaning, from GB, etc. straight to the U.S., again), for one, and second, in some European countries, it's now ILLEGAL to encrypt data, and this is then a wonderful world for such secret services: Either they get your data in full, or they even criminalize you or the responsible staff in your corporation. (Edit: France's legislation seems to have been somewhat lightened up instead of being further enforced as they had intended by 2011. Cf )"

and, especially, the post by "clean" there (far down in page 1), almost in its entirety, and just for an example:

"Why this is so harmful?


Even with their "patent frenzy" (cf. their allowing for "patents" for things not new at all, but just because you have the necessary money to pay for the "patent" of these processes et al. perhaps known for years; or have a look at U.S. sw "patents" which cause scandal world-wide in the "industry"), the U.S. do invent less and less, and with every year, this become more apparent. Thus, the U.S. government is highly interested in "providing" their big corporations of "nation interest" with new info about what would be suitable to make some development on (= forking findings of third parties), or simply, about what U.S. corps could simply steal: Whilst a European corp is in the final stages of preparing patents, those are then introduced by their U.S. competitors just days before the real inventors will do it.


It's not only the Europeans who are harmed: Whilst the Japanese ain't not as strong anymore as they had once been, it's the Chinese who steal less and less from others but who invent more and more on their own and who risk to leave trailing the U.S. industry anytime soon."

and there again:


And it's not just inventors, etc., abroad that are at risk: It's perfectly sensible that some innovative, small U.S. companies are spied for the benefit of big U.S. companies, be it for simple stealing their ideas alone, and / or for facilitating their taking over for cheap.


Of course, it's not only and all about inventions, it's also about contracting (Siemens in South Africa? Why not these same contracts be going to General Electric, by using core info? I just made up this example and I'm not insinuating that GE might want or go to "steal" from Siemens, but yes, I'm insinuating that some people might be interested in "helping" them to do so.)"

and there again, some "practical advice" (see below):


So it might be time, about 30 years after Orwell's "1984", to store "old" comps (Win 8 and Office 2003, anyone? har, har!), "old" sw, and to divide your work between comps that are connected to the net, and those that are not, and to transfer data between them with secure USB sticks, in readable, "open" (and not proprietary) data formats (perhaps XML instead of "Word", etc.), in the end."

and then, of course, that now superbly confirmed:


The purpose of this post is to show that I'm not speaking out of paranoia, but that reality (here: brand-new MS Office 2013, probably the biggest impact in sw for the coming years, except for operating systems) outstrips fears by far."

As for the "advice" to shift around data between your regular network and your secured pc's, well, that was a little illogical, but I'm sure what's "clean" wanted to express, was:

Do NOT make available core data "they" might be interested in, on any pc to which they could ever have access, be it by MS "backdoors", or by special secret tools "they" might have loaded into your system for this purpose, AND "clean" wanted to express, whenever you TREAT such data, prefer data formats you are able to look into, in order to check that the data itself has not been infected by a secret sending tool ("Troian horses") or whatever else "they" might have invented or might invent.

We should perhaps add here that the current state of affairs, any of our web usage causing unknown amounts of data being transferred BOTH ways, each time, and with content unknown by us, and our having accepted such state of things, instead of not allowing any such "outbound sending" when we don't know / cannot check the contents, in a "readable" format, is the real cause for the current situation, i.e. we should have fought about this "constant data sending" about 10 years ago: now, the web can never become "safe for us" again. So...

- So, physical distinction between "data they can have access to" and private data (= core knowledge of your corporation, big or small) is primordial today

- There has been an (unfruitful) discussion if these encryption tools have backdoors or not; we should assume they have

- Some smart people prefer "replace tables" or such, which seems to be the "Enigma principle": I'm not an expert in cryptography, but I once wrote a rather lengthy such table, of which the principle was to replace not just "e" with "1a" and such (of course not), but to replace "e" with "1a" if it was on xth position in a line/paragraph, but with "1b" if it was on yth position there, and/or if it was the first "e" there, but with "1c" if it was second, etc. (and you can mix up this "position vs. occurence" principle freely if your table is big enough, and there are also other possible combinations, by counting occurences of other specific characters before, in a subset (line, paragraph, or sets of 100 original characters or whatever) - and then, you could even have different such tables for different subsets, e.g. a table for the first 100 original chars, then a table for the second 830 chars, or whatever, and also, it would be possible to have BEGIN the following subset / table according to the CONTENT of the first subset: e.g. first table for the first 100 original chars, and then for as long as they ain't 100 original "e" in that subset BUT go to table 2 immediately IF (even without 100 original "e") there are more than 67 original "a" - or whatever: endless possibilities here, and I suppose any brute force will be totally ineffective; Enigma's concept was much simpler than mine, I suppose, so...)


No, it wasn't, a short look into the respective wikipedia article taught me so, Enigma was pure genius, even by today's standards, so considering its time... (and they got hold of it by other means, not by breaking the code it produced...)

So I'm intrigued by the question how to COMBINE "keys" with tables, and, of course, the question: Why does it SEEM to be impossible, even for the developer of encryption software, to decrypt data which was encrypted with his own program? Why that missing backdoor today, as they want to make us believe? As soon as you can decompile a program, or have the source code to begin with, why not de-compile all these algorithm-triggered processes, table-assignments, etc., too? It seems that today's "keys" trigger rather basic processes? But then, as soon as those tables are within the algorithm, you just need the algorithm's source code, and the tables are worthless, so there should be DIFFERENT keys, one key being some additional "concordance" table (as detailed above, in all its complications) for another key, but this logically means, as soon as "they" don't have your key, and it's sufficiently long and complicated, your key could very well combine the "key" part AND such "table" parts... which means, "keys" and "tables" are NOT conceptionally different (as they are presented on some web sites), but are the same thing, it's all just about two things:

- the processes the right key must then trigger, must be as complicated and time-consuming as possible: here, the Enigma was outstanding, too: Since it was a digitized-but-not-computerized system, application of brute-force was technically impossible

- parts of the ALGORITHM, i.e. of the command structure "what is to be done with the elements within the tables" must remain unknown: just hiding the table is unsufficient if the instructions are all there and available to the decryptor, because then again, they'd brute-force simply all data combinations within that table, which would be high numbers, but not "endless"... but as soon as part of complicated instructions for the same table/key are missing, things become interesting!

- a possible "solution" to this problem could be to have the algorith itself as vague as possible, meaning within your algorithm, there would be hundreds of variables that would then "decide" upon further processing, and which would only be delivered to the algorithm in "real time", BY the intro of that key, which means, the key would not only trigger the "transposition code", for fixed-length bits of the data, but would be a table in itself, deciding in real-time upon the lengths of those data bits, and upon the sub-processes how these are to be processed

- IF you construct encryption software software this way, that would indeed be a perfect means to prevent back-doors: There would not be any possible "de-compilation of what the code DOES" in this scenario

- And this means (I hope), if you write your algorithm yourself and make it sufficiently complicated and vague, i.e. not predetermined by its own construct, but "needing too many exterior data in order to proceed in any sensible way and which is all missing without the key", your key, if sufficiently long, even might be of the kind of "most of this even makes sense", since this brute force approach on the key will then, internally, trigger so much "internal response time" by "over-complicated table comparisons and triggering all sorts of DIFFERENT things for each for possible permutation", that it should be unbreakable as the Enigma would be today, by information technology means, too

- Of course, you could have "two keys", one being the key, and another one being your "table", but it's evident that one key of enough length could contain "key" and additional tables, there is no conceptual difference between them, you only have to look after utmost complication of the KEY-WISE processing instructions, whilst the algorithm-wise processing instructions will be "in their hands"

- So, the result of my additional musing here is (and I suppose encryption experts will have known all this for ages, but it's so sweet to re-invent the wheel, so much more satisfying than doing cross-words), do not only check encryption software source code for backdoors, but also for level of complication, of pre-determinedness of processing the key = all those keys their bruto-force will try: if the algorithm is rather simple, brute-forcing will be simple, but even if processing is totally aleatoric AND CANNOT BE RE-SIMPLIFIED by them in the process, they should be up for a real task

- In other words, a good key is a real good key whenever its compents, its characters, ain't introduced as a whole into a simple transposition algorithm, but when there they have to read into as many different entry variables, spread all over a complicated, variable-VALUE-wise inter-dependant code structure (missing chars in your code: default values... and even those could be aleatoric-at-the-arrival, depending on existant chars in your code string? I'm not sure here in case they know the algorithm) - it seems to me such a thing is virtually unbreakable


- As we all know, "they" will end up getting your tables, in this scenario, since you need them in your working memory, and you will also have to store them somewhere (but perhaps with some other means of encryption?). What's perhaps of utmost interest here (as long as normal people don't get tortured in our "democratic" nations in order to "give" their commercial secrets):

- What about Windows' hdd storage of the "working memory", AND how to prevent it? And how to be sure to have prevented it? In this scenario, you "just" would have to cut electricity (and allow for some seconds in order for the memory chips to lose their current state of activity, though)

- Also, it occurs to me that perhaps SOME currently available (traditional, non-table but key-based) encryption programs do NOT all have such backdoors, but, thanks to the developments of these last days, any of their future updates will have, so, if you continue to use your current encryption tool, but only in physical circumstances where they can't even update it without your knowledge (!), you MIGHT be relatively safe with YOUR data

- But what about emails?

- And, as in ancient times, what about staff from yours "they" simply and secretely "buy out"? BUT, that's for sure, ancient methods ask for much more effort than all these new electronic harm "they" have done to us these last years, so making "them" have to rely upon human spying, is not actually facilitating "their" task

- So there's plenty of room for TECHNICAL discussion here!

As for spies, if I was Edward, I'd marry Anna, have some beautiful kids with that overly cute and certainly very smart woman, shut my mouth, and be as happy in the residential outskirts of Moscou as it gets...

Since we all see now that humankind (which is myriads of people and their respective governments) simply ain't worth it to be nailed to a cross - and that's all I'll say about the "political implications" of this current affair.

As for technical discussions, why not share our respective knowledge, and our respective hints and ideas?

Yours Truly,

from wikipedia: "In October 2010, Chapman posed on the cover of Russian version of Maxim magazine in Agent Provocateur lingerie." - hasn't this been a truly wonderful idea?


[0] Message Index

[#] Next page

Go to full version