PDA

View Full Version : Do you use secure email



cmosentine
15-Aug-2013, 12:33
Hi all:

Out of curiosity, do you use secure email, either at home or at work? What system do you use?

ab
15-Aug-2013, 13:54
Thunderbird, Enigmail plugin. Yes, I encrypt e-mails whenever I can.
Sadly, it relies on the recipient having a key, and that's not very
common. Yes, I'd recommend it for everybody since, with the right client
(requires a thick client... no web-only clients can properly do this afaik
since that would involve somehow sharing the private key with something in
or beyond the web browser which is insane), this is really easy to
implement and it is the only way to guarantee your e-mail is kept between
you and the other party (and folks to which either you or the other party
choose to forward the message).

Good luck.

cmosentine
15-Aug-2013, 14:22
Thanks for the reply. That is what I thought was required.

Dave Howe
16-Aug-2013, 15:44
On 15/08/2013 12:33, cmosentine wrote:
> Hi all:
>
> Out of curiosity, do you use secure email, either at home or at work?
> What system do you use?

Whatever the recipient can handle - seriously.

For some, that's going to be PGP or S/MIME. Those both need preshared keys.

If your employer is willing to spring for the system, oracle based
encryption solutions such as the pgp universal gateway and cisco CRES
are good.

for the rest, just enforced TLS on the outbound smtp bridgehead is about
the best you can do.

Joseph Marton
17-Aug-2013, 02:44
cmosentine wrote:

> Out of curiosity, do you use secure email, either at home or at work?
> What system do you use?

I use GroupWise, a secure and reliable collaboration platform.

--
Does this washcloth smell like chloroform?

Dave Howe
19-Aug-2013, 13:07
On 17/08/2013 02:44, Joseph Marton wrote:
> cmosentine wrote:
>
>> Out of curiosity, do you use secure email, either at home or at work?
>> What system do you use?
>
> I use GroupWise, a secure and reliable collaboration platform.

HAHAHAHA

Last I looked, the gwia doesn't even check TLS certificates and has no
way to enforce TLS.....

the Trusted Application API lets you connect to anyone's mailbox you
like, whenever you want, using a standard groupwise client and a half
dozen lines of VBS.

Groupwise is a lot of things, but secure isn't any of them :)

Joseph Marton
19-Aug-2013, 13:45
Dave Howe wrote:

> Last I looked, the gwia doesn't even check TLS certificates and has no
> way to enforce TLS.....

Of course GWIA supports SSL/TLS.

> the Trusted Application API lets you connect to anyone's mailbox you
> like, whenever you want, using a standard groupwise client and a half
> dozen lines of VBS.

You need administrator access to even create a trusted application, and
even then you can't just use a standard GW client to get into a user's
mailbox. You have to use a third-party application which specifically
uses the trusted app.

On the other hand, with Exchange all an administrator needs to do is
type a single command and now administrators can simply use the Outlook
client to access every single user's mailbox.

http://help.outlook.com/en-Us/140/gg709759.aspx

--
Does this washcloth smell like chloroform?

Dave Howe
19-Aug-2013, 14:52
On 19/08/2013 13:45, Joseph Marton wrote:
> Dave Howe wrote:
>
>> Last I looked, the gwia doesn't even check TLS certificates and has no
>> way to enforce TLS.....
>
> Of course GWIA supports SSL/TLS.

That isn't what I said. What I said was that, while it *supports* TLS,
it doesn't bother checking anything at all in the certificate - not even
expiry or hostname. Try it sometime. It also has no way to enforce it,
so if you simply MitM a gwia connection and remove the "starttls"
response from the EHLO responses, the gwia will happily send the whole
stream unencrypted.

>> the Trusted Application API lets you connect to anyone's mailbox you
>> like, whenever you want, using a standard groupwise client and a half
>> dozen lines of VBS.
>
> You need administrator access to even create a trusted application, and
> even then you can't just use a standard GW client to get into a user's
> mailbox. You have to use a third-party application which specifically
> uses the trusted app.

Erm, no. you need admin access to create the trustapp token - that can
either be restricted to a specific IP (usually a good idea!) or not.

The gwcma1.dll installed in the standard installation of the gw client
has a "SetTrustedApplicationCredentials" method on the application
object, and a login method - call the first in vbs, call the second
(again in vbs) and it will launch a full client logged in as the target
user. By using gwcmb1.dll first, you can list the users in a given post
office so you can select one for the procedure (that may require admin
rights if you want to see/select a user not in the normal address book).
This works, in practice - I have such a vbs script written for
troubleshooting problems with the BES gateways, and it works just fine.


> On the other hand, with Exchange all an administrator needs to do is
> type a single command and now administrators can simply use the Outlook
> client to access every single user's mailbox.

Yup. I do note that you can then go into your outlook client (not the
webapp, sadly) and check to see who has rights to your inbox - but that
doesn't really matter - pointing and saying "but they are just as bad"
doesn't work outside of a playground.

Joseph Marton
19-Aug-2013, 14:56
Dave Howe wrote:

> The gwcma1.dll installed in the standard installation of the gw
> client has a "SetTrustedApplicationCredentials" method on the
> application object, and a login method - call the first in vbs, call
> the second (again in vbs) and it will launch a full client logged in
> as the target user. By using gwcmb1.dll first, you can list the users
> in a given post office so you can select one for the procedure (that
> may require admin rights if you want to see/select a user not in the
> normal address book). This works, in practice - I have such a vbs
> script written for troubleshooting problems with the BES gateways,
> and it works just fine.
>
> Yup. I do note that you can then go into your outlook client (not the
> webapp, sadly) and check to see who has rights to your inbox - but
> that doesn't really matter - pointing and saying "but they are just
> as bad" doesn't work outside of a playground.

I'm not saying Exchange is just as bad. Looks like they are worse.
Look at what you described above and trying to use the GW client to
access users' mailboxes via the trusted app. Now look at how it's done
with Exchange. Grab a DLL and put together a VB script? Or just log
into a native client without doing anything? Yeah, exactly.

--
Does this washcloth smell like chloroform?

Anders Gustafsson
19-Aug-2013, 15:06
Joseph Marton,
> I'm not saying Exchange is just as bad.

Wrong response Joe, the correct one would be:

Your message pointed out several possible attacks that I was previously
unaware of. I will take this up with the GW PM right away.

--
Anders Gustafsson (NKP)
The Aaland Islands (N60 E20)

Have an idea for a product enhancement? Please visit:
http://www.novell.com/rms

Joseph Marton
19-Aug-2013, 18:05
Anders Gustafsson wrote:

> Your message pointed out several possible attacks that I was
> previously unaware of. I will take this up with the GW PM right away.

Ask PM to remove trusted app functionality?

I'm also not sure the SSL/TLS information in this thread is entirely
accurate either.

--
Does this washcloth smell like chloroform?

Anders Gustafsson
19-Aug-2013, 19:28
Joseph Marton,
> Ask PM to remove trusted app functionality?

No, look at possible security implications.

> I'm also not sure the SSL/TLS information in this thread is entirely
> accurate either.

But there is no harm i verifying that, right?

--
Anders Gustafsson (NKP)
The Aaland Islands (N60 E20)

Have an idea for a product enhancement? Please visit:
http://www.novell.com/rms

Anders Gustafsson
19-Aug-2013, 19:33
Dave Howe,
> That isn't what I said. What I said was that, while it *supports* TLS,
> it doesn't bother checking anything at all in the certificate - not even
> expiry or hostname. Try it sometime

Thanks for pointing that out. A bug has been raised so that it will be
properly investigated.

I have also started some discussions internally about possible security
implications of the trusted app interface.

--
Anders Gustafsson (NKP)
The Aaland Islands (N60 E20)

Have an idea for a product enhancement? Please visit:
http://www.novell.com/rms

Anders Gustafsson
19-Aug-2013, 20:23
Dave Howe,
> The gwcma1.dll installed in the standard installation of the gw client
> has a "SetTrustedApplicationCredentials" method on the application
> object, and a login method - call the first in vbs,

But you still need the token, right? Just wanting to clarify things.

--
Anders Gustafsson (NKP)
The Aaland Islands (N60 E20)

Have an idea for a product enhancement? Please visit:
http://www.novell.com/rms

Joseph Marton
20-Aug-2013, 01:01
Anders Gustafsson wrote:

> > Ask PM to remove trusted app functionality?
>
> No, look at possible security implications.

Not a bad idea to check. Just saying based on what's been described so
far it sounds WAD and wouldn't necessarily be a security issue. It'd
be sorta like saying if you give someone the password to the tree's
admin account it's a security issue that someone can log in with the
Novell client and use a script to nuke a bunch of objects in the tree.
Well, that's the purpose of the admin account.

> > I'm also not sure the SSL/TLS information in this thread is entirely
> > accurate either.
>
> But there is no harm i verifying that, right?

Nope and soon we'll find out what the story is. :-)

--
Does this washcloth smell like chloroform?

Dave Howe
20-Aug-2013, 11:00
On 19/08/2013 20:23, Anders Gustafsson wrote:
> Dave Howe,
>> The gwcma1.dll installed in the standard installation of the gw client
>> has a "SetTrustedApplicationCredentials" method on the application
>> object, and a login method - call the first in vbs,
>
> But you still need the token, right? Just wanting to clarify things.

Yes. This is behavior as designed, not a bug per se - groupwise has a
backdoor to allow admin-authorized users or services unrestricted access
to mailboxes (and as far as I know, you can't restrict the GWTAPP token
to just a single mailbox, access is granted to all mailboxes)

*however*, as has been pointed out, to use that backdoor you need to
jump though several hoops.

First, you need to be an admin, or have an admin run GWTAPP on your
behalf (you don't even need to compile your own GWTAPP, its available as
a nice, friendly installer on the Novell site, but it isn't part of
anyone's standard install. You can also "steal" the key from a BES server)

Second, you need to make a couple of API calls (note, you don't need to
download the dll from anywhere, it comes as standard with the gw client)

Third, and most importantly, you *need to know* that the above is
possible and how to do it. I went for years thinking that GW was secure,
even from its own administrators. Having to fix a customer's BES
solution corrected that belief, and once my mindset was correct, a quick
look at the DLL (which I already knew about, due to scripting other
automation tasks) showed me a trusted api login. The documentation also
shows how you could do this using nothing but a key and the telnet app,
if you understand IMAP commands :)

Dave Howe
20-Aug-2013, 11:07
On 19/08/2013 19:33, Anders Gustafsson wrote:
> Dave Howe,
>> That isn't what I said. What I said was that, while it *supports* TLS,
>> it doesn't bother checking anything at all in the certificate - not even
>> expiry or hostname. Try it sometime
>
> Thanks for pointing that out. A bug has been raised so that it will be
> properly investigated.

Tried that a couple of years ago, when the lack of any way to enforce or
even check TLS via a GWIA cost me (well, my employer) a UK government
contract - they had to go with exchange, as that can require TLS *and*
enforce validation with a local CA cert (and enforced TLS was part of
the Code of Connection).

My suggestion, to reproduce the missing functionality by adding exim to
the same SLES box, didn't go down well either.

Dave Howe
20-Aug-2013, 11:10
On 20/08/2013 11:00, Dave Howe wrote:
> Yes. This is behavior as designed, not a bug per se - groupwise has a
> backdoor to allow admin-authorized users or services unrestricted access
> to mailboxes (and as far as I know, you can't restrict the GWTAPP token
> to just a single mailbox, access is granted to all mailboxes)

On the bright side - GW seems to support s/mime reasonably well
(although that's hardly unique), and the mail is stored encrypted, so it
*is* possible to get a fair bit of security provided you prepare in
advance :)

Anders Gustafsson
20-Aug-2013, 11:42
Dave Howe,
> (and as far as I know, you can't restrict the GWTAPP token
> to just a single mailbox, access is granted to all mailboxes)

But being able to do so, say per group would be rather cool!

--
Anders Gustafsson (NKP)
The Aaland Islands (N60 E20)

Have an idea for a product enhancement? Please visit:
http://www.novell.com/rms

Dave Howe
20-Aug-2013, 15:06
On 20/08/2013 11:42, Anders Gustafsson wrote:
> Dave Howe,
>> (and as far as I know, you can't restrict the GWTAPP token
>> to just a single mailbox, access is granted to all mailboxes)
>
> But being able to do so, say per group would be rather cool!

Yup. certain Other Systems are very granular - you can grant access down
to individual folders, calenders and so forth - however, GWTAPP was
clearly written as a backdoor for a trusted solution (even the name
suggests that) rather than a general purpose tool.

susecmail
16-Sep-2013, 02:42
Interesting conversation & I thought I'd add my two-cents to the topic:

I use Claws-email with the GPG plugins enabled. I avoid using ANY "free" email providor, especially if their company makes $10.74 billion in selling OUR information to whomever it wants; I had used Lavabit.com until the owners closed it due to NSA pressure. Sadly, it is now necessary to find an offshore (for those living in the U.S., that is) company that supports privacy & encrypted communication. After evaluating several, I ended up on Countermail.com.

Sadly, I do not encrypt hardly any of my email as most people I know do not use encryption. I have used One-Time-Encryption keys for emails as well as GPG/PGP for those users who employ that security.

Another sad, pathetic development for the Internet: http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security

The lessons I would take away from the conversation above and my post:

1. Do NOT rely on any encryption technology to store extremely sensitive data; do not store that data on any computer at any time, somebody somewhere will be able to get it;
2. Do NOT use "free" services without checking them out, first:
2a. I remember being a young lad when I was told that nothing in this life is free; everything comes with a cost; what's the cost for a free email provider? Loss of privacy? Ads?
2b. Do you trust the Linux developers up & downline of your distro? How many of us check the kernel anymore? I know I have not; has the NSA worked with Torvalds or any other major developers?
2c. For SUSE, from what repositories are you installing? Has Novell opted to put in a backdoor? Who develops that driver you just installed? etc.
3. If you do store data on your system, encrypt your hard drive with whole-disk-encryption; or, lacking that, encrypt your swap file & home directory.
4. Choose a good email program that supports encryption and privacy; many of them do; however, some are less effective than others.

It may all be a moot point, given that the NSA has a quantum computer available to them, even if it is "just" using their tech subsidiary, Google, Inc. :P And, the CIA program, Facebook, makes it easy to keep track of most people on the planet: Although this is tongue-in-cheek, PRISM proved it to be probably true: https://www.youtube.com/watch?v=cqggW08BWO0

Dave Howe
16-Sep-2013, 16:27
On 16/09/2013 15:27, susecmail wrote:
>
> Interesting conversation & I thought I'd add my two-cents to the topic:
>
> I use Claws-email with the GPG plugins enabled. I avoid using ANY
> "free" email providor, especially if their company makes $10.74 billion
> in selling OUR information to whomever it wants; I had used Lavabit.com
> until the owners closed it due to NSA pressure. Sadly, it is now
> necessary to find an offshore (for those living in the U.S., that is)
> company that supports privacy & encrypted communication. After
> evaluating several, I ended up on Countermail.com.
I tend to use enigmail - not because there is anything wrong with claws
(I even have it, it came with one of the pgp4win installs) but because I
find the feature-rich plugin community fills a lot of my other needs
(plus of course gpg users are the exception)

I also have a copy of https://www.quicksilvermail.net/ but of course I
don't use that for anything, honest :)


> Sadly, I do not encrypt hardly any of my email as most people I know do
> not use encryption. I have used One-Time-Encryption keys for emails as
> well as GPG/PGP for those users who employ that security.

That is a problem for me too. I can count on, ok, more than one hand,
but less than two, the number of people I know who have a secure key,
and of that, less than half would routinely encrypt their mails to me
(even in reply to a secure mail) unless I set up their enigmail for them
for secure-reply as a default :)

> Another sad, pathetic development for the Internet:
> http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security
>
> The lessons I would take away from the conversation above and my post:
>
> 1. Do NOT rely on any encryption technology to store extremely sensitive
> data; do not store that data on any computer at any time, somebody
> somewhere will be able to get it;

Some data really cries out for computer storage. One takeaway from the
snowden affair was that a physical airgap and encrypted exchange
(physical) media was acceptable to Snowden; I believe truecrypt was used
for the latter, but don't have a reliable source on that.


> 2. Do NOT use "free" services without checking them out, first:
> 2a. I remember being a young lad when I was told that nothing in
> this life is free; everything comes with a cost; what's the cost for a
> free email provider? Loss of privacy? Ads?

If you aren't paying, you *are* the product. Who are you being sold to.
Sadly, if you *are* paying, maybe they are getting paid twice.

> 2b. Do you trust the Linux developers up & downline of your distro?
> How many of us check the kernel anymore? I know I have not; has the NSA
> worked with Torvalds or any other major developers?

I would be surprised if they had, but you have to recall that the NSA's
own patches to the kernel are mainstream, so worth checking. That said
though, it would appear the NSA are more interested in compromising
binary installs of browsers and servers, mostly on the windows platform,
and can substitute downloaded installers "on the fly" for targets of
interest. And who is to say *everyone* isn't a target of interest?

> 2c. For SUSE, from what repositories are you installing? Has Novell
> opted to put in a backdoor? Who develops that driver you just
> installed? etc.

At some point, the paranoia has to get too much. It is worthwhile noting
that, even in the very earliest days of the unix project, a way was
found to booby trap compilers so that they would always compile in a
backdoor in certain executables (such as openssh) not present in the
source. They would *also* always compile in the above code if the
compiler is recompiled, and also the code to compromise the compiler (so
compiling the compiler multiple times would not remove it)

Usually, a compiler is compiled using a hand-coded and very inefficient
compiler. The resulting binary doesn't work fast, but does produce
efficient code (much better than the hand-coded compiler). The efficient
compiler is then recompiled with its inefficiently compiled self, to
produce an efficient compiler that runs efficiently. If that *first*
bootstrapping compiler, hand-coded in assembler for which no source code
is usually supplied, had the backdoor, no copy of the binaries for the
efficient compiler would ever exist without the backdoor, despite that
backdoor never, ever appearing in the source of the compiler.

obviously, what keeps me awake nights is a bit more complex than what
you worry at :)

> 3. If you do store data on your system, encrypt your hard drive with
> whole-disk-encryption; or, lacking that, encrypt your swap file & home
> directory.

Actually, the opposite.

If you store data, then ideally you want a read-only operating system
such as a boot cd, that has no networking support. You can then boot to
that os, mount the encrypted partition, decrypt (from the unencrypted
windows drive) encrypted inbound data, work on it within your secured
environment, then store encrypted outbound data on the windows partition
and reboot back into your untrusted os.

Now all you have to worry about is that the tpm/uefi bootstrap has some
code in it to compromise stored in memory keys after your secure
partition is mounted.


> 4. Choose a good email program that supports encryption and privacy;
> many of them do; however, some are less effective than others.

A good choice of key is crucial, but from statements made so far I am
reluctant to believe that the MS cryptographic core remains untainted,
and it is possible the openssl core is compromised too. Not sure WHAT
that leaves, given 95% of the crypto code out there is rooted in one or
the other of those.

> It may all be a moot point, given that the NSA has a quantum computer
> available to them, even if it is "just" using their tech subsidiary,
> Google, Inc. :P And, the CIA program, Facebook, makes it easy to keep
> track of most people on the planet: Although this is tongue-in-cheek,
> PRISM proved it to be probably true:
> https://www.youtube.com/watch?v=cqggW08BWO0

Quantum Cryptanalysis is overrated. Just as in theory you can break
symmetric keys by running "enough" processors in parallel, a QC has to
have sufficient qbits, in sufficient parallel probability fluxes, to
hold all possible states simultaneously - as I understand it, each of
those possible states must be powered, so at some point you are forcing
enough power into the solution that it will fuse atoms below iron. That
practical limit is thought to lie far below what we can already achieve
by brute force (although, it would be cool to have a RSA key broken
near-instantaneously rather than over months by a server farm the size
of a small town)

The new DWave approach, should it prove viable, may give a significant
improvement to the limit - DWave qbits are, as I understand it, much
less stable than classical QC qbits, so may (or may not) yield a correct
answer. However, it may be the case that sufficient runs of the QC,
tested using a conventional computer, might still find results for
larger keys in the EC/DSA space in a realistic timespan (days or weeks)
where conventional computing is likely to take centuries. Scientists are
alternatively enthusiastic and skeptical about DWave's claims though. So
it would be wise to remain on the fence. I have not seen any suggestion
that the factorization hard problem underlying RSA is likely to be
suitable for the DWave though, so as long as that is true, I am going to
use Schneier's own actions (of issuing a new gpg 4K key using trusted
code) as a guide for mine :)

susecmail
16-Sep-2013, 23:31
@David Howe

Yeah, I'm fairly paranoid, in general; I'm not afraid to admit that; however, my life experience has shown me to always consider the circumstances from every conceivable angle available to me at the time. I've been in some crazy life or death situations that have given me grey hairs ahead of my time :P.

I know that in actual practice, average users should fall somewhere between my take on life & the current laissez-faire attitude. Using a computer for data storage and computation (etc.), is a compromise. Also, I'm not sure I've ever heard of Shneier or what he (or she) advocates, I'll have to look that up, thank you.

Without getting into a lot of detail, I know for a fact that the technology the public sees today is 50 years or more behind where it actually is in development, generally speaking, of course. There are some amazing projects being developed that I wish I were able to take part in (well, at least when I was more aware of them...); there are other projects that would scare the heck out of any sane, rational human being.

From what I've seen, the OpenSSL core might very well be tainted; I hope it is not, but evidence seems to indicate otherwise.

If I remember correctly (and I may not, being a victim of an aneurysm rupture), the problem of compiling a "backdoor" into NIX base functionality crept back in to the Linux kernel around 2.6.14-ish; I cannot remember the two people who provided a white paper on how the 'ls' function could be compromised, both quickly and simply, due to security issues in that specific kernel release as a proof-of-concept report. Of course, the problem was quickly fixed; however, it demonstrated that continuous oversight and untiring vigilance should be SOP.

I used to meticulously track down and read through almost every package I installed on my systems back when there were not too many around; however, today, I blissfully trust Novell and other repository maintainers to update my machine without checking the code. I've observed all my friends doing the same, even those who were more meticulous than I was in the mid-1990's. I've come to the point where I do not trust my ability to maintain a level of system security to such a degree that somebody else could not get it. As a consequence, my taxes are hand prepared by an accountant and other extremely important documents are paper-based stored in fireproof, locked containers. While somebody may be able to access them, they would have to be physically at my location to do so.

As far as using a read-only OS not connected to the network & using a virtual environment, excellent recommendations! I have worked in one situation where that was necessary and several others where it ought to have been employed.

BTW, your name is not too common and I have a cousin who shares it with you :).

Dave Howe
17-Sep-2013, 09:47
On 16/09/2013 23:34, susecmail wrote:
>
> @David Howe
>
> Yeah, I'm fairly paranoid, in general; I'm not afraid to admit that;
> however, my life experience has shown me to always consider the
> circumstances from every conceivable angle available to me at the time.
> I've been in some crazy life or death situations that have given me grey
> hairs ahead of my time :P.

There is always an *appropriate* level of security awareness. If it is
paranoia is something that can only really be judged in the failure
(i.e. you were insufficiently careful) while a bit of overkill,
particularly in the crypto field, is usually little harder than a
just-good-enough solution.

> I know that in actual practice, average users should fall somewhere
> between my take on life & the current laissez-faire attitude. Using a
> computer for data storage and computation (etc.), is a compromise.

Indeed. Good tradecraft is to have different levels of protection for
different types of data. There is data that it is safe to use commercial
solutions (such as skype, decidedly porous to the NSA and MS themselves,
and stuff like cisco CRES) for, data that end to end crypto (such as pgp
or s/mime) for, though on an otherwise only normally secured computer,
data that a certain amount of paranoia is indicated for (see the prior
pseudo-airgap solution), and then data where the machine itself should
never, ever see a network of any type, stock live media be in use, and
removable media used as the interchange medium by trusted courier only.

Most people will never, ever get to the last step, journalists should
consider (at least these days) anything from confidential sources to
*require* the latter, if they ever want them to remain confidential.

> Also, I'm not sure I've ever heard of Shneier or what he (or she)
> advocates, I'll have to look that up, thank you.

https://www.schneier.com/crypto-gram.html

*fairly* well known :)


> Without getting into a lot of detail, I know for a fact that the
> technology the public sees today is 50 years or more behind where it
> actually is in development, generally speaking, of course. There are
> some amazing projects being developed that I wish I were able to take
> part in (well, at least when I was more aware of them...); there are
> other projects that would scare the heck out of any sane, rational human
> being.
>
> From what I've seen, the OpenSSL core might very well be tainted; I hope
> it is not, but evidence seems to indicate otherwise.

Yup. if it is though, its subtle. Of course, much of openssl implements
standards, and a clean implementation of a tainted standard is still
tainted.

> If I remember correctly (and I may not, being a victim of an aneurysm
> rupture), the problem of compiling a "backdoor" into NIX base
> functionality crept back in to the Linux kernel around 2.6.14-ish; I
> cannot remember the two people who provided a white paper on how the
> 'ls' function could be compromised, both quickly and simply, due to
> security issues in that specific kernel release as a proof-of-concept
> report. Of course, the problem was quickly fixed; however, it
> demonstrated that continuous oversight and untiring vigilance should be
> SOP.

http://cm.bell-labs.com/who/ken/trust.html

> BTW, your name is not too common and I have a cousin who shares it with
> you :).

Yeah. Luckily, the head honcho over at the syfy channel also shares it,
which has pushed most of my online presence off the first few pages of
google... except, oddly, for my linkedin account.

Dave Howe
17-Sep-2013, 10:21
On 17/09/2013 09:47, Dave Howe wrote:
> Yeah. Luckily, the head honcho over at the syfy channel also shares it,
> which has pushed most of my online presence off the first few pages of
> google... except, oddly, for my linkedin account.

Urk. I really, really need to either adopt a pseudonym or stop
pontificating so much on crypto. Now, how to reduce my google footprint?