[Cryptography] Langsec & authentication

Judson Lester nyarly at gmail.com
Tue May 27 14:20:52 EDT 2014


>From the responses, it's clear that I touched the wrong nerves in what
I was asking. A shell based config file would serve as a good example
I think:

So I write a simple parser - it matches key=value pairs and assigns
the pairs into e.g. a Ruby Hash as they come in. And the full protocol
looks like: client produces the list of pairs, client MACs the list,
server checks the MAC, server parses the list and takes action.

But this document:
FOO=value1
FOO=value2

has the same outcome in the exchange as
FOO=value2

But they authenticate differently. Which implies that there's a list
of pairs that mean the same thing as
FOO=value2

but authenticate as if
FOO=value1

because there's a chain of pointless assignments of FOO. The solution
to that would be (on way or another) to constrain the lists language
so that keys have to be part of a set, i.e.
FOO=value1
FOO=value2 XXX error!
because FOO has been repeated.

So I redefine the language: it's a list of key=value, but no key can
be repeated. I *believe* that language is context sensitive, (where
before it was regular) and the langsec OWS people are going to camp
out on my lawn. But if I don't make it context sensitive, there's a
message authentication problem, because multiple valid documents have
the same authentication code.

Also granted: in this example, it would be easy enough to check for
the presence of the key in the host language data structure on each
match - but now you're pulling some of the parsing out into the
application code, which might be acceptable in some circumstances?

For instance, a language like DER that uses byte counts can be
transformed into CER with field-end markers trivially, and therefore
reduced on the server side from context-sensitive to context-free, no?
Is that okay? If not, why not if checking for key uniqueness is okay
outside the parser?

Judson

On Tue, May 27, 2014 at 8:42 AM, Theodore Ts'o <tytso at mit.edu> wrote:
> On Tue, May 27, 2014 at 07:42:25AM +1000, James A. Donald wrote:
>> >What confuses me is trying to align this with a principle of
>> >cryptography that you should only authenticate what you mean, as
>> >opposed to authenticating a particular series of bytes, especially in
>> >the face of langsec sites that recommend the use of JSON after having
>> >argued convincingly against ASN.1 DER.
>>
>>
>> ASN.1 DER contains a turing machine in which the attacker can execute code
>> that you never imagined.
>>
>> With ASN.1 PER that turing machine is executed at compile time, and at run
>> time is no longer around, so your attacker cannot use it.
>
> Furthermore, competent JSON readers do not parse JSON by exec'ing the
> JSON as javascript, but rather by explicitly parsing it.  It's true
> that a config language such as this:
>
> FOO=value1
> BAR=value2
>
> can be parsed by a shell script using ". config", but that doesn't
> mean that this is the only way, or even the advisable way, to parse
> such an encoding!
>
>                                                 - Ted
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography


More information about the cryptography mailing list