Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Michael Richardson]

Viktor Dukhovni <openssl-us...@dukhovni.org> wrote:
>> On Jan 24, 2018, at 9:27 AM, Michael Richardson <m...@sandelman.ca> 
wrote:
>>
>>> email clients are designed to handle hundreds to thousands of messages
>>> a day, Github UI isn't

> Indeed email is best for informal ad-hoc back and forth threaded
> discussion, while Github et. al. are for issue tracking.

> If there's a clear problem that requires tracking and resolution,
> then the right forum is Github.  If there's a topic to discuss,
> we have openssl-users.  Most openssl-dev threads were more
> appropriate for openssl-users.

I'm okay with taking more of the "what is the right answer" questions to
openssl-users if that's the plan.

I truly love github for many many things, but the email interface to issues
and pull requests has been a problem for me with projects like tcpdump.
I personally don't render HTML parts, and read 90% of my email via
emacsclient -nw.

Users reasonably post things. 60% are silly requests which a google search or
a "man foo" would resolve but it generates emails to the busiest people
only (the maintainers), skipping the other users on the list who *also* could
answer if they knew there was a well formed question.

Is there a stackexchange/serverfault?

I took to CC: tcpdump-workers when I answered github issues by email,
particularly when there was a question of project goals or policy involved.
I realized that there is a bit of a XSS/spam attack facilitated by doing that
as the magic reply-to address to get stuff posted to the github issue is now
happily archived in the ML!

Does github issue process the emails with useful quoting in them usefully? 
Sorta.
So, I'm skeptical, but I am willing to go with the plan.

--
]       Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Michael Richardson]

Hubert Kario  wrote:
> that marking a conversation as ignored and going to next one is two key
> combinations and less than a second, github ones require me to go to
> the web UI which is slow, and if I have to view the issue because
> subject is ambiguous it takes ten times as long as it does when using
> email

+1

> email clients are designed to handle hundreds to thousands of messages
> a day, Github UI isn't



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

[Michael Richardson]

Matt Caswell <m...@openssl.org> wrote:
> Please raise a separate PR for this work. It *must* be portable though
> and work across all our platforms (e.g. including VisualC etc). My
> suggestion is that your BIO_CTRL_DGRAM_GET_ADDR/BIO_CTRL_DGRAM_SET_ADDR
> ctrls should return an error on platforms that we don't know we can
> support, i.e. attempt to detect (at compile time) whether we are on a
> platform that we know has the required system calls - if we are then use
> them, otherwise we do things the old way.

> Note that stuff like this is problematic:

> char __attribute__((aligned(8))) chdr[CMSG_SPACE(sizeof(struct
> in_pktinfo))];

> The "attribute" is compiler specific and not something we can rely on to
> be available. Additionally "CMSG_SPACE" is probably not portable, and in
> any case may not evaluate to a compile time constant (according to the
> man page), so this is not C90 (which is a requirement for OpenSSL
> submissions).

Understood.
I think that CMSG_SPACE might be in the POSIX spec, but I'll double check.

What do you suggest I do for the IPv4 stuff, which has no POSIX standard?
A bunch of #ifdef on OS definitions?

> Once this PR is in (assuming it gets accepted), then you can look at
> what remains of your original PR and see if it makes sense to raise new
> PRs to bring the rest of it in.

Roger. Wilco.

--
]       Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

[Michael Richardson]

Matt Caswell <m...@openssl.org> wrote:
>> Matt Caswell <m...@openssl.org> wrote:
>> >> Matt Caswell <m...@openssl.org> wrote: >> a) when the existing FD is
>> >> connect(2) any future traffic to the bound >> port will get rejected
>> >> with no port.  So the application really has to >> open a new socket
>> >> first.  The application can do this two ways: it can >> open a new
>> >> socket on which to receive new connections, or it can open >> a new
>> >> socket on which to communicate with the new client.  The second >>
>> >> method is better for reason (b) below.  Either way, it socket to >>
>> >> communicate with the client needs to be bind(2) to the address that >>
>> >> the client used to communicate with the server, and DTLSv1_listen() >>
>> >> didn't collect or return that information.
>> >>
>> >> > The second way is what is intended.
>> >>
>> >> Unfortunately, there remains a race condition because we have to call
>> >> bind() before connect() on the new socket.  Under load, if a packet is
>> >> received between the bind() and the connect(), it might go onto the
>> >> wrong socket queue. So some packets that could have been processed
>> >> will get dropped and have to be retransmitted by the client.
>>
>> > This seems like a non-issue to me. At this point in the handshake the
>> > client will have sent its ClientHello and won't progress until it gets
>> > the server's flight back (ServerHello etc), i.e. in the vast majority
>> > of cases it won't be sending anything.
>>
>> *That* client will be waiting, but other clients may be sending new 
ClientHello
>> messages (with or without cookies).

> So how does your refactor solve this issue? AFAICT this also just does a
> bind then connect:

My refactor does not solve it. I'm noting that this is still an issue.

It's not solvable unless the kernel can do both operations at the same time,
for which there isn't a standard call (nor a non-standard one).
If we could punt segments between BIOs easily, then we could deal with the
problem, but I don't think it's worth solving.


> if(bind(rfd,BIO_ADDR_sockaddr(ouraddr),BIO_ADDR_sockaddr_size(ouraddr))
> != 0){
> +  goto end;
> +}
> +
> if(connect(rfd,BIO_ADDR_sockaddr(client),BIO_ADDR_sockaddr_size(client))
> != 0) {
> +  goto end;
> +}

> Doesn't this suffer from the same problem? i.e. packets could arrive
> from other clients between the bind and connect.

Yes.

This is in contrast this situation to the original problem with connect()'ing
the socket which is given to DTLSv1_listen(). That socket has lots of time
between the two points in which to accumulate new connection requests.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

[Michael Richardson]

Matt Caswell <m...@openssl.org> wrote:
>> Matt Caswell <m...@openssl.org> wrote: >> a) when the existing FD is
>> connect(2) any future traffic to the bound >> port will get rejected
>> with no port.  So the application really has to >> open a new socket
>> first.  The application can do this two ways: it can >> open a new
>> socket on which to receive new connections, or it can open >> a new
>> socket on which to communicate with the new client.  The second >>
>> method is better for reason (b) below.  Either way, it socket to >>
>> communicate with the client needs to be bind(2) to the address that >>
>> the client used to communicate with the server, and DTLSv1_listen() >>
>> didn't collect or return that information.
>>
>> > The second way is what is intended.
>>
>> Unfortunately, there remains a race condition because we have to call
>> bind() before connect() on the new socket.  Under load, if a packet is
>> received between the bind() and the connect(), it might go onto the
>> wrong socket queue. So some packets that could have been processed
>> will get dropped and have to be retransmitted by the client.

> This seems like a non-issue to me. At this point in the handshake the
> client will have sent its ClientHello and won't progress until it gets
> the server's flight back (ServerHello etc), i.e. in the vast majority
> of cases it won't be sending anything.

*That* client will be waiting, but other clients may be sending new ClientHello
messages (with or without cookies).

>> The address of the remote client is returned ("getpeername()") by
>> DTLSv1_listen().  That's all that recvfrom() gives you.
>>
>> recvfrom() was a reasonable API for SunOS 3.x machines with a single
>> 10Mb/s interface with a single IPv4 address.  I loved all that at the
>> time...  But it doesn't work that well when we might have a dozen
>> different kind of IPv6 addresses on each virtual interface.
>>
>> The address that I'm talking about needing is the one the remote
>> client used to reach us.  That's the destination IP of the incoming
>> packet ("getsockname()" in TCP speak).

> Ahhhits the *server's* address you are after. This requirement
> seems more reasonable. I think the API is designed to expect you to
> only bind to a single IP. I'd be interested in Richard Levitte's
> opinion on this.

okay.
binding to a single IP is not scalable in many applications.

> It seems like a fairly simple solution could solve this. Currently we
> have BIO_dgram_get_peer() which returns the peer's address for the last
> message read from a BIO. You could imagine a new call being introduced
> to get our own address. You could then call that immediately after a
> successful DTLSv1_listen() call. Obviously we'd have to change the
> dgram BIO to use recvmsg for this to work.

That's here:
   
https://github.com/mcr/openssl/commit/f764151782b4b32a752b4016336c0ceafa98ed5c
   
https://github.com/mcr/openssl/commit/50692219afe92762e85338b8d947e7ac732d2cde
and:   
https://github.com/mcr/openssl/commit/bb6f6b2cc860f25eb2b08aa109d1c7dc9ea94323


--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

[Michael Richardson]

Matt Caswell <m...@openssl.org> wrote:
>> a) when the existing FD is connect(2) any future traffic to the bound
>> port will get rejected with no port.  So the application really has to
>> open a new socket first.  The application can do this two ways: it can
>> open a new socket on which to receive new connections, or it can open
>> a new socket on which to communicate with the new client.  The second
>> method is better for reason (b) below.  Either way, it socket to
>> communicate with the client needs to be bind(2) to the address that
>> the client used to communicate with the server, and DTLSv1_listen()
>> didn't collect or return that information.

> The second way is what is intended.

Unfortunately, there remains a race condition because we have to call bind()
before connect() on the new socket.  Under load, if a packet is received
between the bind() and the connect(), it might go onto the wrong socket
queue. So some packets that could have been processed will get dropped and
have to be retransmitted by the client.

It could be solved if there was a way to punt packets received on the wrong
socket to the correct BIO on the input side.  I looked into this, but decided
it was too difficult...

That would also let one operate a multitude of DTLS connections using single
socket which might be a boon to some users.  Mis-designed it would scale
badly on multi-threaded machines and involve lots of ugly locks.
I don't want to consider the impacts if one had to pass packets between 
processes...
I don't advocate a solution like this (I'll live with the dropped packets),
but I think it's worth making people aware that they might see mis-directed
packets get dropped.

> Maybe I misunderstand your point -
> but the client address *is* returned? Admittedly its wrapped in a
> BIO_ADDR, but its easy to get the underlying "raw" address using
> BIO_ADDR_rawaddress():

> Why isn't recvfrom() suitable (which is what the code currently uses to
> get the address)?

The address of the remote client is returned ("getpeername()") by 
DTLSv1_listen().
That's all that recvfrom() gives you.

recvfrom() was a reasonable API for SunOS 3.x machines with a single 10Mb/s
interface with a single IPv4 address.  I loved all that at the time...
But it doesn't work that well when we might have a dozen different kind of
IPv6 addresses on each virtual interface.

The address that I'm talking about needing is the one the remote client used
to reach us.  That's the destination IP of the incoming packet ("getsockname()" 
in TCP speak).

With TCP this is never an issue because the kernel creates the new socket and
copies the right stuff in for us when it creates the socket.

With UDP, the source address for outgoing packets needs to match or the
client may get a response from an address that it didn't connect to.  Worse,
there might be firewalls or policy routing that would cause the packet to
disappear or get routed differently.  In my application, I definitely dealing
with connections over IPv6 Link-Local addresses with a multitude of virtual
links.

In your code example:
bind(client_fd, _addr, sizeof(struct sockaddr_in6));

server_addr has to be set from the destination address of the incoming
packet, it's not a global that the admin set, or the SIP negotiated.

In the bad old days, this meant opening a socket for every interface on the
machine, and re-reading the list of interfaces based upon some heuristic.
(routing socket, SIGHUP, ...)

Even getting a list of interfaces (and their addresses) is itself a
OS-dependant activity!  And, if you use the old BSD interface on Linux,
you'll miss a bunch of interfaces, because the Linux kernel people thought
that it would confuse BSD APIs if interfaces were returned that the BSD
interface didn't create.  So you can't even win there.

The IPv6 API gives us recvmsg() and ipi6_pktinfo, which makes it all sane.
But, we never got a standard interface for IPv4: Linux uses something that
looks identical to IPv6, and BSD has something with slightly different names.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

[Michael Richardson]

My preference is for (d), because I think that it's common code and the
application writer will get it wrong.  In particular, you need to open the
socket with SO_REUSEPORT in order to be allowed to bind() the new socket
before connect(2)ing it.  If there were a system call to do both at the same
time it would be better.  There is a race condition by calling bind() first,
because the kernel is likely to put new traffic from new sources into the
new socket.  They will be dropped as having the wrong cookies.

mattcaswell> * The code does not seem to be portable - it needs
mattcaswell> to work on all our platforms

mattcaswell> * There is no documentation

I will write more documentation when I am sure what the structure is going to 
be.

mattcaswell> I noticed a number of other things at a more specific level,
mattcaswell> just scanning through the code, but at this point I have not
mattcaswell> reviewed it in detail. I am not yet convinced there is a
mattcaswell> need for this.

I absolutely need to have recvmsg()/sendmsg() in the bss_dgram.c in order to
get the destination address used.   This IPv6 code is portable, since the RFC
API says how to do it.

The IPv4 code varies by OS; I can probably write the correct thing and get
tested it on FreeBSD, but I have no idea about Windows.  We used to solve
this by opening a socket for each interface and listening to the routing
socket, or having a human configure an explicit list of interfaces, or just
failing on multi-homed hosts.

I propose to split this pull request up into one that deals with the changes
to the BIO layer only.
A second pull request will include the "duplicate" BIO functionality.

A third then deals with the d1_lib.c layer.



--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] DTLS "accept" functionality

[Michael Richardson]

I have been working since mid-November in my "copious spare time" to bring
DTLS support into ruby-openssl in order to bring DTLS into the Rails "David"
CoAP server.

DTLS_listen() seems entirely focused on single-use situations like in RTP,
where only a single connection (single DTLS session) is expected. If used
in CoAP situation, there are a number of race conditions that make it
hard to use correctly.   I wrote another email about that, which I think did
not get to the list, which I can resend.

I have preserved DLTSv1_listen() functionality, refactoring most of it
into DTLSv1_anwerHello(), and then adding DTLSv1_accept() on top of it.

Unfortunately I was also forced to delve into dgram_bss.c in order to bring
some additional information out; stuff which is rather OS dependant for IPv4,
and which perhaps would be better done in the application somehow.

I'm looking for advice.

Also, I found it difficult to find the right incantation to get a static
build; I noticed finally that my test/* programs were linking against the
libssl that was in my /lib, rather than the code I was testing.  I suggest
that this be captured into a ./Configure option.  I used:

 ./Configure no-shared --debug linux-x86_64

"no-dso" seemed like it ought to help, but it made things worse...

I hope that I added the new exposed symbols correctly.
I have yet to validate the complete david/coap/ruby-openssl/dtls
functionality, but I wanted to post this sooner for review.


https://github.com/openssl/openssl/pull/5024 says:

This patch refactors the DTLSv1_listen() to create an alternative API that is
called DTLSv1_accept().

DTLSv1_accept() is useable by programs that need to treat DTLS interfaces in
a way similar to TCP: new connections must be accepted, and new sockets
created.

There are a number of changes included here:

1. dgram_write() and dgram_read() now use sendmsg(2) and recvmsg(2) in order to 
set and collect the local address used in the datagram.  This allows a socket 
to bound to ::, while still sending traffic correctly from the address that the 
other peer used. The IPv6 version of this code is according to rfc3542 API, but 
the IPv4 of the code is Linux specific and needs to be either abstracted and 
translated for *BSD and Windows, or IPv6 mapped IPv4 sockets could be used.
2. a new BIO control SET_ADDR and GET_ADDR are added, and if the address is not 
set then it pulls it out of the socket using getsockname(2).
3. DTLSv1_accept() accepts a second SSL* on which new connections are setup. A 
new socket is set up using the addresses from the received message and it is 
inserted into the BIO. There is a race condition during setup which turned out 
to be unavoidable: between the bind(2) and the connect(2), the new socket could 
have the same address as the "listen" socket, and additional hello packets 
could arrive on the wrong socket.  Such packets will hopefully be dropped as 
garbage. It was thought that connect(2) could be called before bind(2), but 
that seems to cause the kernel to allocate a local address for the new socket 
(a random port), which the subsequent bind(2) can not seem to change.
4. the use of POSIX socket APIs inside this code is likely inappropriate and 
this routine should be split up in some better way so that socket activities 
can be done by the application, using the correct abstractions for the OS.
5. a new test case dtlsaccepttest was created.  It uses fork() and also calls 
system() on "openssl s_client". Probably it should just call code internally, 
but apps/* is not in a library form that can be used. Perhaps this use is 
acceptable.  Other test functions just use canned packets in/out, but since 
this is testing the creation/adaption of socket code, real sockets would seem 
to be necessary.  Probably this test case should be disabled on non-Unix 
platforms.
6. routines BIO_ADDR_sockaddr and BIO_ADDR_sockaddr_size exposed from libcrypto 
to libssl.  There might be a better way to do this, perhaps a BIO_CTRL would be 
better?



--
]   Never tell me the odds!     | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] weird loop in s3_lib.c

[Michael Richardson]

Michael Richardson <m...@sandelman.ca> wrote:
> in
> const SSL_CIPHER *ssl3_choose_cipher(SSL *s, STACK_OF(SSL_CIPHER) *clnt,
> STACK_OF(SSL_CIPHER) *srvr)

never mind.
I mis-read the brackets.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] weird loop in s3_lib.c

[Michael Richardson]

in
const SSL_CIPHER *ssl3_choose_cipher(SSL *s, STACK_OF(SSL_CIPHER) *clnt,
 STACK_OF(SSL_CIPHER) *srvr)


we have:

for (i = 0; i < sk_SSL_CIPHER_num(prio); i++) {
c = sk_SSL_CIPHER_value(prio, i);
...

if (!ok)
continue;
}


The if (!ok) continue;
is just a no-op.  Maybe it said at some point:
  "if(ok) break;"

which would have an affect, or maybe there was some code after it that was
removed.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

AES and difference between engine and not

[Michael Richardson]

-BEGIN PGP SIGNED MESSAGE-


  I would have thought that this would be a FAQ.
  It is not. What is the engine?

  I was however, specifically trying to determine if anyone
has started any work on having an AES integrated into openssl.
  http://www.mail-archive.com/openssl-dev@openssl.org/msg10670.html

  suggests that it will be in the 0.9.7 release?

  (I am asking with my FreeSWAN and tcpdump hat on. We need to
have AES support in print-esp.c before we bother coding it
for FreeSWAN)

]   ON HUMILITY: to err is human. To moo, bovine.   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic(Just another NetBSD/notebook using, kernel hacking, security guy);  [

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBPGrcj4qHRg3pndX9AQExiQQAiGYocFsrZCVKxBDO1Du/qlVwb9YHiX3B
uSAskA7SMQtQ9v/8K2atLeDCP5i95QwLFFb8b3elHUKx8h+xIk0B9/949TCi/YTq
o7GQisSxBw/s+b/x6WxFi7nTCNO47xP70BY+v0yUGWN9fe6Pven6xVOvxsXKlgVu
vruKfDgmK1c=
=VRRZ
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [Design] changes to des.h

[Michael Richardson]

-BEGIN PGP SIGNED MESSAGE-


 Bodo == Bodo Moeller [EMAIL PROTECTED] writes:
Bodo Actually a change similar to what you proposed above was done in the
Bodo development version of OpenSSL (0.9.7-dev, snapshots available at
Bodo URL: ftp://ftp.openssl.org/snapshot;type=d), except that
Bodo des_key_schedule is now the actual struct and not a pointer to the
Bodo struct.

  Excellent!

Bodo (which is still valid for variable definitions) then 'ks' will not
Bodo automatically replaced by an appropriate pointer and you have to use
Bodo 'ks' in function calls.  If I remember correctly, I was the only one
Bodo worried about this though.  (Apart from transition difficulties, the
Bodo new scheme surely is less confusing.)

  And, compilers will complain nicely about this.

]   ON HUMILITY: to err is human. To moo, bovine.   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic(Just another NetBSD/notebook using, kernel hacking, security guy);  [

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBO9mlhIqHRg3pndX9AQHZkQQAqADrYp5RBekvI60Hg5mBZ8GUZw51+qhz
e5rTeB8nOYVNLc9yRdi1oeBXdsCsF27G30Lf3xqXiyODARYbR95LoOX93ZI8fO7j
/8ZuBZQEWiV7897zKKGpdnghKma2uQiZxGfAXoEovTZf/Cmpx9MNpk1kSpp/szkc
pQoC6LNVFjU=
=xkfO
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

print-esp.c gcc 2.95

[Michael Richardson]

-BEGIN PGP SIGNED MESSAGE-


  I ran into a problem in print-esp.c.

  To see, 

http://cvs.tcpdump.org/cgi-bin/cvsweb/tcpdump/print-esp.c?rev=1.19.2.3

  I had to add:

/* keep secret out of a register */
p = (u_char *)secret;

  because after the second call to des_set_key(), secret was trashed.
At first I thought this was because something was trashing the memory. After
some tracing, I since realized that it was the pointer itself that was being
trashed. It was in a register. des_set_key() uses lots of registers.
  
  I am using Debian 2.2 (Potato) on i386. I have:

cassidy:/home/mcr/src/linux/i386/tcpdump# dpkg -l | grep gcc
ii  gcc2.95.2-13  The GNU C compiler.

  I am building against: 
OpenSSL 0.9.6 24 Sep 2000

  In order to debug easier, I linked in libcrypto.a statically after adding -g 
to the CFLAGS in the toplevel.

  I then tried openssl 0.9.6b, and it worked fine without the above hack.

  I have looked around openssl.org, but the changelog doesn't seem to say
anything about problems against gcc-2.95.

  It worked fine on NetBSD/i386 with the 1.5.2 openssl. I'm not clear, but 
openssl/opensslv.h seems to suggest that NetBSD has 0.9.5a. (and: gcc version
egcs-2.91.66).

]   ON HUMILITY: to err is human. To moo, bovine.   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic(Just another NetBSD/notebook using, kernel hacking, security guy);  [

  
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBO9TMZ4qHRg3pndX9AQHAiwP+KcxAidt7SpIw1yyt2Cw0i1MD4vZlUPQz
ULH/xK4mBQa2/CUs8c1mQXRfCyvML18O30G6IHIPhG1e4yqf5dkIevDu81BwixB4
zZ4y4l3tzH/rzRuU6fDGiwmxCQ8KhGnWH4unYnqKvatyvT6fXZbJk5/CTAfWBo5x
8RyE0jn/24c=
=S1Ow
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

changes to des.h

[Michael Richardson]

-BEGIN PGP SIGNED MESSAGE-


  I'm in the process of cleaning up some of the FreeSWAN IPsec kernel code.
  I'm CC'ing Eric because he may still care, and openssl-dev since I suspect
that they are the current maintainers of the code.

  Specifically dealing with testing of various pieces of code. I was looking
around our key scheduling code, and the related error checking.

  One piece of code that bothered me was in our key scheduling
(freeswan-1.91, klips/net/ipsec/pfkey_v2_parser.c, line 1106)

error = des_set_key((caddr_t)ekp + EMT_ESPDES_KEY_SZ * i,
(caddr_t)((struct des_eks*)(tdbp-tdb_key_e))[i]);

  I wondered why we were casting to caddr_t, and why in the world we didn't
include des.h to get a proper prototype (we had a local prototype), and why
do we define struct des_eks instead of using des_key_schedule.
  [Our des.h is:  Copyright (C) 1995-1997 Eric Young ([EMAIL PROTECTED]),
although it appears the same in a recent openssl as found in NetBSD source]
 
  I've since understood.

  des_key_schedule is a pointer. 
  Despite the typedef at the top of des.h, it is in fact a pointer.
  So, one can't really really cast the tdb_key_e (which is the algorithm
neutral pointer to the keying material) to des_key_schedule *, and access
the three pieces of the 3DES key. 
  Thus struct des_eks that we created that was in fact a char[16][2].
  
  My suggestion:

change the typedef, (or probably, add a new one):

  struct des_ks_struct
{
union   {
des_cblock _;
/* make sure things are correct size on machines with
 * 8 byte longs */
DES_LONG pad[2];
} ks[16];
};

  typedef struct des_ks_struct * des_key_schedule;

  Our copy also has this ghastly:

#undef _
#define _   ks._

  which I see is gone from a more recent des.h.

  This let us include des.h and use struct des_ks_struct as our object.
  
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBO84ziIqHRg3pndX9AQFsPwQAno6Onn6ollkSOl3BDMK9lP/5Gc2MhdEx
iNvVHM4h5BWmtqlcHVlXe9Kmwk9xwX7VePZtnIesBoL+qCg0aiV0A3mFFY29mXYW
DkUaG024VeSkdGQuyhNRO6CIPWIVNo1mrNVgtaTjmfca1I2kjLfUULsvlom9nfVW
z8Vo7HZQiXM=
=zLS8
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [Design] changes to des.h

[Michael Richardson]

-BEGIN PGP SIGNED MESSAGE-


 Michael == Michael Richardson [EMAIL PROTECTED] writes:
Michael   My suggestion:

Michael change the typedef, (or probably, add a new one):

Michael   struct des_ks_struct
Michael{
Michaelunion   {
Michaeldes_cblock _;
Michael/* make sure things are correct size on machines with
Michael * 8 byte longs */
MichaelDES_LONG pad[2];
Michael} ks[16];
Michael};

Michael   typedef struct des_ks_struct * des_key_schedule;

  I see the error of my ways.

  des_key_schedule gets to be a nice chameleon.
  If declared as an auto/static, its gets storage like a structure.
  If declared in a parameter list, it gets treated like a pointer. This is
the nature of arrays in C. (And before structure passing, this was the case
for structures as well)

  The above breaks lots of programs.
  The problem is that one can't cast a pointer to a des_key_schedule
(as it was defined before) because that is an array type, not a pointer to an
array. So, one needs at a minimum:

struct des_eks {
  des_key_schedule ks;
};

  so that one can do ((struct des_eks *)foo)-ks to get the right type to
satisfy the prototype.

]   ON HUMILITY: to err is human. To moo, bovine.   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic(Just another NetBSD/notebook using, kernel hacking, security guy);  [

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBO84/04qHRg3pndX9AQHfPQQA5b9VQhsmCjX6rqiG43WNO5IRqBfvk7cA
mBUab6p7DQPG+390HO7ULMNskb4F7cVBocMYZe/e7ErczA81UbNN8U6ty21tC1td
tHqAQprx2N1767fNeLv5Ro0bx7gIqWgsFTlKRNuxmUduwcwI9GTwSbgFDeY/lMbW
2xH5vlwfB50=
=6o0U
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]