info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Microsoft put NSA backdoor in encryption
138 views
Skip to first unread message
Free Ed Snowden!
Jul 12, 2013, 2:44:12 PM7/12/13
to
Here is an extremely important and disturbing story that the American
media are conveniently ignoring. According to the British newspaper The
Guardian, documents leaked by Ed Snowden reveal that Microsoft has put a
backdoor in its encryption to allow the NSA access what users think are
confidential communications, passwords, etc. This has long been
suspected, but has never been proven until now.
__________________________________________________
http://www.guardian.co.uk/world/2013/jul/11/microsoft-nsa-collaboration-
user-data
11 July 2013
"Microsoft has collaborated closely with US intelligence services to
allow users' communications to be intercepted, including helping the
National Security Agency to circumvent the company's own encryption,
according to top-secret documents obtained by the Guardian."
"The files provided by Edward Snowden illustrate the scale of co-
operation between Silicon Valley and the intelligence agencies over the
last three years."
"Microsoft helped the NSA to circumvent its encryption to address
concerns that the agency would be unable to intercept web chats on the
new Outlook.com portal; The agency already had pre-encryption stage
access to email on Outlook.com, including Hotmail..."
"In July last year, nine months after Microsoft bought Skype, the NSA
boasted that a new capability had tripled the amount of Skype video calls
being collected through Prism; Material collected through Prism is
routinely shared with the FBI and CIA, with one NSA document describing
the program as a 'team sport.'"
[Note: The Chinese government has been overhauling its computer systems
to use open-source Linux, rightfully distrusting Microsoft's proprietary
closed-source software.]
media are conveniently ignoring. According to the British newspaper The
Guardian, documents leaked by Ed Snowden reveal that Microsoft has put a
backdoor in its encryption to allow the NSA access what users think are
confidential communications, passwords, etc. This has long been
suspected, but has never been proven until now.
__________________________________________________
http://www.guardian.co.uk/world/2013/jul/11/microsoft-nsa-collaboration-
user-data
11 July 2013
"Microsoft has collaborated closely with US intelligence services to
allow users' communications to be intercepted, including helping the
National Security Agency to circumvent the company's own encryption,
according to top-secret documents obtained by the Guardian."
"The files provided by Edward Snowden illustrate the scale of co-
operation between Silicon Valley and the intelligence agencies over the
last three years."
"Microsoft helped the NSA to circumvent its encryption to address
concerns that the agency would be unable to intercept web chats on the
new Outlook.com portal; The agency already had pre-encryption stage
access to email on Outlook.com, including Hotmail..."
"In July last year, nine months after Microsoft bought Skype, the NSA
boasted that a new capability had tripled the amount of Skype video calls
being collected through Prism; Material collected through Prism is
routinely shared with the FBI and CIA, with one NSA document describing
the program as a 'team sport.'"
[Note: The Chinese government has been overhauling its computer systems
to use open-source Linux, rightfully distrusting Microsoft's proprietary
closed-source software.]
Matt
Jul 12, 2013, 3:49:39 PM7/12/13
to
Free Ed Snowden! <s...@nsa.gov> wrote in
news:aeKdnVamScLh033M...@earthlink.com:
> Here is an extremely important and disturbing story that the American
> media are conveniently ignoring. According to the British newspaper
> The Guardian, documents leaked by Ed Snowden reveal that Microsoft has
> put a backdoor in its encryption to allow the NSA access what users
> think are confidential communications, passwords, etc. This has long
No, that is not what they did. Read the article, instead of being so
dramatic about it, and you realize they provided the NSA with unencrypted
data before it was sent. Not an especially nice thing to do, but seriously,
if you are sending plain text over the Internet in the form of email, IM
and Usenet, and are worried about someone reading it, you have more serious
issues.
RSA encryption can be beaten, but it takes an awful lot of computing power
dedicated to the process. It is most certainly not something you do for all
messages.
Matt
news:aeKdnVamScLh033M...@earthlink.com:
> Here is an extremely important and disturbing story that the American
> media are conveniently ignoring. According to the British newspaper
> The Guardian, documents leaked by Ed Snowden reveal that Microsoft has
> put a backdoor in its encryption to allow the NSA access what users
> think are confidential communications, passwords, etc. This has long
dramatic about it, and you realize they provided the NSA with unencrypted
data before it was sent. Not an especially nice thing to do, but seriously,
if you are sending plain text over the Internet in the form of email, IM
and Usenet, and are worried about someone reading it, you have more serious
issues.
RSA encryption can be beaten, but it takes an awful lot of computing power
dedicated to the process. It is most certainly not something you do for all
messages.
Matt
Aragorn
Jul 12, 2013, 4:50:02 PM7/12/13
to
[Follow-up rerouted to alt.os.linux.ubuntu because it's the only one of
the listed groups I'm subscribed to, and because we have an undercover
Microsoft astroturfer here - or perhaps I should say: at least one, as I
suspect that there might be two of them.]
On Friday 12 July 2013 21:49, Matt conveyed the following to
alt.os.linux.ubuntu...
> Free Ed Snowden! <s...@nsa.gov> wrote in
> news:aeKdnVamScLh033M...@earthlink.com:
>
>> Here is an extremely important and disturbing story that the American
>> media are conveniently ignoring. According to the British newspaper
>> The Guardian, documents leaked by Ed Snowden reveal that Microsoft
>> has put a backdoor in its encryption to allow the NSA access what
>> users think are confidential communications, passwords, etc. [...]
Note to the OP: Although I support Edward Snowden, as far as I know he
_is still_ a free man. A hunted man, no doubt, but he is still free,
and definitely more free than Julian Assange, who has found shelter in
the Ecuadorian embassy in London, but is unable to leave the embassy
because Scotland Yard has been staking out the embassy ever since it was
known that Assange was hiding there, and if he ever leaves, they will
catch him, hand him over to the Swedes, and the Swedes will then hand
him over to the Americans, and then he'd be spending the rest of his
days in Guantanamo Bay.
> No, that is not what they did. Read the article, instead of being so
> dramatic about it, and you realize they provided the NSA with
> unencrypted data before it was sent. Not an especially nice thing to
> do, but seriously, if you are sending plain text over the Internet in
> the form of email, IM and Usenet, and are worried about someone
> reading it, you have more serious issues.
Yes, but that is not the /complete/ story. The article in question
highlights this particular tidbit, but as was already revealed earlier
on, ...
a. Microsoft did build deliberate backdoors into all NT-based versions
of Microsoft Windows [1] from day one. I don't know whether that
was also the case for the DOS-based versions of Microsoft Windows
[2], but those were easy to crack anyway.
b. Microsoft sells zero-day exploits in Microsoft Windows to the NSA,
and so do so-called computer security companies - e.g. the anti-
virus industry. In fact, the US government is the biggest buyer
of zero-day exploits, and in whatever software, for that matter;
it's not limited to Microsoft Windows, and these days, Android -
which is for most part written in Java, which is itself a security
nightmare - is also a highly favored target for use as a botnet
slave which can be deployed for conducting DDoS attacks.
c. As of Windows XP onward, Microsoft spies on its users, because
Windows phones home every week with a detailed report on (of
course) your Windows installation, your computer's hardware, what
software is installed on your computer - even if it's not Microsoft
software - and possibly your browser history if you use Internet
Explorer. Microsoft has admitted to this and claims that "the
information will not be stored permanently at Microsoft and is only
used so as to allow Microsoft to improve its service to its
customers." However, Microsoft has a history of lying - in fact,
they are not to be trusted, ever - and they most certainly do store
and save that information on their servers somewhere for at least
a certain amount of time, linked to your WAN-side IP address and
your Windows serial number and activation key. As of Windows 7 on,
the user can disable this "feature" via the Windows Configuration
Panel, but this was not possible in Windows XP. A French developer
- the one who discovered this "feature" of Windows - wrote a
freeware tool which the Windows user can download and which will
then deactivate the spying.
d. Microsoft also spies on its Windows Phone users by sending GPS
coordinates of Windows Phone users to Microsoft. Although
undocumented, Microsoft was caught and has in the meantime also
admitted to doing that, but of course with the same old spin that
they are collecting this data "so as to improve their service
towards their customers."
> RSA encryption can be beaten, but it takes an awful lot of computing
> power dedicated to the process. It is most certainly not something you
> do for all messages.
That's why the NSA is building a brand-new and multi-million dollar
supercomputer [3], courtesy of the US American taxpayer - note: I myself
am not a US American. Apparently their current contingent of
supercomputers - they have more than one - wasn't up for the job
anymore.
[1] The NT-based Windows versions are...
- Windows NT 3.1
- Windows NT 3.5 and NT 3.51
- Windows NT 4.0
- Windows NT 5.0 (i.e. Windows 2000)
- Windows NT 5.1 (i.e. Windows XP and Windows 2003 Server)
- Windows NT 6.0 (i.e. Windows Vista and Windows 2008 Server)
- Windows NT 6.1 (i.e. Windows 7)
- Windows NT 6.2 (i.e. Windows 8)
- Windows NT 6.3 (i.e. the upcoming Windows 8.1)
[2] Windows 1.x, Windows 2.x, Windows 386, Windows 3.xx, Windows 95,
Windows 98 and 98 SE, and Windows Millenium Edition were all still
DOS-based.
[3] Which, like their other supercomputers, will of course be running
GNU/Linux.
--
= Aragorn =
GNU/Linux user #223157 - http://www.linuxcounter.net
the listed groups I'm subscribed to, and because we have an undercover
Microsoft astroturfer here - or perhaps I should say: at least one, as I
suspect that there might be two of them.]
On Friday 12 July 2013 21:49, Matt conveyed the following to
alt.os.linux.ubuntu...
> Free Ed Snowden! <s...@nsa.gov> wrote in
> news:aeKdnVamScLh033M...@earthlink.com:
>
>> Here is an extremely important and disturbing story that the American
>> media are conveniently ignoring. According to the British newspaper
>> The Guardian, documents leaked by Ed Snowden reveal that Microsoft
>> has put a backdoor in its encryption to allow the NSA access what
Note to the OP: Although I support Edward Snowden, as far as I know he
_is still_ a free man. A hunted man, no doubt, but he is still free,
and definitely more free than Julian Assange, who has found shelter in
the Ecuadorian embassy in London, but is unable to leave the embassy
because Scotland Yard has been staking out the embassy ever since it was
known that Assange was hiding there, and if he ever leaves, they will
catch him, hand him over to the Swedes, and the Swedes will then hand
him over to the Americans, and then he'd be spending the rest of his
days in Guantanamo Bay.
> No, that is not what they did. Read the article, instead of being so
> dramatic about it, and you realize they provided the NSA with
> unencrypted data before it was sent. Not an especially nice thing to
> do, but seriously, if you are sending plain text over the Internet in
> the form of email, IM and Usenet, and are worried about someone
> reading it, you have more serious issues.
highlights this particular tidbit, but as was already revealed earlier
on, ...
a. Microsoft did build deliberate backdoors into all NT-based versions
of Microsoft Windows [1] from day one. I don't know whether that
was also the case for the DOS-based versions of Microsoft Windows
[2], but those were easy to crack anyway.
b. Microsoft sells zero-day exploits in Microsoft Windows to the NSA,
and so do so-called computer security companies - e.g. the anti-
virus industry. In fact, the US government is the biggest buyer
of zero-day exploits, and in whatever software, for that matter;
it's not limited to Microsoft Windows, and these days, Android -
which is for most part written in Java, which is itself a security
nightmare - is also a highly favored target for use as a botnet
slave which can be deployed for conducting DDoS attacks.
c. As of Windows XP onward, Microsoft spies on its users, because
Windows phones home every week with a detailed report on (of
course) your Windows installation, your computer's hardware, what
software is installed on your computer - even if it's not Microsoft
software - and possibly your browser history if you use Internet
Explorer. Microsoft has admitted to this and claims that "the
information will not be stored permanently at Microsoft and is only
used so as to allow Microsoft to improve its service to its
customers." However, Microsoft has a history of lying - in fact,
they are not to be trusted, ever - and they most certainly do store
and save that information on their servers somewhere for at least
a certain amount of time, linked to your WAN-side IP address and
your Windows serial number and activation key. As of Windows 7 on,
the user can disable this "feature" via the Windows Configuration
Panel, but this was not possible in Windows XP. A French developer
- the one who discovered this "feature" of Windows - wrote a
freeware tool which the Windows user can download and which will
then deactivate the spying.
d. Microsoft also spies on its Windows Phone users by sending GPS
coordinates of Windows Phone users to Microsoft. Although
undocumented, Microsoft was caught and has in the meantime also
admitted to doing that, but of course with the same old spin that
they are collecting this data "so as to improve their service
towards their customers."
> RSA encryption can be beaten, but it takes an awful lot of computing
> power dedicated to the process. It is most certainly not something you
> do for all messages.
supercomputer [3], courtesy of the US American taxpayer - note: I myself
am not a US American. Apparently their current contingent of
supercomputers - they have more than one - wasn't up for the job
anymore.
[1] The NT-based Windows versions are...
- Windows NT 3.1
- Windows NT 3.5 and NT 3.51
- Windows NT 4.0
- Windows NT 5.0 (i.e. Windows 2000)
- Windows NT 5.1 (i.e. Windows XP and Windows 2003 Server)
- Windows NT 6.0 (i.e. Windows Vista and Windows 2008 Server)
- Windows NT 6.1 (i.e. Windows 7)
- Windows NT 6.2 (i.e. Windows 8)
- Windows NT 6.3 (i.e. the upcoming Windows 8.1)
[2] Windows 1.x, Windows 2.x, Windows 386, Windows 3.xx, Windows 95,
Windows 98 and 98 SE, and Windows Millenium Edition were all still
DOS-based.
[3] Which, like their other supercomputers, will of course be running
GNU/Linux.
--
= Aragorn =
GNU/Linux user #223157 - http://www.linuxcounter.net
Dänk 42Ø
Jul 14, 2013, 12:29:55 AM7/14/13
to
On Fri, 12 Jul 2013 19:49:39 +0000, Matt wrote:
> Free Ed Snowden! <s...@nsa.gov> wrote in
> news:aeKdnVamScLh033M...@earthlink.com:
>
>> Here is an extremely important and disturbing story that the American
>> media are conveniently ignoring. According to the British newspaper
>> The Guardian, documents leaked by Ed Snowden reveal that Microsoft has
>> put a backdoor in its encryption to allow the NSA access what users
>> think are confidential communications, passwords, etc. This has long
>
> No, that is not what they did. Read the article, instead of being so
> dramatic about it, and you realize they provided the NSA with
> unencrypted data before it was sent.
Surreptitiously forwarding a user's data to the NSA just before he is
> Free Ed Snowden! <s...@nsa.gov> wrote in
> news:aeKdnVamScLh033M...@earthlink.com:
>
>> Here is an extremely important and disturbing story that the American
>> media are conveniently ignoring. According to the British newspaper
>> The Guardian, documents leaked by Ed Snowden reveal that Microsoft has
>> put a backdoor in its encryption to allow the NSA access what users
>> think are confidential communications, passwords, etc. This has long
>
> No, that is not what they did. Read the article, instead of being so
> dramatic about it, and you realize they provided the NSA with
> unencrypted data before it was sent.
finished encrypting it certainly qualifies as a "back door."
What I find amusing is how liberals are actually DEFENDING Barack Obama
for exceeding the worst abuses of the Nixon AND Bush administrations.
"But Bush did it too!" is no longer an excuse.
Even worse, they are defending Microsoft, a giant global monopolistic
corporation, of the sort they usually condemn for being global and
monopolistic etc. But almost every single goddamn bleating Obamatard is
posting his defense of Chairman Obama (and Microsoft) to the Internet
using the virus that passes for Microsoft's software.
This contradiction keeps in line with their beliefs, though: That by
continuing to purchase corruption -- whether it be Microsoft's or the
Democrat Party's lies -- that one can somehow Change things. You say you
don't like high-fructose corn syrup, yet you continue to buy Coke and
Pepsi laden with the stuff. You say you don't like being spied on, but
you buy software from the company and vote for the political party that
spy on you. What the fuck did you expect?!?
Virus Guy
Jul 14, 2013, 8:52:46 AM7/14/13
to
Aragorn wrote:
>a. Microsoft did build deliberate backdoors into all NT-based versions
> of Microsoft Windows [1] from day one. I don't know whether that
> was also the case for the DOS-based versions of Microsoft Windows
> [2], but those were easy to crack anyway.
Just to correct your perception of win-9x/me as being "DOS-based" - they
>a. Microsoft did build deliberate backdoors into all NT-based versions
> of Microsoft Windows [1] from day one. I don't know whether that
> was also the case for the DOS-based versions of Microsoft Windows
> [2], but those were easy to crack anyway.
are not.
Win-9x/ME are *booted*, loaded or invoked from DOS as it exists
transiently during the boot process, but once invoked, Win-9x/ME runs
from a kernel that puts i86 CPU in protected mode.
Win-9x/me and all NT-based OS (prior to 7) create virtual DOS
environments for any process or application that needs them, but it's a
complete fallacy to say that Win-9x/me is either "DOS-based" or "runs on
top of DOS".
Win-9x/me is a full Win32 operating system, and with the addition of a
third-party API enhancement known as KernelEx, 9x/me can run many
current "NT-only" programs.
Virus Guy
Jul 14, 2013, 9:13:46 AM7/14/13
to
"Free Ed Snowden!" wrote:
> "Microsoft has collaborated closely with US intelligence services to
> allow users' communications to be intercepted, including helping the
> National Security Agency to circumvent the company's own encryption,
> according to top-secret documents obtained by the Guardian."
It was pointed out as long ago as 1999 that a debugging symbol (_NSAKEY)
> "Microsoft has collaborated closely with US intelligence services to
> allow users' communications to be intercepted, including helping the
> National Security Agency to circumvent the company's own encryption,
> according to top-secret documents obtained by the Guardian."
existed in ADVAPI32.DLL (security
and encryption driver) when it released Service Pack 5 for Windows NT
4.0.
"Microsoft's operating systems require all cryptography suites that
work with its operating systems to have a digital signature. Since
only Microsoft-approved cryptography suites can be installed or
used as a component of Windows it is possible to keep export copies
of this operating system (and products with Windows installed) in
compliance with the Export Administration Regulations (EAR), which
are enforced by the US Department of Commerce Bureau of Industry
and Security (BIS).
It was already known that Microsoft used two keys, a primary and a
spare, either of which can create valid signatures."
(the above from http://en.wikipedia.org/wiki/NSAKEY)
It's not clear to me how the presence of a second public key within
ADVAPI32.DLL (regardless who owns the private key) could constitute a
"back door" to a windows system.
It's not clear how data being handled by ADVAPI32.dll can leave a
windows computer and be signed by a specific key (or any key other than
Microsoft's primary key) without some sort of back-channel communication
with ADVAPI32.dll, and without the wider software community becoming
aware of this at some point over the past 15 years.
It seems to me that the only way (technically) that this NSAkey could be
used (by the NSA) is if they are able to intercept the data stream from
a target PC and insert their own system between the target and the
destination, and thus they can act as a "man in the middle" and handle
encrypted traffic between the target and the destination without either
of them knowing there is a system between them decrypting and then
re-encrypting the data stream.
To do that, the NSA would either (a) need to know Microsoft's private
key, or (b) have their own key embedded inside ADVAPI32.DLL (which they
seem to have). But how does ADVAPI32.dll know which key to use at any
given time? Both keys can't be used simultaneously - can they? If they
could, then theoretically an encrypted data stream could be decoded by
either key, but again the wider software community would have noticed
that.
Virus Guy
Jul 14, 2013, 12:05:56 PM7/14/13
to
Ernst Oberhammer wrote:
> Does not matter. What file/code you say does run directly 32b
> without DOS intervention? None.
DOS can't run 32-bit code. So right off the bat, your insistence that
DOS is some sort of necessary component of Win-9x/me is complete
bullshit.
I dare you to explain how a 32-bit protected mode kernel (that win-9x/me
has) can possibly run "on top of" or even concurrent with a 16-bit
real-mode DOS executive.
> You start Win from DOS and not the opposite.
And DOS is wiped from the system RAM when the 9x kernel is started.
Why are so stuck on how the win-9x/me kernel is loaded and then invoked?
Once invoked, win-9x/me is a fully 32-bit OS that puts the CPU in
protected mode. The fact that I can interrupt the process or stop the
boot and keep the system in 16-bit real-mode DOS is irrelavent.
> A Command Line / DOS-prompt run any DOS- program you may find
> appropriate. Is NOT a feature.
Any command line / dos prompt I open under win-9x is a virtual DOS
machine.
> It is a construction UPON. You see that in programming. You may
> allocate pointers anywhere anytime.
You confuse the fact that under 9x/me, that 16-bit DOS code has full
access to the BIOS and hardware, so you assume that the native 32-bit
win-9x drivers must somehow also use 16-bit code to perform their
function. Win-9x will thunk down and use 16-bit DOS drivers that
existed as part of the boot-configuration prior to the windows kernel
being loaded, but that was done for legacy reasons as people
transitioned existing systems from DOS/Win3.x to Win-9x. As hardware
vendors came out with 32-bit drivers, the use of legacy DOS-mode drivers
became non-existant.
The kernel of the NT line prevents direct hardware access, so it can't
use 16-bit DOS drivers if no 32-bit drivers are available. This is why
Win-2k wasn't adopted early by game enthusiasts, because 32-bit
sound-card drivers took a while to become available.
> Does not matter. What file/code you say does run directly 32b
> without DOS intervention? None.
DOS can't run 32-bit code. So right off the bat, your insistence that
DOS is some sort of necessary component of Win-9x/me is complete
bullshit.
I dare you to explain how a 32-bit protected mode kernel (that win-9x/me
has) can possibly run "on top of" or even concurrent with a 16-bit
real-mode DOS executive.
> You start Win from DOS and not the opposite.
And DOS is wiped from the system RAM when the 9x kernel is started.
Why are so stuck on how the win-9x/me kernel is loaded and then invoked?
Once invoked, win-9x/me is a fully 32-bit OS that puts the CPU in
protected mode. The fact that I can interrupt the process or stop the
boot and keep the system in 16-bit real-mode DOS is irrelavent.
> A Command Line / DOS-prompt run any DOS- program you may find
> appropriate. Is NOT a feature.
Any command line / dos prompt I open under win-9x is a virtual DOS
machine.
> It is a construction UPON. You see that in programming. You may
> allocate pointers anywhere anytime.
You confuse the fact that under 9x/me, that 16-bit DOS code has full
access to the BIOS and hardware, so you assume that the native 32-bit
win-9x drivers must somehow also use 16-bit code to perform their
function. Win-9x will thunk down and use 16-bit DOS drivers that
existed as part of the boot-configuration prior to the windows kernel
being loaded, but that was done for legacy reasons as people
transitioned existing systems from DOS/Win3.x to Win-9x. As hardware
vendors came out with 32-bit drivers, the use of legacy DOS-mode drivers
became non-existant.
The kernel of the NT line prevents direct hardware access, so it can't
use 16-bit DOS drivers if no 32-bit drivers are available. This is why
Win-2k wasn't adopted early by game enthusiasts, because 32-bit
sound-card drivers took a while to become available.
Aragorn
Jul 14, 2013, 1:40:54 PM7/14/13
to
On Sunday 14 July 2013 14:52, Virus Guy conveyed the following to
alt.os.linux.ubuntu...
> Aragorn wrote:
>
>> a. Microsoft did build deliberate backdoors into all NT-based
>> versions of Microsoft Windows [1] from day one. I don't know
>> whether that was also the case for the DOS-based versions of
>> Microsoft Windows [2], but those were easy to crack anyway.
>
> Just to correct your perception of win-9x/me as being "DOS-based" -
> they are not.
Uhh, I'm afraid they are, and very much so. I will explain below.
> Win-9x/ME are *booted*, loaded or invoked from DOS as it exists
> transiently during the boot process, but once invoked, Win-9x/ME runs
> from a kernel that puts i86 CPU in protected mode.
No, DOS does not exist "transiently during the boot process" in Windows
9x/ME. There is indeed a so-called Win-kernel, and the Win-kernel runs
in protected mode, that much is true. However, that Win-kernel is only
a _DPMI-based DOS extender_ with the addition of a task scheduler -
cooperative in Windows versions before 95, and (mainly) preemptive from
Win95 on.
The protected mode component of Win 3.x, 9x and ME also only uses ring
0, so there is no privilege separation between kernel processes and
userspace processes. There is only a single address space, and any
misbehaving process can grab hold of another process's memory, including
that of the system itself, plus that even so-called userspace processes
have full control of the processor, since they run in ring 0, which is
the kernel ring.
Furthermore, some 60% (at best) of all CPU time on a running Win
3.x/9x/ME system was spent in _real mode_ because although Win 9x/ME
(and Win 3.1/3.11, but not Win 3.0) offered direct 32-bit access for _a
limited subset of_ the I/O operations (such as filesystem access and
swapping), _all of its other_ I/O operations were still happening via
DOS-style real mode access and legacy BIOS calls. There was no
protected mode abstraction layer for the underlying hardware, and the
virtual device drivers (.vxd?) were all hooks into the underlying DOS
and its interface with the legacy BIOS.
Now, the NT-based Windows versions also do have virtual device drivers
for backward compatibility, but they work similar to how Wine works in
UNIX, i.e. by /translating/ the DOS-specific I/O requests into NT-
compatible I/O requests. NT doesn't use real mode and provides for a
complete abstraction layer of the hardware, similar to how other modern
operating systems do that. (The Windows NT kernel was modeled after VMS
and the Windows NT win32/win64 subsystem was largely based upon
Microsoft's contributions to OS/2, which is also a fully protected mode
operating system.) But this was definitely not the case in Windows 3.x,
Windows 9x and Windows ME.
> Win-9x/me and all NT-based OS (prior to 7) create virtual DOS
> environments for any process or application that needs them, but it's
> a complete fallacy to say that Win-9x/me is either "DOS-based" or
> "runs on top of DOS".
Windows NT creates a virtual DOS environment by using the V86 ("virtual
8086") mode of the IA32 processor architecture and by loading a DOS-
compatible command interpreter and DOS-compatible I/O abstraction layer
into the V86 session - which then essentially becomes a virtual machine
- but Win 9x/ME did not actually do it that way.
In Windows 386, 3.0, 3.1/3.11, 95, 98, 98 SE and ME, the DOS sessions
would also run in a V86 session (and could thus be multi-tasked), but
instead of loading a DOS-compatible command interpreter, it simply
loaded a copy of the underlying DOS into the V86 session. Windows 95
also offered the ability of actually switching to real mode for the
execution of DOS programs - in which case it would be like in Windows
3.x on an i286 processor, or even a "DOS box" session in the 16-bit
versions of OS/2, with all protected mode code being halted until the
real mode session had ended - but this was abandoned from Windows 98
onward because it made the system too unstable. Misbehaving software
could, while the processor was in real mode, hang the entire system,
because real mode offers full unmitigated access to all of the
processor's registers and to the BIOS, and with a 1:1 mapping of the
RAM.
You mention "prior to Windows 7" in the above paragraph of yours, and I
do not know whether Windows 7 has dropped DOS support altogether (even
in its 32-bit versions), but what I do know is that all 64-bit versions
of the NT-based Windows releases - and this included the experimental
64-bit XP release and the 64-bit release of Vista - do not support DOS
anymore - or at least, not without any third-party add-ons - because
when the x86-64 processor is in long mode (i.e. 64-bit mode), it no
longer features a V86 submode, which means that in order to offer DOS
and real mode compatibility, a real mode processor must be emulated in
software, which is slow. x86-64 does /have/ a V86 submode, but it is
only accessible from within its "32-bit legacy mode", i.e. when it is
running a 32-bit operating system natively - see the footnote [*].
Rationale: x86-64 has two 32-bit modes: legacy mode - which is
essentially IA32-compatibility mode - and the 32-bit compatibility mode
of long mode. When the processor is running a 64-bit operating system,
then it can still run 32-bit code and even 16-bit protected mode code,
but not real mode code. Real mode emulators for x86-64 long mode do
exist, but they perform a complete emulation in software of an IA32
processor in real mode. In UNIX systems, the 64-bit version of dosemu
does this as well, while the 32-bit version just uses the underlying
processor's V86 mode.
> Win-9x/me is a full Win32 operating system, [...
I'm afraid not. It's a DPMI-based DOS extender with a tasker scheduler
added on.
Here you can read how DPMI works...:
http://en.wikipedia.org/wiki/DPMI
> ...] and with the addition of a third-party API enhancement known as
to make use of ring 3 for NT-based userspace applications, but as such,
it wasn't part of the Win 9x/ME kernel natively.
Similarly, Cygwin offers a complete UNIX/POSIX-like subsystem for the
NT-based Windows versions - including GNU Bash and the X.Org display
server - but that doesn't mean that NT itself would be POSIX-compliant
or even POSIX-compatible, let alone that anyone could possibly suspect
NT to be a UNIX. And another similarity was the NT kernel hack called
WinFrame, written by Citrix Systems, which allowed for NT to become a
genuine multi-user operating system - in the sense of being multi-seat-
capable - and which was later on sold by Citrix to Microsoft, and then
re-marketed by Microsoft as Windows Terminal Server.
The bottom line is that these are bolted-on subsystems, and that they're
not part of the base kernel design. KernelEx was not part of Win 9x/ME,
and neither Cygwin nor the Citrix-developed Terminal Server add-on are
part of the NT kernel. (As of NT 6.0 (Windows Vista and 2008 Server)
on, Microsoft does offer its own Services For Unix subsystem which is
similar to Cygwin, but which - at least, to my knowledge - does not
include a complete and ready-to-use POSIX-like environment. As far as I
know, it's still only a compatibility layer without any userland
software - similar to Wine on UNIX - and a 32-bit/64-bit evolution of
the formerly 16-bit-only POSIX subsystem - think "Microsoft Xenix" - in
NT 3.x and NT 4.0, which was dropped as standard issue from NT 5.x
(Windows 2000, Windows XP and Windows 2003 Server) on.)
[*] x86-64 operation modes:
° Legacy mode
- 16-bit real mode
- 16-bit protected mode, segmented memory model
- 32-bit protected mode, flat memory model
- 32-bit protected mode with PAE pagetables
- V86 mode (16-bit real mode emulation from within 32-bit
protected mode)
° Long mode
* Compatibility mode
- supports 16-bit protected mode code
- 32-bit protected mode with PAE
° Native 64-bit mode
° Systems Management Mode: This is a special 16-bit mode which
was introduced on the i386SL and which uses a feature called
"unreal mode". In this mode, the pagetables are set up, but
the processor then switches back to real mode without a reset,
so that the pagetables remain active. This allows for 16-bit
real mode code to access the complete RAM capacity. Systems
Management Mode is triggered by the hardware, and while the
processor is in Systems Management Mode, all execution of the
operating system and its processes is temporarily halted. It
is mainly used for switching between power savings modes and
for switching fans on and off. The operating system itself
cannot trigger Systems Management Mode, but it will define a
timeout within which SMM must do whatever it was called to do.
alt.os.linux.ubuntu...
> Aragorn wrote:
>
>> a. Microsoft did build deliberate backdoors into all NT-based
>> versions of Microsoft Windows [1] from day one. I don't know
>> whether that was also the case for the DOS-based versions of
>> Microsoft Windows [2], but those were easy to crack anyway.
>
> Just to correct your perception of win-9x/me as being "DOS-based" -
> they are not.
> Win-9x/ME are *booted*, loaded or invoked from DOS as it exists
> transiently during the boot process, but once invoked, Win-9x/ME runs
> from a kernel that puts i86 CPU in protected mode.
9x/ME. There is indeed a so-called Win-kernel, and the Win-kernel runs
in protected mode, that much is true. However, that Win-kernel is only
a _DPMI-based DOS extender_ with the addition of a task scheduler -
cooperative in Windows versions before 95, and (mainly) preemptive from
Win95 on.
The protected mode component of Win 3.x, 9x and ME also only uses ring
0, so there is no privilege separation between kernel processes and
userspace processes. There is only a single address space, and any
misbehaving process can grab hold of another process's memory, including
that of the system itself, plus that even so-called userspace processes
have full control of the processor, since they run in ring 0, which is
the kernel ring.
Furthermore, some 60% (at best) of all CPU time on a running Win
3.x/9x/ME system was spent in _real mode_ because although Win 9x/ME
(and Win 3.1/3.11, but not Win 3.0) offered direct 32-bit access for _a
limited subset of_ the I/O operations (such as filesystem access and
swapping), _all of its other_ I/O operations were still happening via
DOS-style real mode access and legacy BIOS calls. There was no
protected mode abstraction layer for the underlying hardware, and the
virtual device drivers (.vxd?) were all hooks into the underlying DOS
and its interface with the legacy BIOS.
Now, the NT-based Windows versions also do have virtual device drivers
for backward compatibility, but they work similar to how Wine works in
UNIX, i.e. by /translating/ the DOS-specific I/O requests into NT-
compatible I/O requests. NT doesn't use real mode and provides for a
complete abstraction layer of the hardware, similar to how other modern
operating systems do that. (The Windows NT kernel was modeled after VMS
and the Windows NT win32/win64 subsystem was largely based upon
Microsoft's contributions to OS/2, which is also a fully protected mode
operating system.) But this was definitely not the case in Windows 3.x,
Windows 9x and Windows ME.
> Win-9x/me and all NT-based OS (prior to 7) create virtual DOS
> environments for any process or application that needs them, but it's
> a complete fallacy to say that Win-9x/me is either "DOS-based" or
> "runs on top of DOS".
8086") mode of the IA32 processor architecture and by loading a DOS-
compatible command interpreter and DOS-compatible I/O abstraction layer
into the V86 session - which then essentially becomes a virtual machine
- but Win 9x/ME did not actually do it that way.
In Windows 386, 3.0, 3.1/3.11, 95, 98, 98 SE and ME, the DOS sessions
would also run in a V86 session (and could thus be multi-tasked), but
instead of loading a DOS-compatible command interpreter, it simply
loaded a copy of the underlying DOS into the V86 session. Windows 95
also offered the ability of actually switching to real mode for the
execution of DOS programs - in which case it would be like in Windows
3.x on an i286 processor, or even a "DOS box" session in the 16-bit
versions of OS/2, with all protected mode code being halted until the
real mode session had ended - but this was abandoned from Windows 98
onward because it made the system too unstable. Misbehaving software
could, while the processor was in real mode, hang the entire system,
because real mode offers full unmitigated access to all of the
processor's registers and to the BIOS, and with a 1:1 mapping of the
RAM.
You mention "prior to Windows 7" in the above paragraph of yours, and I
do not know whether Windows 7 has dropped DOS support altogether (even
in its 32-bit versions), but what I do know is that all 64-bit versions
of the NT-based Windows releases - and this included the experimental
64-bit XP release and the 64-bit release of Vista - do not support DOS
anymore - or at least, not without any third-party add-ons - because
when the x86-64 processor is in long mode (i.e. 64-bit mode), it no
longer features a V86 submode, which means that in order to offer DOS
and real mode compatibility, a real mode processor must be emulated in
software, which is slow. x86-64 does /have/ a V86 submode, but it is
only accessible from within its "32-bit legacy mode", i.e. when it is
running a 32-bit operating system natively - see the footnote [*].
Rationale: x86-64 has two 32-bit modes: legacy mode - which is
essentially IA32-compatibility mode - and the 32-bit compatibility mode
of long mode. When the processor is running a 64-bit operating system,
then it can still run 32-bit code and even 16-bit protected mode code,
but not real mode code. Real mode emulators for x86-64 long mode do
exist, but they perform a complete emulation in software of an IA32
processor in real mode. In UNIX systems, the 64-bit version of dosemu
does this as well, while the 32-bit version just uses the underlying
processor's V86 mode.
> Win-9x/me is a full Win32 operating system, [...
I'm afraid not. It's a DPMI-based DOS extender with a tasker scheduler
added on.
Here you can read how DPMI works...:
http://en.wikipedia.org/wiki/DPMI
> ...] and with the addition of a third-party API enhancement known as
> KernelEx, 9x/me can run many current "NT-only" programs.
KernelEx was indeed a third-party add-on which provided for the ability
to make use of ring 3 for NT-based userspace applications, but as such,
it wasn't part of the Win 9x/ME kernel natively.
Similarly, Cygwin offers a complete UNIX/POSIX-like subsystem for the
NT-based Windows versions - including GNU Bash and the X.Org display
server - but that doesn't mean that NT itself would be POSIX-compliant
or even POSIX-compatible, let alone that anyone could possibly suspect
NT to be a UNIX. And another similarity was the NT kernel hack called
WinFrame, written by Citrix Systems, which allowed for NT to become a
genuine multi-user operating system - in the sense of being multi-seat-
capable - and which was later on sold by Citrix to Microsoft, and then
re-marketed by Microsoft as Windows Terminal Server.
The bottom line is that these are bolted-on subsystems, and that they're
not part of the base kernel design. KernelEx was not part of Win 9x/ME,
and neither Cygwin nor the Citrix-developed Terminal Server add-on are
part of the NT kernel. (As of NT 6.0 (Windows Vista and 2008 Server)
on, Microsoft does offer its own Services For Unix subsystem which is
similar to Cygwin, but which - at least, to my knowledge - does not
include a complete and ready-to-use POSIX-like environment. As far as I
know, it's still only a compatibility layer without any userland
software - similar to Wine on UNIX - and a 32-bit/64-bit evolution of
the formerly 16-bit-only POSIX subsystem - think "Microsoft Xenix" - in
NT 3.x and NT 4.0, which was dropped as standard issue from NT 5.x
(Windows 2000, Windows XP and Windows 2003 Server) on.)
[*] x86-64 operation modes:
° Legacy mode
- 16-bit real mode
- 16-bit protected mode, segmented memory model
- 32-bit protected mode, flat memory model
- 32-bit protected mode with PAE pagetables
- V86 mode (16-bit real mode emulation from within 32-bit
protected mode)
° Long mode
* Compatibility mode
- supports 16-bit protected mode code
- 32-bit protected mode with PAE
° Native 64-bit mode
° Systems Management Mode: This is a special 16-bit mode which
was introduced on the i386SL and which uses a feature called
"unreal mode". In this mode, the pagetables are set up, but
the processor then switches back to real mode without a reset,
so that the pagetables remain active. This allows for 16-bit
real mode code to access the complete RAM capacity. Systems
Management Mode is triggered by the hardware, and while the
processor is in Systems Management Mode, all execution of the
operating system and its processes is temporarily halted. It
is mainly used for switching between power savings modes and
for switching fans on and off. The operating system itself
cannot trigger Systems Management Mode, but it will define a
timeout within which SMM must do whatever it was called to do.
Aragorn
Jul 14, 2013, 2:18:04 PM7/14/13
to
On Sunday 14 July 2013 18:05, Virus Guy conveyed the following to
alt.os.linux.ubuntu...
> Ernst Oberhammer wrote:
>
>> Does not matter. What file/code you say does run directly 32b
>> without DOS intervention? None.
>
> DOS can't run 32-bit code.
Not natively, but by way of a DPMI extender, yes, it can. (See my other
reply to you.)
> So right off the bat, your insistence that DOS is some sort of
> necessary component of Win-9x/me is complete bullshit.
No, I'm afraid that it is you who is mistaken.
> I dare you to explain how a 32-bit protected mode kernel (that
> win-9x/me has) can possibly run "on top of" or even concurrent with a
> 16-bit real-mode DOS executive.
Once again I refer to my other reply to you.
>> You start Win from DOS and not the opposite.
>
> And DOS is wiped from the system RAM when the 9x kernel is started.
No, I'm afraid you are confusing Windows 9x with the older versions of
Novell Netware, where DOS was only used as the bootloader for Netware
and could then, depending on what the administrator wanted, either be
wiped from the RAM to make room for caching, or kept in RAM to be used
as a DOS virtual machine so that the Netware server could double as a
workstation.
> Why are so stuck on how the win-9x/me kernel is loaded and then
> invoked?
Because _he_ is right, and _you_ are wrong.
> Once invoked, win-9x/me is a fully 32-bit OS that puts the CPU in
> protected mode.
It is most certainly not a _fully_ 32-bit operating system, and its
protected mode is only an extender to DOS. Again, see my other reply to
you, and the Wikipedia link contained therein about the DPMI interface.
DPMI was quite popular among pure DOS applications even outside of
Windows. Think dBASE or AutoCAD, for instance.
> The fact that I can interrupt the process or stop the boot and keep
> the system in 16-bit real-mode DOS is irrelavent.
That in itself is, yes. But that's not what he meant.
>> A Command Line / DOS-prompt run any DOS- program you may find
>> appropriate. Is NOT a feature.
>
> Any command line / dos prompt I open under win-9x is a virtual DOS
> machine.
Yes and no. From the hardware's point of view, it would be a virtual
machine because it is executed in V86, which is a hardware real mode
emulation from within 32-bit protected mode - albeit that Windows _95_
did also allow for the execution of DOS code in real mode, which was
dropped from Windows 98; see my other reply to you - but the operating
system loaded inside the DOS virtual machine was in essence only a
slimmed-down copy of the underlying DOS of Win 9x/ME.
>> It is a construction UPON. You see that in programming. You may
>> allocate pointers anywhere anytime.
>
> You confuse the fact that under 9x/me, that 16-bit DOS code has full
> access to the BIOS and hardware, so you assume that the native 32-bit
> win-9x drivers must somehow also use 16-bit code to perform their
> function.
60% of all code execution in Windows 9x/ME ran in real mode.
> Win-9x will thunk down and use 16-bit DOS drivers that existed as part
> of the boot-configuration prior to the windows kernel being loaded,
> but that was done for legacy reasons as people transitioned existing
> systems from DOS/Win3.x to Win-9x.
No, it worked in _exactly the same way_ as in Windows 3.1 and 3.11.
> As hardware vendors came out with 32-bit drivers, the use of legacy
> DOS-mode drivers became non-existant.
/Some/ I/O in Windows 9x and ME used 32-bit access, but most of it used
16-bit real mode access via the underlying DOS. Most of the device
drivers for the Windows environment itself were _virtual_ device
drivers. And as I explained in my other reply to you, those virtual
device drivers still do exist in the NT-based Windows versions, but
that's only for compatibility reasons, because in NT, they are actually
translators to the NT-native drivers.
> The kernel of the NT line prevents direct hardware access, so it can't
> use 16-bit DOS drivers if no 32-bit drivers are available.
That part is correct.
> This is why Win-2k wasn't adopted early by game enthusiasts, because
> 32-bit sound-card drivers took a while to become available.
They /were/ available - at least, for the most prevalent types of sound
adapters - albeit that installing them was pretty much a nightmare. And
AGP support was only available as of NT 4.0 with SP3.
The reason why game developers preferred developing for Win 9x/ME was
that the underlying DOS allowed them to pull all sorts of nifty things
by directly accessing the hardware, which was not possible anymore in
NT. NT imposed a hardware abstraction layer, with rules. Game
developers did not like that, which is why Microsoft forced the
transition to NT with Windows XP by no longer offering DOS-based Windows
versions and providing Windows XP with a 9x/ME compatibility layer.
alt.os.linux.ubuntu...
> Ernst Oberhammer wrote:
>
>> Does not matter. What file/code you say does run directly 32b
>> without DOS intervention? None.
>
> DOS can't run 32-bit code.
reply to you.)
> So right off the bat, your insistence that DOS is some sort of
> necessary component of Win-9x/me is complete bullshit.
> I dare you to explain how a 32-bit protected mode kernel (that
> win-9x/me has) can possibly run "on top of" or even concurrent with a
> 16-bit real-mode DOS executive.
>> You start Win from DOS and not the opposite.
>
> And DOS is wiped from the system RAM when the 9x kernel is started.
Novell Netware, where DOS was only used as the bootloader for Netware
and could then, depending on what the administrator wanted, either be
wiped from the RAM to make room for caching, or kept in RAM to be used
as a DOS virtual machine so that the Netware server could double as a
workstation.
> Why are so stuck on how the win-9x/me kernel is loaded and then
> invoked?
> Once invoked, win-9x/me is a fully 32-bit OS that puts the CPU in
> protected mode.
protected mode is only an extender to DOS. Again, see my other reply to
you, and the Wikipedia link contained therein about the DPMI interface.
DPMI was quite popular among pure DOS applications even outside of
Windows. Think dBASE or AutoCAD, for instance.
> The fact that I can interrupt the process or stop the boot and keep
> the system in 16-bit real-mode DOS is irrelavent.
>> A Command Line / DOS-prompt run any DOS- program you may find
>> appropriate. Is NOT a feature.
>
> Any command line / dos prompt I open under win-9x is a virtual DOS
> machine.
machine because it is executed in V86, which is a hardware real mode
emulation from within 32-bit protected mode - albeit that Windows _95_
did also allow for the execution of DOS code in real mode, which was
dropped from Windows 98; see my other reply to you - but the operating
system loaded inside the DOS virtual machine was in essence only a
slimmed-down copy of the underlying DOS of Win 9x/ME.
>> It is a construction UPON. You see that in programming. You may
>> allocate pointers anywhere anytime.
>
> You confuse the fact that under 9x/me, that 16-bit DOS code has full
> access to the BIOS and hardware, so you assume that the native 32-bit
> win-9x drivers must somehow also use 16-bit code to perform their
> function.
> Win-9x will thunk down and use 16-bit DOS drivers that existed as part
> of the boot-configuration prior to the windows kernel being loaded,
> but that was done for legacy reasons as people transitioned existing
> systems from DOS/Win3.x to Win-9x.
> As hardware vendors came out with 32-bit drivers, the use of legacy
> DOS-mode drivers became non-existant.
16-bit real mode access via the underlying DOS. Most of the device
drivers for the Windows environment itself were _virtual_ device
drivers. And as I explained in my other reply to you, those virtual
device drivers still do exist in the NT-based Windows versions, but
that's only for compatibility reasons, because in NT, they are actually
translators to the NT-native drivers.
> The kernel of the NT line prevents direct hardware access, so it can't
> use 16-bit DOS drivers if no 32-bit drivers are available.
> This is why Win-2k wasn't adopted early by game enthusiasts, because
> 32-bit sound-card drivers took a while to become available.
adapters - albeit that installing them was pretty much a nightmare. And
AGP support was only available as of NT 4.0 with SP3.
The reason why game developers preferred developing for Win 9x/ME was
that the underlying DOS allowed them to pull all sorts of nifty things
by directly accessing the hardware, which was not possible anymore in
NT. NT imposed a hardware abstraction layer, with rules. Game
developers did not like that, which is why Microsoft forced the
transition to NT with Windows XP by no longer offering DOS-based Windows
versions and providing Windows XP with a 9x/ME compatibility layer.
David H. Lipman
Jul 14, 2013, 3:23:45 PM7/14/13
to
From: "Virus Guy" <Vi...@Guy.com>
Bwahahahahahahahahahahahahahahahaha...................
You are addicted to Win9x and you don't even understand is architecture.
--
Dave
Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk
http://www.pctipp.ch/downloads/dl/35905.asp
You are addicted to Win9x and you don't even understand is architecture.
--
Dave
Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk
http://www.pctipp.ch/downloads/dl/35905.asp
Reed Whitmore
Jul 14, 2013, 3:27:28 PM7/14/13
to
David H. Lipman wrote:
> Bwahahahahahahahahahahahahahahahaha...................
>
> You are addicted to Win9x and you don't even understand is architecture.
Correct. You start Win95 from DOS prompt, close Win95 and return back to
> Bwahahahahahahahahahahahahahahahaha...................
>
> You are addicted to Win9x and you don't even understand is architecture.
DOS (6.2 I guess).
Matt
Jul 14, 2013, 6:48:41 PM7/14/13
to
Dänk 42Ř <da...@sourdiesel.org> wrote in
news:ae-dnVojN8XetH_M...@earthlink.com:
> On Fri, 12 Jul 2013 19:49:39 +0000, Matt wrote:
>
>> Free Ed Snowden! <s...@nsa.gov> wrote in
>> news:aeKdnVamScLh033M...@earthlink.com:
>>
>>> Here is an extremely important and disturbing story that the
>>> American media are conveniently ignoring. According to the British
>>> newspaper The Guardian, documents leaked by Ed Snowden reveal that
>>> Microsoft has put a backdoor in its encryption to allow the NSA
>>> access what users think are confidential communications, passwords,
>>> etc. This has long
>>
>> No, that is not what they did. Read the article, instead of being so
>> dramatic about it, and you realize they provided the NSA with
>> unencrypted data before it was sent.
>
> Surreptitiously forwarding a user's data to the NSA just before he is
> finished encrypting it certainly qualifies as a "back door."
This is true. However, the OP stated that they had unencrypted the data
and then sent it. This is not true.
>
> What I find amusing is how liberals are actually DEFENDING Barack
> Obama for exceeding the worst abuses of the Nixon AND Bush
> administrations. "But Bush did it too!" is no longer an excuse.
Really? Why's that? Did you think the good guys would come in and just
sweep all the tools out the door?
Oh heck no. Get over it, we aren't lying down for you anymore.
Matt
news:ae-dnVojN8XetH_M...@earthlink.com:
> On Fri, 12 Jul 2013 19:49:39 +0000, Matt wrote:
>
>> Free Ed Snowden! <s...@nsa.gov> wrote in
>> news:aeKdnVamScLh033M...@earthlink.com:
>>
>>> Here is an extremely important and disturbing story that the
>>> American media are conveniently ignoring. According to the British
>>> newspaper The Guardian, documents leaked by Ed Snowden reveal that
>>> Microsoft has put a backdoor in its encryption to allow the NSA
>>> access what users think are confidential communications, passwords,
>>> etc. This has long
>>
>> No, that is not what they did. Read the article, instead of being so
>> dramatic about it, and you realize they provided the NSA with
>> unencrypted data before it was sent.
>
> Surreptitiously forwarding a user's data to the NSA just before he is
> finished encrypting it certainly qualifies as a "back door."
and then sent it. This is not true.
>
> What I find amusing is how liberals are actually DEFENDING Barack
> Obama for exceeding the worst abuses of the Nixon AND Bush
> administrations. "But Bush did it too!" is no longer an excuse.
sweep all the tools out the door?
Oh heck no. Get over it, we aren't lying down for you anymore.
Matt
David W. Hodgins
Jul 14, 2013, 9:34:16 PM7/14/13
to
On Sun, 14 Jul 2013 09:13:46 -0400, Virus Guy <Vi...@guy.com> wrote:
> It was already known that Microsoft used two keys, a primary and a
> spare, either of which can create valid signatures."
>
> (the above from http://en.wikipedia.org/wiki/NSAKEY)
>
> It's not clear to me how the presence of a second public key within
> ADVAPI32.DLL (regardless who owns the private key) could constitute a
> "back door" to a windows system.
The wiki article is not written well.
> It was already known that Microsoft used two keys, a primary and a
> spare, either of which can create valid signatures."
>
> (the above from http://en.wikipedia.org/wiki/NSAKEY)
>
> It's not clear to me how the presence of a second public key within
> ADVAPI32.DLL (regardless who owns the private key) could constitute a
> "back door" to a windows system.
In asymmetric (aka public key) encryption, the public key can be used
in one of two ways.
The public key can be used to verify a signature of a file, where the
signature was created by the holder of the private key. If the NSA
really has the private key, they could use it to sign a modified
version of a microsoft program, and it would pass the signature test,
on the target client's computer. The signature, is just a hash (like
sha512), that's been encrypted with the private key.
The public key can also be used, to encrypt a file, such that the
owner of the private key, is the only one who can decrypt the file.
The public key is not used to create signatures.
Since asymmetric encryption, is really slow, most cryptographic systems,
including ssl, use both asymmetric encryption, and symmetric encryption
(same passphrase used to encrypt, and decrypt), which is much faster.
For the symmetric encryption, a random number is generated. Since it's
fast, a large key has to be used, in order to prevent a brute force
attack. Most systems will use a 512 bit (64 byte key), made up using
pseudo random numbers. As long as a reasonably good pseudo random
number generation method is used, trying 2 to the power 512 keys, using
every computer that has ever existed on earth, would take billions, if
not trillions, of years. The random key used, is called a session key.
The problem with using symmetric encryption, is that you have to have
some way of getting the session key, to the person who has to be able
to decrypt the file. That's where the asymmetric encryption comes in.
The session key is encrypted using the public key(s) of the intended
recipient(s).
It would be quite easy to hide the extra copy of the session key,
encrypted with the nsa's public key, in an encrypted file. For the
recipient, who can decrypt the file/message, using their private
key, there would be nothing in the output, to suggest that there
was extra data, in the encrypted stream.
It would be very difficult to detect, and even if analysis of the
encrypted file showed some data that didn't need to be there, without
a copy of the nsa private key, there would be no way to prove that
the extra data was an encrypted copy of the session key.
The only way to confirm it, would be to disassemble, not only the
module that contains the key, but every module that calls it.
Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
Timothy Daniels
Jul 15, 2013, 12:24:09 AM7/15/13
to
"David W. Hodgins" wrote:
> [ . . . ]
> The problem with using symmetric encryption, is that you have to have
> some way of getting the session key, to the person who has to be able
> to decrypt the file. That's where the asymmetric encryption comes in.
>
> The session key is encrypted using the public key(s) of the intended
> recipient(s).
>
> It would be quite easy to hide the extra copy of the session key,
> encrypted with the nsa's public key, in an encrypted file. For the
> recipient, who can decrypt the file/message, using their private
> key, there would be nothing in the output, to suggest that there
> was extra data, in the encrypted stream.
>
> It would be very difficult to detect, and even if analysis of the
> encrypted file showed some data that didn't need to be there, without
> a copy of the nsa private key, there would be no way to prove that
> the extra data was an encrypted copy of the session key.
>
> The only way to confirm it, would be to disassemble, not only the
> module that contains the key, but every module that calls it.
>
> Regards, Dave Hodgins
I'm having trouble following this. Who would be hiding the extra
> some way of getting the session key, to the person who has to be able
> to decrypt the file. That's where the asymmetric encryption comes in.
>
> The session key is encrypted using the public key(s) of the intended
> recipient(s).
>
> It would be quite easy to hide the extra copy of the session key,
> encrypted with the nsa's public key, in an encrypted file. For the
> recipient, who can decrypt the file/message, using their private
> key, there would be nothing in the output, to suggest that there
> was extra data, in the encrypted stream.
>
> It would be very difficult to detect, and even if analysis of the
> encrypted file showed some data that didn't need to be there, without
> a copy of the nsa private key, there would be no way to prove that
> the extra data was an encrypted copy of the session key.
>
> The only way to confirm it, would be to disassemble, not only the
> module that contains the key, but every module that calls it.
>
> Regards, Dave Hodgins
copy of the session key - the sender who is evading the NSA, or the
software that has been modified for the NSA's use as a peephole?
*TimDaniels*
David W. Hodgins
Jul 15, 2013, 1:27:24 AM7/15/13
to
On Mon, 15 Jul 2013 00:24:09 -0400, Timothy Daniels <Spam...@nosuchdomain.com> wrote:
> I'm having trouble following this. Who would be hiding the extra
> copy of the session key - the sender who is evading the NSA, or the
> software that has been modified for the NSA's use as a peephole?
The software that has been modified (if true, by microsoft), for the
> I'm having trouble following this. Who would be hiding the extra
> copy of the session key - the sender who is evading the NSA, or the
> software that has been modified for the NSA's use as a peephole?
NSA to use.
Dänk 42Ø
Jul 15, 2013, 12:49:58 PM7/15/13
to
On Sun, 14 Jul 2013 22:48:41 +0000, Matt wrote:
> Dänk 42Ø <da...@sourdiesel.org> wrote in
>> What I find amusing is how liberals are actually DEFENDING Barack Obama
>> for exceeding the worst abuses of the Nixon AND Bush administrations.
>> "But Bush did it too!" is no longer an excuse.
>
> Really? Why's that? Did you think the good guys would come in and just
> sweep all the tools out the door?
Khrushchev succeeds Stalin, and suddenly the KGB are "good guys?"
> Oh heck no. Get over it, we aren't lying down for you anymore.
"We" implies you are a Democrat, and "you" implies that I am a
Republican, which I am not. I called for Emperor Bush's impeachment for
his illegal wiretapping program, and I demand the same for Chairman Obama.
If you really believe that the Democrat Party will exercise this
unconstitutional surveillance power benevolently, you are a fool. And
no, this does not mean I think or thought that the Republican Party would
either. This is why the Framers wrote the Fourth Amendment.
> Dänk 42Ø <da...@sourdiesel.org> wrote in
>> What I find amusing is how liberals are actually DEFENDING Barack Obama
>> for exceeding the worst abuses of the Nixon AND Bush administrations.
>> "But Bush did it too!" is no longer an excuse.
>
> Really? Why's that? Did you think the good guys would come in and just
> sweep all the tools out the door?
> Oh heck no. Get over it, we aren't lying down for you anymore.
Republican, which I am not. I called for Emperor Bush's impeachment for
his illegal wiretapping program, and I demand the same for Chairman Obama.
If you really believe that the Democrat Party will exercise this
unconstitutional surveillance power benevolently, you are a fool. And
no, this does not mean I think or thought that the Republican Party would
either. This is why the Framers wrote the Fourth Amendment.
Matt
Jul 15, 2013, 1:20:23 PM7/15/13
to
Dänk 42Ř <da...@sourdiesel.org> wrote in
news:SaCdndaOJq6rtXnM...@earthlink.com:
> On Sun, 14 Jul 2013 22:48:41 +0000, Matt wrote:
>
Matt
Message has been deleted
Message has been deleted
Message has been deleted
Aragorn
Jul 16, 2013, 4:22:18 PM7/16/13
to
On Tuesday 16 July 2013 21:11, Dustin conveyed the following to
alt.os.linux.ubuntu...
> Aragorn <thor...@telenet.be.invalid> wrote in news:kruplp$fc$1@dont-
> email.me:
Oh yes, that one too, of course. ;-)
>> The reason why game developers preferred developing for Win 9x/ME was
>> that the underlying DOS allowed them to pull all sorts of nifty
>> things by directly accessing the hardware, which was not possible
>> anymore in NT. NT imposed a hardware abstraction layer, with rules.
>> Game developers did not like that, which is why Microsoft forced the
>> transition to NT with Windows XP by no longer offering DOS-based
>> Windows versions and providing Windows XP with a 9x/ME compatibility
>> layer.
>
> Rocking. You know your stuff!
Thank you for acknowledging that. Unfortunately, it takes someone who
knows their stuff too to recognize that I know my stuff as well, whereas
especially the Microsoft fanboys like throwing the shroud of
unreliability upon anyone who contradicts the Microsoft marketing talk.
;-)
alt.os.linux.ubuntu...
> Aragorn <thor...@telenet.be.invalid> wrote in news:kruplp$fc$1@dont-
> email.me:
>
>> On Sunday 14 July 2013 18:05, Virus Guy conveyed the following to
>> alt.os.linux.ubuntu...
>>
>>> Ernst Oberhammer wrote:
>>>
>>>> Does not matter. What file/code you say does run directly 32b
>>>> without DOS intervention? None.
>>>
>>> DOS can't run 32-bit code.
>>
>> Not natively, but by way of a DPMI extender, yes, it can. (See my
>> other reply to you.)
>
> DOOM! [G]
>> On Sunday 14 July 2013 18:05, Virus Guy conveyed the following to
>> alt.os.linux.ubuntu...
>>
>>> Ernst Oberhammer wrote:
>>>
>>>> Does not matter. What file/code you say does run directly 32b
>>>> without DOS intervention? None.
>>>
>>> DOS can't run 32-bit code.
>>
>> Not natively, but by way of a DPMI extender, yes, it can. (See my
>> other reply to you.)
>
Oh yes, that one too, of course. ;-)
>> The reason why game developers preferred developing for Win 9x/ME was
>> that the underlying DOS allowed them to pull all sorts of nifty
>> things by directly accessing the hardware, which was not possible
>> anymore in NT. NT imposed a hardware abstraction layer, with rules.
>> Game developers did not like that, which is why Microsoft forced the
>> transition to NT with Windows XP by no longer offering DOS-based
>> Windows versions and providing Windows XP with a 9x/ME compatibility
>> layer.
>
Thank you for acknowledging that. Unfortunately, it takes someone who
knows their stuff too to recognize that I know my stuff as well, whereas
especially the Microsoft fanboys like throwing the shroud of
unreliability upon anyone who contradicts the Microsoft marketing talk.
;-)
Aragorn
Jul 16, 2013, 4:40:22 PM7/16/13
to
On Tuesday 16 July 2013 21:08, Dustin conveyed the following to
alt.os.linux.ubuntu...
> Virus Guy <Vi...@Guy.com> wrote in news:51E2CC64...@Guy.com:
So does FreeDOS. ;-)
> It's not a virtual machine under win9x. It's a very real DOS
> subsystem. Any changes it makes are real. Not virtualized, but real.
True, albeit that a DOS window inside Windows 98 and ME did run in the
processor's V86 mode so that the DOS session could be run under
multitasking control from the win32 component. In Windows 95, it could
run either in V86 mode or in real mode.
In the latter case, the Windows-specific code and all the other
applications were halted until the processor returned from real mode -
or otherwise put: after the DOS session was closed - because an x86
processor in real mode and running DOS doesn't support multitasking.
>> The kernel of the NT line prevents direct hardware access, so it
>> can't use 16-bit DOS drivers if no 32-bit drivers are available.
>> This is why Win-2k wasn't adopted early by game enthusiasts, because
>> 32-bit sound-card drivers took a while to become available.
>
> win2k wasn't designed for gaming in mind. Windows XP solved that.
Windows 2000 was actually Windows NT 5.0 - Bill Gates chose to change
the name to Windows 2000 when NT 5.0 was still in beta stage - and as
such it was the third generation of NT.
The NT-based Windows versions were intended to take over from the DOS-
based Windows versions eventually, but they were too different to
properly support multimedia and gaming, and they were always considered
too business-oriented. Gates recognized the problem with NT's adoption,
which is why Windows ME was the last of the DOS-based versions, and XP
merged the two Windows families into one.
And it didn't go well right away, because although Windows XP did
contain the so-called "Windows on Windows" emulators for mimicking
earlier Windows versions in XP, they weren't fully compatible with those
earlier Windows versions for the simple reason that XP didn't run off a
DOS/DPMI kernel anymore. But given that from there on all Windows
versions were based upon NT, the game developers were forced to adapt
their code base to the NT-based win32 API, and they did, because
Microsoft left them no other choice.
alt.os.linux.ubuntu...
> Virus Guy <Vi...@Guy.com> wrote in news:51E2CC64...@Guy.com:
>
>> Ernst Oberhammer wrote:
>>
>>> Does not matter. What file/code you say does run directly 32b
>>> without DOS intervention? None.
>>
>> DOS can't run 32-bit code. So right off the bat, your insistence
>> that DOS is some sort of necessary component of Win-9x/me is complete
>> bullshit.
>
> DOS 7 does, actually.
>> Ernst Oberhammer wrote:
>>
>>> Does not matter. What file/code you say does run directly 32b
>>> without DOS intervention? None.
>>
>> DOS can't run 32-bit code. So right off the bat, your insistence
>> that DOS is some sort of necessary component of Win-9x/me is complete
>> bullshit.
>
So does FreeDOS. ;-)
> It's not a virtual machine under win9x. It's a very real DOS
> subsystem. Any changes it makes are real. Not virtualized, but real.
True, albeit that a DOS window inside Windows 98 and ME did run in the
processor's V86 mode so that the DOS session could be run under
multitasking control from the win32 component. In Windows 95, it could
run either in V86 mode or in real mode.
In the latter case, the Windows-specific code and all the other
applications were halted until the processor returned from real mode -
or otherwise put: after the DOS session was closed - because an x86
processor in real mode and running DOS doesn't support multitasking.
>> The kernel of the NT line prevents direct hardware access, so it
>> can't use 16-bit DOS drivers if no 32-bit drivers are available.
>> This is why Win-2k wasn't adopted early by game enthusiasts, because
>> 32-bit sound-card drivers took a while to become available.
>
Windows 2000 was actually Windows NT 5.0 - Bill Gates chose to change
the name to Windows 2000 when NT 5.0 was still in beta stage - and as
such it was the third generation of NT.
The NT-based Windows versions were intended to take over from the DOS-
based Windows versions eventually, but they were too different to
properly support multimedia and gaming, and they were always considered
too business-oriented. Gates recognized the problem with NT's adoption,
which is why Windows ME was the last of the DOS-based versions, and XP
merged the two Windows families into one.
And it didn't go well right away, because although Windows XP did
contain the so-called "Windows on Windows" emulators for mimicking
earlier Windows versions in XP, they weren't fully compatible with those
earlier Windows versions for the simple reason that XP didn't run off a
DOS/DPMI kernel anymore. But given that from there on all Windows
versions were based upon NT, the game developers were forced to adapt
their code base to the NT-based win32 API, and they did, because
Microsoft left them no other choice.
Big Bad Bob
Jul 17, 2013, 4:44:56 AM7/17/13
to
On 07/14/13 06:13, Virus Guy so wittily quipped:
I remember seeing that symbol (or one like it) exported in other
NT-based OS's as well, such as pre-release versions of XP. It does
raise an eyebrow, and maybe was placed there originally due to actual
requirements of having that kind of "feature". The 90's was a time when
data encryption was treated the same as a military style weapon.
Fortunately the laws were changed to something a bit more sane [NOW you
basically register your algorithm with some gummint agency before you
can export it, or at least the last time I checked that's what it was].
Before that, only 60-DES equivalent could be exported, and that's as
much of a joke as WEP.
I doubt the NSA has a back door into windows. but if you want to use
that potential as a reason to run Linux and/or use open source
encryption like TrueCrypt, go for it.
on a related note, Korea's reaction to the data encryption fiasco was to
mandate their own closed-source encryption library for ALL! BANKING!
TRANSACTIONS! and it requires an ActiveX! PLUGIN! for INTERNET!
EXPLORER! and they are STILL! USING! IT! in spite of the obvious
security craters involved.
https://blog.mozilla.org/gen/2010/04/28/the-security-of-internet-banking-in-south-korea/
> It was pointed out as long ago as 1999 that a debugging symbol (_NSAKEY)
> existed in ADVAPI32.DLL (security
> and encryption driver) when it released Service Pack 5 for Windows NT
> 4.0.
sorry, I call 'FUD' on that.
> existed in ADVAPI32.DLL (security
> and encryption driver) when it released Service Pack 5 for Windows NT
> 4.0.
I remember seeing that symbol (or one like it) exported in other
NT-based OS's as well, such as pre-release versions of XP. It does
raise an eyebrow, and maybe was placed there originally due to actual
requirements of having that kind of "feature". The 90's was a time when
data encryption was treated the same as a military style weapon.
Fortunately the laws were changed to something a bit more sane [NOW you
basically register your algorithm with some gummint agency before you
can export it, or at least the last time I checked that's what it was].
Before that, only 60-DES equivalent could be exported, and that's as
much of a joke as WEP.
I doubt the NSA has a back door into windows. but if you want to use
that potential as a reason to run Linux and/or use open source
encryption like TrueCrypt, go for it.
on a related note, Korea's reaction to the data encryption fiasco was to
mandate their own closed-source encryption library for ALL! BANKING!
TRANSACTIONS! and it requires an ActiveX! PLUGIN! for INTERNET!
EXPLORER! and they are STILL! USING! IT! in spite of the obvious
security craters involved.
https://blog.mozilla.org/gen/2010/04/28/the-security-of-internet-banking-in-south-korea/
Ignoramus26578
Jul 27, 2013, 10:02:30 AM7/27/13
to
My understanding of that old _NSAKEY story is as follows.
When encrypting a data stream, a random encryption key is generated to
be used by the stream cypher.
That is not the same as public and private keys, and is used to
encrypt the specific data stream. That cipher key is encrypted with
the recipient's public key. The recipient uses its private key to
decrypt the cipher key, and then to decrypt the data. This is
legitimate use of public key encryption.
Microsoft also encrypts that cipher stream key with NSA's key and
therefore, if NSA is able to intercent encrypted data, it can decrypt
the key used to encrypt the data stream, and then decrypt the data
stream. That is NSA's backdoor to Microsoft encryption.
No other explanations made sense to me at the time.
i
When encrypting a data stream, a random encryption key is generated to
be used by the stream cypher.
That is not the same as public and private keys, and is used to
encrypt the specific data stream. That cipher key is encrypted with
the recipient's public key. The recipient uses its private key to
decrypt the cipher key, and then to decrypt the data. This is
legitimate use of public key encryption.
Microsoft also encrypts that cipher stream key with NSA's key and
therefore, if NSA is able to intercent encrypted data, it can decrypt
the key used to encrypt the data stream, and then decrypt the data
stream. That is NSA's backdoor to Microsoft encryption.
No other explanations made sense to me at the time.
i
Cybe R. Wizard
Jul 27, 2013, 10:49:43 AM7/27/13
to
on, and, therefore, spamming the other two groups.
Cybe R. Wizard
--
T i m non cogitat, ergo dumb
Virus Guy
Jul 27, 2013, 1:13:07 PM7/27/13
to
Ignoramus26578 wrote:
> Microsoft also encrypts that cipher stream key with NSA's key and
> therefore, if NSA is able to intercent encrypted data, it can
> decrypt the key used to encrypt the data stream, and then decrypt
> the data stream. That is NSA's backdoor to Microsoft encryption.
>
> No other explanations made sense to me at the time.
Can a data stream be encrypted by two different keys simultaneously,
> Microsoft also encrypts that cipher stream key with NSA's key and
> therefore, if NSA is able to intercent encrypted data, it can
> decrypt the key used to encrypt the data stream, and then decrypt
> the data stream. That is NSA's backdoor to Microsoft encryption.
>
> No other explanations made sense to me at the time.
such that either key can decrypt the stream?
Wouldn't that be necessary if a target is communicating with a
third-party machine using encryption and the NSA has access to the data
stream, and both the NSA and the third-party machine can decrypt the
stream?
And are we talking about anything other than https or vpn? If not, what
other commonly-used windoze-based applications or protocals (circa
year-2000) made use of encryption?
Ignoramus26578
Jul 27, 2013, 3:19:37 PM7/27/13
to
On 2013-07-27, Virus Guy <Vi...@Guy.com> wrote:
> Ignoramus26578 wrote:
>
>> Microsoft also encrypts that cipher stream key with NSA's key and
>> therefore, if NSA is able to intercent encrypted data, it can
>> decrypt the key used to encrypt the data stream, and then decrypt
>> the data stream. That is NSA's backdoor to Microsoft encryption.
>>
>> No other explanations made sense to me at the time.
>
> Can a data stream be encrypted by two different keys simultaneously,
> such that either key can decrypt the stream?
recipient's public key, and the encrypted key is sent with the
encrypted data. THis is how public key encryption works. With the
Microsoft software, the stream cipher key is also encrypted with NSA's
public key, and that is sent along with the rest of the data. So, if
NSA intercepts the encrypted data, they cat decrypt the streak key
with their private key.
Read up on public key cryptoraphy.
Virus Guy
Jul 27, 2013, 3:47:34 PM7/27/13
to
Ignoramus26578 wrote:
> > Can a data stream be encrypted by two different keys
> > simultaneously, such that either key can decrypt the stream?
>
> This is not how it works.
The NSA is the NSA. Presumably it has access to the data stream.
> > Can a data stream be encrypted by two different keys
> > simultaneously, such that either key can decrypt the stream?
>
> This is not how it works.
The data stream is Data leaving the Target and going to the Recipient.
The Target is a person of interest (to the NSA)
The Recipient could be an individual, but is probably a web-server.
> The stream key is encrypted with the recipient's public key
with the Recipient's public key, which is no secret to anyone. Anyone
looking at the data stream can theoretically not decipher it without
knowing the Recipient's private key. Naturally the Recipient can
decipher the Data.
> and the encrypted key is sent with the encrypted data.
> With the Microsoft software, the stream cipher key is also
> encrypted with NSA's public key, and that is sent along with
> the rest of the data.
(the one being identified as _NSAKEY) then the Recipient will not be
able to decrypt the Data - but the NSA will (naturally) be able to do so
(if they have access to the data stream - presumably real-time access).
Since the Recipient will not be able to decrypt the Data, the
communication between the Target and Recipient will break down and both
parties will suspect something is wrong and further surveilence by the
NSA during that session will not be possible.
How ADVAPI32.DLL determines/decides when to use the NSA key is another
question that I haven't seen anyone discuss.
Ignoramus8874
Jul 28, 2013, 1:32:43 PM7/28/13
to
On 2013-07-27, Virus Guy <Vi...@Guy.com> wrote:
> Ignoramus26578 wrote:
>
>> > Can a data stream be encrypted by two different keys
>> > simultaneously, such that either key can decrypt the stream?
>>
>> This is not how it works.
>
> The NSA is the NSA. Presumably it has access to the data stream.
> The data stream is Data leaving the Target and going to the Recipient.
> The Target is a person of interest (to the NSA)
> The Recipient could be an individual, but is probably a web-server.
>
>> The stream key is encrypted with the recipient's public key
>
> The Target is sending Data to the Recipient, but the Data is scrambled
> with the Recipient's public key, which is no secret to anyone. Anyone
> looking at the data stream can theoretically not decipher it without
> knowing the Recipient's private key. Naturally the Recipient can
> decipher the Data.
Your post reveals intelligence, but at the same time, lack of
>
>> > Can a data stream be encrypted by two different keys
>> > simultaneously, such that either key can decrypt the stream?
>>
>> This is not how it works.
>
> The NSA is the NSA. Presumably it has access to the data stream.
> The data stream is Data leaving the Target and going to the Recipient.
> The Target is a person of interest (to the NSA)
> The Recipient could be an individual, but is probably a web-server.
>
>> The stream key is encrypted with the recipient's public key
>
> The Target is sending Data to the Recipient, but the Data is scrambled
> with the Recipient's public key, which is no secret to anyone. Anyone
> looking at the data stream can theoretically not decipher it without
> knowing the Recipient's private key. Naturally the Recipient can
> decipher the Data.
knowledge of this important subject. So, please, read some articles on
public key cryptography.
The data stream is not encrypted with the recipient's public key. It
is encrypted with a faster stream cypher, such as IDEA. The key for
that stream cypher is picked at random, and that key is what is
encrypted with the recipient's public key, and sent along with the
encrypted data. This makes encryption much faster.
>> and the encrypted key is sent with the encrypted data.
>
> Not sure where that fits into this. What key is encrypted?
>
>> With the Microsoft software, the stream cipher key is also
>> encrypted with NSA's public key, and that is sent along with
>> the rest of the data.
>
> If the Data leaving the Target is encrypted with the NSA's public key
> (the one being identified as _NSAKEY) then the Recipient will not be
> able to decrypt the Data - but the NSA will (naturally) be able to do so
> (if they have access to the data stream - presumably real-time access).
>
> Since the Recipient will not be able to decrypt the Data, the
> communication between the Target and Recipient will break down and both
> parties will suspect something is wrong and further surveilence by the
> NSA during that session will not be possible.
>
> How ADVAPI32.DLL determines/decides when to use the NSA key is another
> question that I haven't seen anyone discuss.
cipher key: one encrypted with the recipient's public key, and one
encrypted with NSA's public key.
i
Hans Palme
Feb 24, 2014, 4:08:58 PM2/24/14
to
Am 12.07.2013 20:44, schrieb Free Ed Snowden!:
> Here is an extremely important and disturbing story that the American
> media are conveniently ignoring. According to the British newspaper The
> Guardian, documents leaked by Ed Snowden reveal that Microsoft has put a
> backdoor in its encryption to allow the NSA access what users think are
> confidential communications, passwords, etc. This has long been
> Here is an extremely important and disturbing story that the American
> media are conveniently ignoring. According to the British newspaper The
> Guardian, documents leaked by Ed Snowden reveal that Microsoft has put a
> backdoor in its encryption to allow the NSA access what users think are
> suspected, but has never been proven until now.
> __________________________________________________
>
>
> http://www.guardian.co.uk/world/2013/jul/11/microsoft-nsa-collaboration-
> user-data
>
> 11 July 2013
>
> "Microsoft has collaborated closely with US intelligence services to
> allow users' communications to be intercepted, including helping the
> National Security Agency to circumvent the company's own encryption,
> according to top-secret documents obtained by the Guardian."
>
> "The files provided by Edward Snowden illustrate the scale of co-
> "Microsoft has collaborated closely with US intelligence services to
> allow users' communications to be intercepted, including helping the
> National Security Agency to circumvent the company's own encryption,
> according to top-secret documents obtained by the Guardian."
>
> operation between Silicon Valley and the intelligence agencies over the
> last three years."
>
> "Microsoft helped the NSA to circumvent its encryption to address
> concerns that the agency would be unable to intercept web chats on the
> new Outlook.com portal; The agency already had pre-encryption stage
> access to email on Outlook.com, including Hotmail..."
>
> "In July last year, nine months after Microsoft bought Skype, the NSA
> boasted that a new capability had tripled the amount of Skype video calls
> being collected through Prism; Material collected through Prism is
> routinely shared with the FBI and CIA, with one NSA document describing
> the program as a 'team sport.'"
>
> [Note: The Chinese government has been overhauling its computer systems
> to use open-source Linux, rightfully distrusting Microsoft's proprietary
> closed-source software.]
>
Microsoft is imperialistic and anti-democratic. they ar gansters, like
nazis, the windows-logo is simular like a hook-cross. But you have the
choice between linux and apple, but never windows, the crap of bill
gates, there is a agabage-deponie, full with windows-cds and books, and
gates is also gabage, bee free, the fachists in europe blocket my
textes, but i now, the true will win, and the evil like windoes will loose.
mike
Mar 3, 2014, 1:35:55 PM3/3/14
to
source of the meat you eat.
Ever visited a farm and demanded to see what chemicals they used?
How often have you sent your tap water in for chemical/biological analysis?
Ever visited your bank and demanded to examine their source code?
Ever been online?
Of all the things we have to be angry about, linux seems to be the
least of our solutions.
Jihad Jeffy
Mar 4, 2014, 4:39:47 PM3/4/14
to
is no backdoor in it, but millions of computer geeks have examined the
source code and no serious weakness has been discovered yet. The
slaughterhouse is something else entirely -- we know what'g going on is
disgusting but tolerate it because we're too cheap to patronize
open-source farms (reputable farms give free tours).
Microsoft is an agent of the U.S. government. Just ten or fifteen years
ago the American government was always threatening antitrust action
against the company, now nothing. Looking back at my DOS/Windows
childhood, I can't believe I just blindly installed the constant
"updates," never really knowing whether they were to correct some
security flaw or create a new one for the government to exploit. As a
global company, Microsoft really shot itself in the foot with this one.
John Bokma
Mar 4, 2014, 8:30:17 PM3/4/14
to
Jihad Jeffy <chef...@dahmer.org> writes:
> I'm using Linux right now and love it. There is no way to prove there
> is no backdoor in it, but millions of computer geeks have examined the
> source code and no serious weakness has been discovered yet.
According to this article at Ars Technica, '[A] bug in the GnuTLS
> I'm using Linux right now and love it. There is no way to prove there
> is no backdoor in it, but millions of computer geeks have examined the
> source code and no serious weakness has been discovered yet.
library makes it trivial for attackers to bypass secure sockets
layer (SSL) and Transport Layer Security (TLS) protections available
on websites that depend on the open source package. Initial
estimates included in Internet discussions such as this one indicate
that more than 200 different operating systems or applications rely
on GnuTLS to implement crucial SSL and TLS operations, but it
wouldn't be surprising if the actual number is much higher. Web
applications, e-mail programs, and other code that use the library
are vulnerable to exploits that allow attackers monitoring
connections to silently decode encrypted traffic passing between end
users and servers.' The coding error may have been present since
2005.
via http://slashdot.org/story/198965
so much for millions of computer geeks yada yada
https://www.gitorious.org/gnutls/gnutls/commit/6aa26f78150ccbdf0aec1878a41c17c41d358a3b
Stuff like this is extremely easy to overlook. That's one reason why I
write /tests/ to test my code. Stuff like this should come with tests
that test each and every branch.
--
John Bokma j3b
Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
0 new messages