From: Liam O'Toole
> That sounds worrying. Could you elaborate, or provide a citation?
Remember this?
http://nakedsecurity.sophos.com/2013/12/09/serious-security-google-finds-fake-but-trusted-ssl-certificates-for-its-domains-made-in-france/
The whole SSL certificates system is not to be trusted
On 1/9/2014 15:52, m.r...@5-cent.us wrote:
> Robert Moskowitz wrote:
>>
>> Only algorithm they compromised was an RNG that got pretty strong thumbs
>> down from the real cryptographers. They have not compromised any IETF
>> standard;
>
> Not quite - anyone mandated to POSIX standards are effective
On 01/09/2014 02:52 PM, m.r...@5-cent.us wrote:
> Not quite - anyone mandated to POSIX standards are effectively mandated to
> use the compromised algorithms, as I understand it.
That's news to me. Citation?
Recently, there was a discussion amongst BSD devs and they concluded
that they don't tru
On Thu, January 9, 2014 17:52, m.r...@5-cent.us wrote:
> Robert Moskowitz wrote:
>>
>> On 01/09/2014 05:28 PM, John R Pierce wrote:
>>> On 1/9/2014 2:20 PM, Eero Volotinen wrote:
It might be easier to compromise security of commercial products as
source code is not available. they seem t
On 01/10/2014 09:22 AM, Liam O'Toole wrote:
> On 2014-01-09, Robert Moskowitz wrote:
>
> (...)
>
>> You want to talk about leaky code? Look how corporate mail proxies work
>> to enable them to read encrypted emails. Simple lying about certs.
> That sounds worrying. Could you elaborate, or provi
On 2014-01-09, Robert Moskowitz wrote:
(...)
> You want to talk about leaky code? Look how corporate mail proxies work
> to enable them to read encrypted emails. Simple lying about certs.
That sounds worrying. Could you elaborate, or provide a citation?
--
Liam
_
On 01/09/2014 06:33 PM, Cliff Pratt wrote:
> I was shocked and horrified to find out that RHEL (and presumably CentOS)
> and Ubuntu no longer implement the 'rot13' program.
But they implement the NULL cipher as part of IPsec.
>
> Cheers,
>
> Cliff
>
>
> On Fri, Jan 10, 2014 at 11:32 AM, Robert M
Thanks! I got similar suggestions when I mentioned this at work. I was of
course joking about rot13.
Cheers,
Cliff
On Fri, Jan 10, 2014 at 12:41 PM, John R Pierce wrote:
> On 1/9/2014 3:33 PM, Cliff Pratt wrote:
> > I was shocked and horrified to find out that RHEL (and presumably CentOS)
> >
On 1/9/2014 3:33 PM, Cliff Pratt wrote:
> I was shocked and horrified to find out that RHEL (and presumably CentOS)
> and Ubuntu no longer implement the 'rot13' program.
tr A-Za-z N-ZA-Mn-za-m outfile
example...
$ echo this is a message | tr A-Za-z N-ZA-Mn-za-m
guvf vf n zrffntr
$ echo guvf
I was shocked and horrified to find out that RHEL (and presumably CentOS)
and Ubuntu no longer implement the 'rot13' program.
Cheers,
Cliff
On Fri, Jan 10, 2014 at 11:32 AM, Robert Moskowitz wrote:
>
> On 01/09/2014 05:15 PM, Les Mikesell wrote:
> > On Thu, Jan 9, 2014 at 3:55 PM, John R Pierc
On 01/09/2014 05:37 PM, Les Mikesell wrote:
> On Thu, Jan 9, 2014 at 4:32 PM, Robert Moskowitz wrote:
>>> I always just assumed that blowfish was good precisely because it
>>> wasn't the one that was recommended/promoted by the groups likely to
>>> be compromised. But, I try to stay out of polit
Robert Moskowitz wrote:
>
> On 01/09/2014 05:28 PM, John R Pierce wrote:
>> On 1/9/2014 2:20 PM, Eero Volotinen wrote:
>>> It might be easier to compromise security of commercial products as
>>> source code is not available. they seem to have succeeded in compromising
STANDARDS and ALGORITHMS,
On Thu, Jan 9, 2014 at 4:32 PM, Robert Moskowitz wrote:
>
>> I always just assumed that blowfish was good precisely because it
>> wasn't the one that was recommended/promoted by the groups likely to
>> be compromised. But, I try to stay out of politics so I don't worry
>> much about keeping secr
On 01/09/2014 05:28 PM, John R Pierce wrote:
> On 1/9/2014 2:20 PM, Eero Volotinen wrote:
>> It might be easier to compromise security of commercial products as source
>> code is not available.
> they seem to have succeeded in compromising STANDARDS and ALGORITHMS, to
> heck with implementations.
Robert Moskowitz wrote:
>
> On 01/09/2014 05:15 PM, Les Mikesell wrote:
>> On Thu, Jan 9, 2014 at 3:55 PM, John R Pierce
>> wrote:
>>> On 1/9/2014 1:27 PM, Kanwar Ranbir Sandhu wrote:
I think everyone should assume the entire ecosystem is compromised and
shouldn't trust anything. Code s
On 01/09/2014 05:20 PM, Eero Volotinen wrote:
> I always just assumed that blowfish was good precisely because it
>> wasn't the one that was recommended/promoted by the groups likely to
>> be compromised. But, I try to stay out of politics so I don't worry
>> much about keeping secrets anyway.
>
On 01/09/2014 05:15 PM, Les Mikesell wrote:
> On Thu, Jan 9, 2014 at 3:55 PM, John R Pierce wrote:
>> On 1/9/2014 1:27 PM, Kanwar Ranbir Sandhu wrote:
>>> I think everyone should assume the entire ecosystem is compromised and
>>> shouldn't trust anything. Code should be reviewed and bugs/weaknes
On 01/09/2014 04:55 PM, John R Pierce wrote:
> On 1/9/2014 1:27 PM, Kanwar Ranbir Sandhu wrote:
>> I think everyone should assume the entire ecosystem is compromised and
>> shouldn't trust anything. Code should be reviewed and bugs/weaknesses
>> removed IMMEDIATELY. The problem is obviously not
On 1/9/2014 2:20 PM, Eero Volotinen wrote:
> It might be easier to compromise security of commercial products as source
> code is not available.
they seem to have succeeded in compromising STANDARDS and ALGORITHMS, to
heck with implementations.
--
john r pierce
I always just assumed that blowfish was good precisely because it
> wasn't the one that was recommended/promoted by the groups likely to
> be compromised. But, I try to stay out of politics so I don't worry
> much about keeping secrets anyway.
>
>
It might be easier to compromise security of comm
On Thu, Jan 9, 2014 at 3:55 PM, John R Pierce wrote:
> On 1/9/2014 1:27 PM, Kanwar Ranbir Sandhu wrote:
>> I think everyone should assume the entire ecosystem is compromised and
>> shouldn't trust anything. Code should be reviewed and bugs/weaknesses
>> removed IMMEDIATELY. The problem is obviou
On 1/9/2014 1:27 PM, Kanwar Ranbir Sandhu wrote:
> I think everyone should assume the entire ecosystem is compromised and
> shouldn't trust anything. Code should be reviewed and bugs/weaknesses
> removed IMMEDIATELY. The problem is obviously not everyone is a
> programmer and not everyone will ha
On Thu, Jan 9, 2014 at 3:27 PM, Kanwar Ranbir Sandhu
wrote:
>>
> We can't trust the software or the hardware any longer. When the
> problem runs this deep, what can anyone do? The NSA program has
> effectively removed my trust with every single U.S. (actually, 5 eyes)
> based tech company.
>
> I
On 2014-01-06 11:28, James B. Byrne wrote:
> I believe that the issue is of pressing interest to the entire
> community and I
> would like to read what others have to say on the matter.
I think everyone should assume the entire ecosystem is compromised and
shouldn't trust anything. Code should
On Tue, Jan 7, 2014 at 9:55 AM, Giles Coochey wrote:
> Can we trust the bios?
Can we trust the compiler not to stealthily inject a backdoor in the
compiled version of a clean code?Given that most entries from the The
International Obfuscated C Code Contest (http://www.iocc
On 07/01/2014 15:55, Giles Coochey wrote:
On 07/01/2014 15:52, Steve Clark wrote:
On 01/07/2014 09:04 AM, m.r...@5-cent.us wrote:
John Doe wrote:
After all the news about backdoors, "planted" bugs or weakened
standards
in apps, in routers, hardware firmwares, etc... these days, can we
trust
On 07/01/2014 15:52, Steve Clark wrote:
On 01/07/2014 09:04 AM, m.r...@5-cent.us wrote:
John Doe wrote:
After all the news about backdoors, "planted" bugs or weakened standards
in apps, in routers, hardware firmwares, etc... these days, can we trust
anything?
Can we trust the bios?
Can we trus
On 01/07/2014 09:04 AM, m.r...@5-cent.us wrote:
> John Doe wrote:
>> After all the news about backdoors, "planted" bugs or weakened standards
>> in apps, in routers, hardware firmwares, etc... these days, can we trust
>> anything?
>> Can we trust the bios?
>>
>> Can we trust the compiler not to ste
Just audit the source code...
7.1.2014 16.42 kirjoitti "Steve Clark" :
> What about selinux - wasn't that originally done by the NSA?
>
> On 01/07/2014 09:04 AM, m.r...@5-cent.us wrote:
> > John Doe wrote:
> >> After all the news about backdoors, "planted" bugs or weakened standards
> >> in apps,
What about selinux - wasn't that originally done by the NSA?
On 01/07/2014 09:04 AM, m.r...@5-cent.us wrote:
> John Doe wrote:
>> After all the news about backdoors, "planted" bugs or weakened standards
>> in apps, in routers, hardware firmwares, etc... these days, can we trust
>> anything?
>> Can
On Mon, January 6, 2014 16:51, m.r...@5-cent.us wrote:
>
> Looks like it's rtrying to install it, not just build it. In the first
> example, you're trying to replace the existing /usr/bin/strip, which only
> root can do. Are you doing make, or make install?
>
I started out by using the openssl.s
John Doe wrote:
> After all the news about backdoors, "planted" bugs or weakened standards
> in apps, in routers, hardware firmwares, etc... these days, can we trust
> anything?
> Can we trust the bios?
>
> Can we trust the compiler not to stealthily inject a backdoor in the
> compiled version of a
After all the news about backdoors, "planted" bugs or weakened standards in
apps, in routers, hardware firmwares, etc... these days, can we trust anything?
Can we trust the bios?
Can we trust the compiler not to stealthily inject a backdoor in the compiled
version of a clean code?Given that most
James B. Byrne wrote:
> I am doing a bit of investigative work to see just how hard it is to build
> openssl for myself. The source from openssl.org is readily available and
> the
> spec file provided seems fairly usable. However, I am seeing lots of
> errors
> similar to this when I try to build
I am doing a bit of investigative work to see just how hard it is to build
openssl for myself. The source from openssl.org is readily available and the
spec file provided seems fairly usable. However, I am seeing lots of errors
similar to this when I try to build it using mock:
+ /usr/lib/rpm/red
Eero Volotinen wrote:
> Um, I guess you haven't read the news lately - the most used,
>> POSIX-mandated elliptic curve is backdoored by the US NSA - when the
>>
>
> Well, as you know backdoored EC Dual DBRG is not working at all on
> openssl:
> http://marc.info/?l=openssl-announce&m=138747119822324
Um, I guess you haven't read the news lately - the most used,
> POSIX-mandated elliptic curve is backdoored by the US NSA - when the
>
Well, as you know backdoored EC Dual DBRG is not working at all on openssl:
http://marc.info/?l=openssl-announce&m=138747119822324
--
Eero
___
Eero Volotinen wrote:
> mark wrote:
> I agree, but I just don't know how much in the way of manhours that would
>> involved.
>>
>> However, if you do get it all built, and build packages out of them,
>> there is an extras? contribs? repo, and I'd encourage you to submit it for
>> that.
>
> RHEL now
> RHEL nowdays supports already Elliptic Curve on openssl.
Which complete misses the point.
First, the initial settings of the EC are significant in determining the
strength of the resulting cipher. There is considerable evidence that
suggests that some of these default settings have been propo
I agree, but I just don't know how much in the way of manhours that would
> involved.
>
> However, if you do get it all built, and build packages out of them, there
> is an extras? contribs? repo, and I'd encourage you to submit it for that.
>
RHEL nowdays supports already Elliptic Curve on openss
James B. Byrne wrote:
> Recently I have been deeply troubled by evidence revealing the degree to
> which U.S. based corporations (well actually all resident in any of the
> so-called 5-eyes countries) appear to have rolled over and assumed the
position with
> respect to NSA inspired pressure to cri
Recently I have been deeply troubled by evidence revealing the degree to which
U.S. based corporations (well actually all resident in any of the so-called
5-eyes countries) appear to have rolled over and assumed the position with
respect to NSA inspired pressure to cripple public key encryption and
42 matches
Mail list logo
