On Sat, Jun 27, 2015 at 8:18 PM, Johannes Bauer <dfnsonfsdu...@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 -- https://mail.python.org/mailman/listinfo/python-list