Pure Python Data Mangling or Encrypting

[Chris Angelico]

On Sat, Jun 27, 2015 at 8:18 PM, Johannes Bauer <dfnsonfsduifb at gmx.de> wrote:
> On 27.06.2015 11:17, Chris Angelico wrote:
>
>> Good, so this isn't like that episode of Yes Minister when they were
>> trying to figure out whether to allow a chemical factory to be built.
>
> I must admit that I have no clue about that show or that epsisode in
> particular and needed to read up on it:
> https://en.wikipedia.org/wiki/The_Greasy_Pole
>
>>> I must admit that I haven't seen your ideas in this thread?
>>
>> No, the proposal I'm putting together is unrelated. You'll see the
>> *vast* extent of my security skills here:
>>
>> https://github.com/Rosuav/ThirdSquare
>>
>> My contribution to this thread has been fairly minor, just suggesting
>> one attack that doesn't even work any more, not much else.
>
> Well, if people already have a solution ready there's a good chance that
> any criticism falls on deaf ears. In any case something that others have
> to be responsible for, their party, their choice.
>
> I've looked at your code even though I don't know pike. That's the
> typesafe JavaScript derivative, isn't it?

Not really; it's more like "Python semantics meets C++ syntax". But
that's still off-topic for this list; I'd be happy to continue
discussion off-list with anyone who's interested.

The most interesting part of the project is the README, to be honest.
Even if you can't understand a single line of the code, you'll be able
to see the specs. Grokking the code is a bonus.

> The only thing that I found horrible was the ssh key format to PKCS
> parsing. Man that's hacky :-) You're creating a DER structure on-the-fly
> that you fill with the key and that you then have parsed back. I've only
> seen ssh-keygen used to generate keys (not to initiate actual ssh
> connections), why don't you use openssl to generate the keys? I think
> you can generate a RSA keypair in openssl (also valid for ssh should you
> need it) and I'm pretty sure that you can generate a ssh public key with
> ssh-keygen from that private keypair file. That would eliminate the need
> to do this kind of parsing, but it's just a PoC as I understand it.

Yeah, it's pretty disgusting. I could actually use Pike to generate
the keys, rather than using ssh-keygen at all, but I wanted to
demonstrate that this is using a well-known key generation method,
ergo I don't need to separately prove that the keys are appropriately
random. (Not that I distrust Pike, but it's one less thing to try to
prove.)

> It appears to be online-only, is that correct? Is Internet coverage so
> good down under? I wish this were the case in Germany :-/

Correct, that's one of the key changes. Our current system (Myki) is a
stored-value card - if you recharge a hundred bucks, then clone your
card, you'd have two cards with a hundred bucks each. With
ThirdSquare, if you clone your card, you have two cards that draw on
the same hundred bucks. (Though I still don't want people cloning
cards, as it would confuse the system some. Plus, it'd be really
REALLY bad if someone could clone someone *else's* card, thus
effectively stealing a copy of it. So the cards themselves need some
kind of security, but short of public key crypto performed actually on
the cards, I'm not sure how to do that.)

My plan is to stick a 3G/4G device onto each bus. So long as there's
mobile phone coverage on all routes, which should be fine in suburbia,
the system will work. It can cope with short dropouts (up to ten
minutes), queueing requests in the client.

> Not 100% about it, but I think that the bus concepts that are active in
> Germany (locally in some cities) either user asymmetric transponders
> (i.e. SmartMX), which gives a beautiful, decentralized, secure and
> offline solution at the cost of being comparatively expensive. The
> others use symmetric transponders which have limited off-line
> functionality: i.e. monotonic counters which are reset in a
> cryptographically secured way by backend systems every time a
> online-connection persists and which are counted down in the offline case.

Thanks for the name, I'll check that out. Ideally, I'd like to use
off-the-shelf hardware for everything, and open-source software. It
should be possible for anyone to pick up the specs, buy their own
hardware, and create something that interoperates with the rest of the
system - for instance, the Red Engine Group could allow their
customers to ding their tickets to buy coffee - simply by providing
the appropriate public keys to the central authorizing database. That
would be a massive improvement over Melbourne's previous ticketing
system (Metcard), which was entirely proprietary; expansion of the
fleet required additional validators, and basically the public
transport operators had to beg, cap in hand, for the company to do
them a favour - for which, of course, they then also had to pay the
earth for. But I digress.

ChrisA