NIST-free crypto, autociphering, and libsodium (NaCl)

classic Classic list List threaded Threaded
25 messages Options
12
MJ
Reply | Threaded
Open this post in threaded view
|

NIST-free crypto, autociphering, and libsodium (NaCl)

MJ
Hello,

I would like to inquire as to which OpenBSD RELEASE will offer the possibility
to avoid NIST crypto for everything in Base (isakmpd, openssh, openssl, https,
nginx being the key items in mind)?

BTW, looks like things are heading in the right direction
(http://www.slideshare.net/yandex/rubsd2013-mikeben)

As it stands, there is currently cipher-suite negotiation / configuration
coded into every single crypto-enabled tool / daemon and it’s a bit of a mess
and a headache to manage it all. Would it be good to start to think about
having a single, system-wide cipher-suite negotiation configuration and
socket? interface and removing all this mess from things like isakmpd,
openssh, openssl, httpd, nginx, etc? For example, one could specify a
preferred ordered list of cipher suites and ones that aren’t listed would be
completely avoided at the system level. This could, for example, eliminate
static algorithm configuration in ipsec.conf and instead start negotiation
traveling down the ordered list until either success or end of list. This
method would provide an abstract interface to avoid future version downgrade
attacks, i.e. no need to update anything other than the configuration file.

And, of course, the autocipher engine would be powered by libsodium (NaCl).

Thoughts, comments, insults, etc, are all welcome! The quantum computer is
coming soon to a theatre near you.


-mike

Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

Chris Cappuccio
MJ [[hidden email]] wrote:

> Hello,
>
> I would like to inquire as to which OpenBSD RELEASE will offer the possibility
> to avoid NIST crypto for everything in Base (isakmpd, openssh, openssl, https,
> nginx being the key items in mind)?
>
> BTW, looks like things are heading in the right direction
> (http://www.slideshare.net/yandex/rubsd2013-mikeben)
>
> And, of course, the autocipher engine would be powered by libsodium (NaCl).
>
> Thoughts, comments, insults, etc, are all welcome! The quantum computer is
> coming soon to a theatre near you.
>

For instance, you may have noticed that OpenSSH is moving towards an
openssl-free mode by importing NaCl components directly?

One problem with abandoning OpenSSL is that you lose SSL, TLS, (oh, and
everything has to be rewritten to use NaCl, and is now incompatible with
everything else.) So what you see with OpenSSH is the first attempt at
doing this, and it will only be compatible with other people also using
new OpenSSH.

The issue is compatbility.

MJ
Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

MJ
On 16 Jan 2014, at 18.23, Chris Cappuccio <[hidden email]> wrote:

> For instance, you may have noticed that OpenSSH is moving towards an
> openssl-free mode by importing NaCl components directly?
>
> One problem with abandoning OpenSSL is that you lose SSL, TLS, (oh, and
> everything has to be rewritten to use NaCl, and is now incompatible with
> everything else.) So what you see with OpenSSH is the first attempt at
> doing this, and it will only be compatible with other people also using
> new OpenSSH.
>
> The issue is compatbility.


Thanks Chris for your response and yes, you make a good point regarding compatibility.

I am by far a crypto expert, but these issues have been anyway on my mind as of late. So bear with me, but would it be possible to switch /dev/crypto to be an interface to an autocipher engine where both OpenSSL and NaCl ciphers could be supported via e.g. /etc/autocipher.conf and then change all crypto-enabled apps to use /dev/crypto and only /dev/crypto as the interface? This approach could highly simplify the crypto operations in all of the associated daemons/tools included in Base, as well Ports could slowly converted to use the same interface. This is precisely the approach that is being taken in Ethos operating system which is being designed from the ground up to withstand cryptographic attack. Given the current status quo (widespread compromise of our computing base by 3 letter agencies), this starts to sound a bit less paranoid of an approach.

Or have I got something wrong? Again, I am open to any sort of response.


-mike

MJ
Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

MJ
In reply to this post by Chris Cappuccio
On 16 Jan 2014, at 18.23, Chris Cappuccio <[hidden email]> wrote:

>
> For instance, you may have noticed that OpenSSH is moving towards an
> openssl-free mode by importing NaCl components directly?
>
> One problem with abandoning OpenSSL is that you lose SSL, TLS, (oh, and
> everything has to be rewritten to use NaCl, and is now incompatible with
> everything else.) So what you see with OpenSSH is the first attempt at
> doing this, and it will only be compatible with other people also using
> new OpenSSH.
>
> The issue is compatbility.

I’m sorry for the typo:

s/I am by far a crypto expert/I am far from being a crypto expert/

Thanks.

-mike

Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

Chris Cappuccio
In reply to this post by MJ
MJ [[hidden email]] wrote:
>
> Thanks Chris for your response and yes, you make a good point regarding compatibility.
>
> I am by far a crypto expert, but these issues have been anyway on my mind as of late. So bear with me, but would it be possible to switch /dev/crypto to be an interface to an autocipher engine where both OpenSSL and NaCl ciphers could be supported via e.g. /etc/autocipher.conf and then change all crypto-enabled apps to use /dev/crypto and only /dev/crypto as the interface? This approach could highly simplify the crypto operations in all of the associated daemons/tools included in Base, as well Ports could slowly converted to use the same interface. This is precisely the approach that is being taken in Ethos operating system which is being designed from the ground up to withstand cryptographic attack. Given the current status quo (widespread compromise of our computing base by 3 letter agencies), this starts to sound a bit less paranoid of an approach.
>
> Or have I got something wrong? Again, I am open to any sort of response.
>

OpenBSD has already began incorporating NaCl by bypassing OpenSSL entirely.

I can't speak for the architectural issues but I can't imagine that I or you
are the only people imagining better cipher suites in the base system.

MJ
Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

MJ
On 16 Jan 2014, at 19.17, Chris Cappuccio <[hidden email]> wrote:
> OpenBSD has already began incorporating NaCl by bypassing OpenSSL entirely.

Good news - perhaps my philosophy is “why lay a lot of small bricks here and there when you can lay a cornerstone and be done with it?”. But perhaps I am not taking all things into consideration.


> I can't speak for the architectural issues but I can't imagine that I or you
> are the only people imagining better cipher suites in the base system.

You are certainly right - that would be just naive. The OpenBSD approach to things is generally to make the interfaces as simple as possible, drop-dead simple. This eliminates configuration mistakes. Take OpenNTPD for example - it’s simply beautiful what has been done with the configuration interface.

A systemwide autocipher engine device could easily be incorporated directly in to PF, no? block all cipher hmac-sha1 (for example).

-mike

Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

Chris Cappuccio
MJ [[hidden email]] wrote:
>
> On 16 Jan 2014, at 19.17, Chris Cappuccio <[hidden email]> wrote:
> > OpenBSD has already began incorporating NaCl by bypassing OpenSSL entirely.
>
> Good news - perhaps my philosophy is ?why lay a lot of small bricks here and there when you can lay a cornerstone and be done with it??. But perhaps I am not taking all things into consideration.
>

OpenSSH is a project that gets used outside of OpenBSD so the way NaCl was
incorporated makes sense to me... It allows OpenSSH to evolve the SSH
standard with a minimum of fuss and contention.

How new crypto primitives get incorporated into the rest of the system
depends on how the people who work on those systems see things.

>
> > I can't speak for the architectural issues but I can't imagine that I or you
> > are the only people imagining better cipher suites in the base system.
>
> You are certainly right - that would be just naive. The OpenBSD approach to things is generally to make the interfaces as simple as possible, drop-dead simple. This eliminates configuration mistakes. Take OpenNTPD for example - it?s simply beautiful what has been done with the configuration interface.
>
> A systemwide autocipher engine device could easily be incorporated directly in to PF, no? block all cipher hmac-sha1 (for example).
>

Block traffic with specific ciphers from traversing the network? That's sci.fi

Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

Nicolai-8
In reply to this post by MJ
On Thu, Jan 16, 2014 at 01:24:09PM +0200, MJ wrote:
> Hello,
>
> I would like to inquire as to which OpenBSD RELEASE will offer the possibility
> to avoid NIST crypto for everything in Base (isakmpd, openssh, openssl, https,
> nginx being the key items in mind)?

Hi MJ,

Base must be interoperable with other systems of course, and for some
time that will require TLS unfortunately.  Aside from that though, the
upcoming OpenBSD release, 5.5, will be a landmark for strong crypto.

Look here for strings like "25519", "signify", and "chacha"

http://www.openbsd.org/plus.html

As for your point, there's a lot of interest in and support for NaCl.
For example, Curve25519 is now in a bunch of stuff like OpenSSH, Tor,
Chromium and DNSCurve.  Salsa20 and ChaCha20 are getting big.  It's
happening.  Now that people are more focused on using crypto that
actually protects them and their data/privacy, I think there may be a
"choice" looming where the IETF either adopts strong crypto, or people
move beyond such standards groups in favor of a bottom-up approach.
(This is already beginning to happen.)  I think certain standards groups
have become way too comfortable and don't serve a common good.

> Thoughts, comments, insults, etc, are all welcome!

Things are moving in the right direction!  The last six months have seen
MAJOR improvements in crypto.  If you want to be a part of it, pick up
DNSCrypt or DNSCurve.  Get a recent Chromium and play with QUIC.  Read
about MinimaLT.  Strong, fast encryption is coming.  And I think OpenBSD
5.5 will be light years ahead when it's released in May.

Nicolai

MJ
Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

MJ
In reply to this post by Chris Cappuccio
On 16 Jan 2014, at 20.24, Chris Cappuccio <[hidden email]> wrote:
>
> Block traffic with specific ciphers from traversing the network? That's sci.fi
>

You’re right again - this stuff is futuristic but could potentially be accomplished via inspection of unencrypted packet headers, etc (i.e. via packet-pattern/flow  analysis). However, it could likely be accomplished for things that access the machine itself.

We are getting into the realm of wirespeed DPI now. If we won’t be doing it, somebody else will. What are our efforts worth if the crypto exists in silos and is vulnerable to side channel attacks? Is it really worth delegating these sorts of things to ports?

Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

Chris Cappuccio
MJ [[hidden email]] wrote:

>
> On 16 Jan 2014, at 20.24, Chris Cappuccio <[hidden email]> wrote:
> >
> > Block traffic with specific ciphers from traversing the network? That's sci.fi
> >
>
> You?re right again - this stuff is futuristic but could potentially be accomplished via inspection of unencrypted packet headers, etc (i.e. via packet-pattern/flow  analysis). However, it could likely be accomplished for things that access the machine itself.
>
> We are getting into the realm of wirespeed DPI now. If we won?t be doing it, somebody else will. What are our efforts worth if the crypto exists in silos and is vulnerable to side channel attacks? Is it really worth delegating these sorts of things to ports?
>


This is just another area where someone has to have the interest
and the skill.

I don't think you'll ever see pf trying to filter out bad crypto.

On that note, Franco Fichtner has been doing some nice DPI work.

https://github.com/fichtner

Although you'll probably have to track him down and email him to get
some more current code.

Fichtner's work has been mated with Netmap more recently (which I started
porting to OpenBSD but never finished, it compiles...) and I bet it could
also be mated with divert-packet for performance (see
http://quigon.bsws.de/papers/2013/vbsdcon/mgp00044.html)

Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

Chris Cappuccio
In reply to this post by Nicolai-8
Nicolai [[hidden email]] wrote:

>
> As for your point, there's a lot of interest in and support for NaCl.
> For example, Curve25519 is now in a bunch of stuff like OpenSSH, Tor,
> Chromium and DNSCurve.  Salsa20 and ChaCha20 are getting big.  It's
> happening.  Now that people are more focused on using crypto that
> actually protects them and their data/privacy, I think there may be a
> "choice" looming where the IETF either adopts strong crypto, or people
> move beyond such standards groups in favor of a bottom-up approach.
> (This is already beginning to happen.)  I think certain standards groups
> have become way too comfortable and don't serve a common good.

All until we learn from the newest Snowden slide that Dan Bernstein is
actually on the NSA payroll :)

Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

Matthew Dempsky-3
In reply to this post by MJ
On Thu, Jan 16, 2014 at 9:01 AM, MJ <[hidden email]> wrote:
> So bear with me, but would it be possible to switch /dev/crypto to be an interface to an autocipher engine where both OpenSSL and NaCl ciphers could be supported via e.g. /etc/autocipher.conf and then change all crypto-enabled apps to use /dev/crypto and only /dev/crypto as the interface?

Moving to stronger safer crypto is a good goal, but framing the issue
as OpenSSL vs NaCl suggests you don't actually understand what either
of these libraries do.  I've also never heard of an "autocipher
engine" (Googling it only brings me back to this thread) and
standardizing on /dev/crypto as the interface would be terrible for
security, because it would force users to use type-unsafe ioctl() or
read()/write() commands.

Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

Christian Weisgerber
In reply to this post by MJ
MJ <[hidden email]> wrote:

> I would like to inquire as to which OpenBSD RELEASE will offer the possibility
> to avoid NIST crypto for everything in Base (isakmpd, openssh, openssl, https,
> nginx being the key items in mind)?

What is "NIST crypto"?

> As it stands, there is currently cipher-suite negotiation / configuration
> coded into every single crypto-enabled tool / daemon and it's a bit of a mess
> and a headache to manage it all.

Yeah, well, they all need to interoperate independently and speak
different protocols.

> Would it be good to start to think about having a single, system-wide
> cipher-suite negotiation configuration and socket?

Wäre es gut, wenn die ganze Welt eine Sprache sprechen würde?

--
Christian "naddy" Weisgerber                          [hidden email]

MJ
Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

MJ
In reply to this post by Nicolai-8
On 16 Jan 2014, at 20.49, Nicolai <[hidden email]> wrote:
>
> Things are moving in the right direction!  The last six months have seen
> MAJOR improvements in crypto.  If you want to be a part of it, pick up
> DNSCrypt or DNSCurve.  Get a recent Chromium and play with QUIC.  Read
> about MinimaLT.  Strong, fast encryption is coming.  And I think OpenBSD
> 5.5 will be light years ahead when it's released in May.


DNSCurve, I was already trying to compile it yesterday. Wonderful:


# ./configure.nacl

Took a long, long time to complete and didn’t produce any output at all.



# ./configure.curvedns
Finished configuring CurveDNS, ready for compiling.
Chosen/picked ABI:              x86
Chosen/picked compiler:         gcc
Chosen/picked compiler options: -m32 -O3 -fomit-frame-pointer -funroll-loops

We are now ready to compile, run 'make' to do so.

# make
gcc -m32 -O3 -fomit-frame-pointer -funroll-loops -Wall -fno-strict-aliasing
-O3 -Inacl/build/include/x86  -c curvedns-keygen.c
In file included from misc.h:49,
                 from curvedns-keygen.c:46:
ip.h:54:31: error: ev.h: No such file or directory
In file included from misc.h:49,
                 from curvedns-keygen.c:46:
ip.h:78: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'global_ip_internal_timeout'
ip.h:79: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'global_ip_tcp_external_timeout'
*** Error code 1

Stop in /usr/local/src/curvedns-0.87 (line 79 of Makefile).


Seems that it can’t even find headers in /usr/local/include, which is where
the OpenBSD pack for libev installs the header, so I had to add that:

# vim Makefile

# If you have libev at a non-standard place, specify that here:
EV=/usr/local
EVCFLAGS=-I$(EV)/include
EVLDFLAGS=-L$(EV)/lib


And then we get a bit further:

# make
gcc -m32 -O3 -fomit-frame-pointer -funroll-loops -Wall -fno-strict-aliasing
-O3 -Inacl/build/include/x86 -I/usr/local/include -c curvedns-keygen.c
gcc -m32 -O3 -fomit-frame-pointer -funroll-loops -Wall -fno-strict-aliasing
-O3 -Inacl/build/include/x86 -I/usr/local/include -c debug.c
gcc -m32 -O3 -fomit-frame-pointer -funroll-loops -Wall -fno-strict-aliasing
-O3 -Inacl/build/include/x86 -I/usr/local/include -c ip.c
gcc -m32 -O3 -fomit-frame-pointer -funroll-loops -Wall -fno-strict-aliasing
-O3 -Inacl/build/include/x86 -I/usr/local/include -c misc.c
misc.c: In function 'misc_base32_decode':
misc.c:291: error: 'EPROTO' undeclared (first use in this function)
misc.c:291: error: (Each undeclared identifier is reported only once
misc.c:291: error: for each function it appears in.)
*** Error code 1

Stop in /usr/local/src/curvedns-0.87 (line 76 of Makefile).



What’s this EPROTO and do I really need to care? I commented it out in misc.c,
dnscurve.c and dns.c:

PROTO:
    //errno = EPROTO;
    return 0;
}



And then:

# make
gcc -m32 -O3 -fomit-frame-pointer -funroll-loops -Wall -fno-strict-aliasing
-O3 -Inacl/build/include/x86 -I/usr/local/include -c dns.c
gcc -m32 -O3 -fomit-frame-pointer -funroll-loops -Wall -fno-strict-aliasing
-O3 -Inacl/build/include/x86 -I/usr/local/include -c curvedns.c
In file included from curvedns.c:37:
/usr/include/sys/socket.h:162: error: expected specifier-qualifier-list before
'u_int8_t'
/usr/include/sys/socket.h:180: error: expected specifier-qualifier-list before
'u_int8_t'
/usr/include/sys/socket.h:378: error: expected specifier-qualifier-list before
'socklen_t'
/usr/include/sys/socket.h:405: error: expected specifier-qualifier-list before
'socklen_t'
In file included from curvedns.c:37:
/usr/include/sys/socket.h:462: error: expected declaration specifiers or '...'
before 'socklen_t'
/usr/include/sys/socket.h:463: error: expected declaration specifiers or '...'
before 'socklen_t'
/usr/include/sys/socket.h:464: error: expected declaration specifiers or '...'
before 'socklen_t'
/usr/include/sys/socket.h:465: error: expected declaration specifiers or '...'
before 'uid_t'
/usr/include/sys/socket.h:465: error: expected declaration specifiers or '...'
before 'gid_t'
/usr/include/sys/socket.h:466: error: expected declaration specifiers or '...'
before 'socklen_t'
/usr/include/sys/socket.h:467: error: expected declaration specifiers or '...'
before 'socklen_t'
/usr/include/sys/socket.h:468: error: expected declaration specifiers or '...'
before 'socklen_t'
/usr/include/sys/socket.h:470: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'recv'
/usr/include/sys/socket.h:471: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'recvfrom'
/usr/include/sys/socket.h:472: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'recvmsg'
/usr/include/sys/socket.h:473: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'send'
/usr/include/sys/socket.h:474: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'sendto'
/usr/include/sys/socket.h:476: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'sendmsg'
/usr/include/sys/socket.h:477: error: expected declaration specifiers or '...'
before 'socklen_t'
curvedns.c: In function 'getenvoptions':
curvedns.c:75: error: 'struct sockaddr' has no member named 'sa_family'
curvedns.c:81: error: 'struct sockaddr' has no member named 'sa_family'
curvedns.c:81: error: 'struct sockaddr' has no member named 'sa_family'
curvedns.c: In function 'main':
curvedns.c:164: error: 'struct sockaddr' has no member named 'sa_family'
*** Error code 1

Stop in /usr/local/src/curvedns-0.87 (line 57 of Makefile).


So I added sys/types.h to curvedns.c:

#include <sys/types.h>
#include <sys/socket.h>     /* for AF_UNSPEC */



And voila, it compiles:

make
gcc -m32 -O3 -fomit-frame-pointer -funroll-loops -Wall -fno-strict-aliasing
-O3 -Inacl/build/include/x86 -I/usr/local/include -c curvedns.c
gcc -Lnacl/build/lib/x86 -L/usr/local/lib debug.o ip.o misc.o dnscurve.o dns.o
cache.a event.a curvedns.o -lev -lnacl -o curvedns


Don’t know how well it works just yet, but it compiles.


-mike

MJ
Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

MJ
In reply to this post by Chris Cappuccio
On 16 Jan 2014, at 23.55, Chris Cappuccio <[hidden email]> wrote:
>
> All until we learn from the newest Snowden slide that Dan Bernstein is
> actually on the NSA payroll :)
>

All your DJBs belong to us!

MJ
Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

MJ
In reply to this post by Christian Weisgerber
On 17 Jan 2014, at 00.54, Christian Weisgerber <[hidden email]> wrote:

> MJ <[hidden email]> wrote:
>
>> I would like to inquire as to which OpenBSD RELEASE will offer the possibility
>> to avoid NIST crypto for everything in Base (isakmpd, openssh, openssl, https,
>> nginx being the key items in mind)?
>
> What is "NIST crypto"?

Are you serious or just being facetious? I basically used it as an umbrella term to include all of the crypto in which the US government has had their hand involved in it’s specification, implementation, approval, standardisation, etc and so forth.

http://csrc.nist.gov/groups/ST/toolkit/index.html

Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

Philip Guenther-2
On Thu, Jan 16, 2014 at 7:12 PM, MJ <[hidden email]> wrote:

> On 17 Jan 2014, at 00.54, Christian Weisgerber <[hidden email]> wrote:
>
>> MJ <[hidden email]> wrote:
>>
>>> I would like to inquire as to which OpenBSD RELEASE will offer the possibility
>>> to avoid NIST crypto for everything in Base (isakmpd, openssh, openssl, https,
>>> nginx being the key items in mind)?
>>
>> What is "NIST crypto"?
>
> Are you serious or just being facetious?

He was serious, because "NIST crypto" has multiple definitions.


> I basically used it as an umbrella term to include all of the crypto in which the US government has had their hand involved in it’s specification, implementation, approval, standardisation, etc and so forth.

Ah, so if NIST looked at work done by someone completely unrelated to
NIST and said "looks good, we'll standardize exactly what you did",
you think that it's now contaminated by NISTs talking about it?  For
example, AES, which was designed by europeans and standardized after a
massively public competitive process that even the losing competitors
think was legit with no funny games, should be excluded by your
clarified criteria.  That sounds like you're interested in a political
statement and not a security goal.


As for your original question: let's imagine it could be done right
now with just a trivial build switch.  Poof, no more "NIST crypto"
(haha) for everything.  Sweet: you can no longer securely connect to
or from almost any non-OpenBSD box!  Practically no https:// website
would work for you.  Wow, that's so much more secure!  What problem
are you trying to solve?

A transition to new ciphers is like an API change: you have you get
mind share and acceptance, show people that new stuff still solves
their problem and that the change isn't insurmountable in time or
effort.  You push, but not so hard that you lose traction with the
larger community, because we're not just trying to make our own
systems more secure, but also everyone else's system.  Go listen
(again) to Theo's talk at yandex, where he talks about address space
mititgations including the ones that were too aggressive and had to be
backed out...
    http://tech.yandex.com/events/ruBSD/2013/talks/103/


Philip Guenther

Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

Christian Weisgerber
In reply to this post by MJ
MJ <[hidden email]> wrote:

> > What is "NIST crypto"?
>
> Are you serious or just being facetious? I basically used it as an
> umbrella term to include all of the crypto in which the US government
> has had their hand involved in it's specification, implementation,
> approval, standardisation, etc and so forth.

As guenther@ has pointed out, refusing all crypto covered by that
definition is silly.  But even if you limit yourself to the
specification part, you should be very disappointed about the newly
added Curve25519 key exchange and Ed25519 signing in OpenSSH, because
as implemented both rely on SHA-2 cryptographic hashes, which were
not only specified by NIST, but in fact designed by the NSA.

Of course mainstream cryptographers don't think that SHA-2 is
insecure, much less backdoored, but that again raises the question:
What do mean by that "NIST crypto" you want to avoid?

--
Christian "naddy" Weisgerber                          [hidden email]

MJ
Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

MJ
On 17 Jan 2014, at 17.30, Christian Weisgerber <[hidden email]> wrote:

>
> As guenther@ has pointed out, refusing all crypto covered by that
> definition is silly.  But even if you limit yourself to the
> specification part, you should be very disappointed about the newly
> added Curve25519 key exchange and Ed25519 signing in OpenSSH, because
> as implemented both rely on SHA-2 cryptographic hashes, which were
> not only specified by NIST, but in fact designed by the NSA.
>
> Of course mainstream cryptographers don't think that SHA-2 is
> insecure, much less backdoored, but that again raises the question:
> What do mean by that "NIST crypto" you want to avoid?
>
> --
> Christian "naddy" Weisgerber                          [hidden email]
>

Hi,

Consider for a moment the difference between objective thinking and objective feeling, then you might consider my point of view.

You are right, mere involvement has not tainted reality. But it has left me suspicious, and that’s something that needs to be satisfied. It’s a fuzzy logic, and it wasn’t enough to get me past the doorman in the Umverschämft.


-mike

Reply | Threaded
Open this post in threaded view
|

Re: NIST-free crypto, autociphering, and libsodium (NaCl)

LeviaComm Networks NOC
MJ wrote:

> On 17 Jan 2014, at 17.30, Christian Weisgerber <[hidden email]> wrote:
>>
>> As guenther@ has pointed out, refusing all crypto covered by that
>> definition is silly.  But even if you limit yourself to the
>> specification part, you should be very disappointed about the newly
>> added Curve25519 key exchange and Ed25519 signing in OpenSSH, because
>> as implemented both rely on SHA-2 cryptographic hashes, which were
>> not only specified by NIST, but in fact designed by the NSA.
>>
>> Of course mainstream cryptographers don't think that SHA-2 is
>> insecure, much less backdoored, but that again raises the question:
>> What do mean by that "NIST crypto" you want to avoid?
>>
>> --
>> Christian "naddy" Weisgerber                          [hidden email]
>>
>
> Hi,
>
> Consider for a moment the difference between objective thinking and
 > objective feeling, then you might consider my point of view.

That's called being emotional and isn't objective in the least.
paranoid != security conscious

> You are right, mere involvement has not tainted reality. But it has
> left me suspicious, and that’s something that needs to be satisfied.
 > It’s a fuzzy logic, and it wasn’t enough to get me past the doorman
> inthe Umverschämft.
>
> -mike
>

Since we have to use those ciphers anyway (to communicate with everyone
else on the internet not wearing a tin-foil hat), why don't we just
audit the code implementing those ciphers?  We have the source, so any
one versed in cryptography (I'm sure there are more than a few lurking
around here) can check it out.  This would help a lot more people than
just us.

-CMA

12