Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #93096 > unrolled thread
| Started by | Randall Smith <randall@tnr.cc> |
|---|---|
| First post | 2015-06-24 13:36 -0500 |
| Last post | 2015-06-25 14:09 -0500 |
| Articles | 20 on this page of 97 — 19 participants |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-24 13:36 -0500
Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-25 14:07 +1000
Re: Pure Python Data Mangling or Encrypting Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-06-24 21:27 -0700
Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-25 19:25 +1000
Re: Pure Python Data Mangling or Encrypting Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-06-25 02:41 -0700
Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-25 19:57 +1000
Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-25 10:03 +0000
Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-26 01:13 +1000
Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-25 15:26 +0000
Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-25 13:58 -0500
Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-26 10:33 +1000
Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-26 10:49 +0000
Re: Pure Python Data Mangling or Encrypting Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-25 19:01 -0600
Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-27 03:06 +1000
Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-26 15:09 -0500
Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-26 23:07 +0200
Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-26 21:29 +0000
Re: Pure Python Data Mangling or Encrypting Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-26 22:55 +0100
Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-27 00:42 +0200
Re: Pure Python Data Mangling or Encrypting Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-06-26 16:26 -0700
Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-27 00:21 +0000
Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-26 19:55 -0500
Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-27 07:24 +0200
Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-26 19:12 -0500
Re: Pure Python Data Mangling or Encrypting Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-26 15:58 -0600
Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-26 19:23 -0500
Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-26 23:11 +0200
Re: Pure Python Data Mangling or Encrypting Michael Torrie <torriem@gmail.com> - 2015-06-27 11:02 -0600
Re: Pure Python Data Mangling or Encrypting Paul Rubin <no.email@nospam.invalid> - 2015-06-27 10:45 -0700
Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-27 13:38 +1000
Re: Pure Python Data Mangling or Encrypting Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-06-26 21:05 -0700
Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-27 16:16 +1000
Re: Pure Python Data Mangling or Encrypting Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-06-27 13:30 -0700
Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-28 11:18 +1000
Re: Pure Python Data Mangling or Encrypting Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-06-27 19:11 -0700
Re: Pure Python Data Mangling or Encrypting Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-26 23:47 -0600
Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-27 18:38 +1000
Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-27 18:53 +1000
Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-27 11:07 +0200
Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-27 19:17 +1000
Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-27 09:27 +0000
Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-27 12:05 +0200
Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-27 20:16 +1000
Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-27 12:55 +0200
Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-27 10:26 +0000
Re: Pure Python Data Mangling or Encrypting Laura Creighton <lac@openend.se> - 2015-06-27 14:27 +0200
Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-27 12:18 +0200
Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-27 21:33 +1000
Re: Pure Python Data Mangling or Encrypting Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-27 08:59 -0600
Re: Pure Python Data Mangling or Encrypting Laura Creighton <lac@openend.se> - 2015-06-27 13:25 +0200
Re: Pure Python Data Mangling or Encrypting Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-06-27 15:23 +0300
Re: Pure Python Data Mangling or Encrypting Laura Creighton <lac@openend.se> - 2015-06-27 14:48 +0200
Re: Pure Python Data Mangling or Encrypting Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-06-27 11:12 +0200
Re: Pure Python Data Mangling or Encrypting Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-27 09:09 -0600
Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-28 03:35 +1000
Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-28 03:58 +1000
Re: Pure Python Data Mangling or Encrypting Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-27 14:16 -0600
Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-28 13:41 +0000
Re: Pure Python Data Mangling or Encrypting Robert Kern <robert.kern@gmail.com> - 2015-06-27 08:58 +0100
Re: Pure Python Data Mangling or Encrypting Robert Kern <robert.kern@gmail.com> - 2015-06-27 09:07 +0100
Re: Pure Python Data Mangling or Encrypting Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-06-27 10:39 -0400
Re: Pure Python Data Mangling or Encrypting Grant Edwards <invalid@invalid.invalid> - 2015-06-27 12:38 +0000
Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-27 13:22 -0500
Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-28 04:51 +1000
Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-28 09:05 +1000
Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-27 11:21 +1000
Re: Pure Python Data Mangling or Encrypting Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-26 23:59 -0600
Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-27 09:26 +0000
Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-27 16:52 +1000
Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-27 12:08 -0500
Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-28 04:50 +1000
Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-29 15:52 -0500
Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-06-30 13:00 +1000
Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-30 12:19 +0000
Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-07-01 04:17 +1000
Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-07-01 04:33 +1000
Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-30 18:37 +0000
Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-07-01 09:38 -0500
Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-30 12:39 -0500
Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve@pearwood.info> - 2015-07-01 04:59 +1000
Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-07-01 05:20 +1000
Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-30 23:25 +0000
Re: Pure Python Data Mangling or Encrypting alister <alister.nospam.ware@ntlworld.com> - 2015-07-01 08:06 +0000
Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-28 14:21 +0000
Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-29 15:46 -0500
Re: Pure Python Data Mangling or Encrypting Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-29 20:49 +0000
Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-30 12:43 -0500
Re: Pure Python Data Mangling or Encrypting Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-07-02 10:31 +1200
Re: Pure Python Data Mangling or Encrypting Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-26 02:17 +0100
Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-26 12:06 +1000
Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-26 12:05 +1000
Re: Pure Python Data Mangling or Encrypting Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-26 03:24 +0100
Re: Pure Python Data Mangling or Encrypting Chris Angelico <rosuav@gmail.com> - 2015-06-26 12:29 +1000
Re: Pure Python Data Mangling or Encrypting Joonas Liik <liik.joonas@gmail.com> - 2015-06-25 13:00 +0300
Re: Pure Python Data Mangling or Encrypting Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-06-25 03:18 -0700
Re: Pure Python Data Mangling or Encrypting Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-25 17:05 +1000
Re: Pure Python Data Mangling or Encrypting Randall Smith <randall@tnr.cc> - 2015-06-25 14:09 -0500
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2015-06-27 09:27 +0000 |
| Message-ID | <slrnmosr71.1nu.jon+usenet@frosty.unequivocal.co.uk> |
| In reply to | #93234 |
On 2015-06-27, Chris Angelico <rosuav@gmail.com> wrote: > On Sat, Jun 27, 2015 at 7:07 PM, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote: >> On 27.06.2015 10:53, Chris Angelico wrote: >>> On Sat, Jun 27, 2015 at 6:38 PM, Steven D'Aprano <steve@pearwood.info> wrote: >>>> I'm not a security expert. I'm not even a talented amateur. *Every time* I >>>> suggest that "X is secure", the security guy at work shoots me down in >>>> flames. But nicely, because I pay his wages <wink> >>> >>> Just out of interest, is _anybody_ active in this thread an expert on >>> security? >> >> Yes. I've done a good 10 years of work in the field doing security >> (mostly applied cryptography on embedded systems with a focus on side >> channels like DPA, but also security concepts and threat/risk analysis) >> and spent the last 3-4 years working on my PhD in the field of IT >> security. My thesis is almost(tm) finished. I would claim to be an >> expert, yes. > > 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. Johannes might have all the education in the world, but he's demonstrated quite comprehensively in this thread that he doesn't have a clue what he's talking about.
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2015-06-27 12:05 +0200 |
| Message-ID | <mmlsh8$kj6$1@news.albasani.net> |
| In reply to | #93236 |
On 27.06.2015 11:27, Jon Ribbens wrote: > Johannes might have all the education in the world, but he's > demonstrated quite comprehensively in this thread that he doesn't > have a clue what he's talking about. Oh, how hurtful. I might even shed a tear or two, but it's pretty clear to me that you're just suffering under the Dunning-Kruger effect. No worries, champ, it's just a phase that'll go away eventually. Hugs and kisses, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-06-27 20:16 +1000 |
| Message-ID | <mailman.132.1435400215.3674.python-list@python.org> |
| In reply to | #93237 |
On Sat, Jun 27, 2015 at 8:05 PM, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote: > On 27.06.2015 11:27, Jon Ribbens wrote: > >> Johannes might have all the education in the world, but he's >> demonstrated quite comprehensively in this thread that he doesn't >> have a clue what he's talking about. > > Oh, how hurtful. I might even shed a tear or two, but it's pretty clear > to me that you're just suffering under the Dunning-Kruger effect. No > worries, champ, it's just a phase that'll go away eventually. Okay, Johannes, NOW you're proving that you don't have a clue what you're talking about. D-K effect doesn't go away... ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2015-06-27 12:55 +0200 |
| Message-ID | <mmlvei$i27$1@news.albasani.net> |
| In reply to | #93238 |
On 27.06.2015 12:16, Chris Angelico wrote: > Okay, Johannes, NOW you're proving that you don't have a clue what > you're talking about. D-K effect doesn't go away... :-D It does in some people. I've seen it happen, with knowledge comes humility. Not saying Jon is a lost cause just yet. He's just in intellectual puberty right now. I'm giving him a few years to re-judge. Cheers, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2015-06-27 10:26 +0000 |
| Message-ID | <slrnmosull.1nu.jon+usenet@frosty.unequivocal.co.uk> |
| In reply to | #93237 |
On 2015-06-27, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote: > On 27.06.2015 11:27, Jon Ribbens wrote: >> Johannes might have all the education in the world, but he's >> demonstrated quite comprehensively in this thread that he doesn't >> have a clue what he's talking about. > > Oh, how hurtful. I might even shed a tear or two, but it's pretty clear > to me that you're just suffering under the Dunning-Kruger effect. No > worries, champ, it's just a phase that'll go away eventually. I guess we need to add the Dunning-Kruger effect to that ever-growing list of things that you don't understand then...
[toc] | [prev] | [next] | [standalone]
| From | Laura Creighton <lac@openend.se> |
|---|---|
| Date | 2015-06-27 14:27 +0200 |
| Message-ID | <mailman.135.1435408071.3674.python-list@python.org> |
| In reply to | #93236 |
In a message of Sat, 27 Jun 2015 20:16:47 +1000, Chris Angelico writes: >Okay, Johannes, NOW you're proving that you don't have a clue what >you're talking about. D-K effect doesn't go away... > >ChrisA You need to read the paper again. That was the whole point -- when Kruger and Dunning went and taught the people at the bottom quadrile some basic skill in the task being estimated, and taught people at the top quadrile how poorly their peers were performing, their ability to estimate how they would score relative to their peers improved a whole lot. But, of course, since these were academics studying students, they had access to bottom-quadrile performers who actually wanted to learn and improve. In the real world, it is getting the bottom-performers to even notice that they need improvement that may be the most difficult task. Laura
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2015-06-27 12:18 +0200 |
| Message-ID | <mmlt9l$m7s$1@news.albasani.net> |
| In reply to | #93234 |
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? 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. It appears to be online-only, is that correct? Is Internet coverage so good down under? I wish this were the case in Germany :-/ 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. In any case, interesting. Thanks for sharing. Best regards, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-06-27 21:33 +1000 |
| Message-ID | <mailman.134.1435404816.3674.python-list@python.org> |
| In reply to | #93239 |
On Sat, Jun 27, 2015 at 8:18 PM, Johannes Bauer <dfnsonfsduifb@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
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2015-06-27 08:59 -0600 |
| Message-ID | <mailman.138.1435417225.3674.python-list@python.org> |
| In reply to | #93239 |
On Sat, Jun 27, 2015 at 5:33 AM, Chris Angelico <rosuav@gmail.com> wrote: > On Sat, Jun 27, 2015 at 8:18 PM, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote: >> 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. That description could apply equally well to Javascript, though. ;-)
[toc] | [prev] | [next] | [standalone]
| From | Laura Creighton <lac@openend.se> |
|---|---|
| Date | 2015-06-27 13:25 +0200 |
| Message-ID | <mailman.133.1435404332.3674.python-list@python.org> |
| In reply to | #93234 |
Johannes, if you don't know "Yes, Minister" then you most likely do not know the Politician's Syllogism (which now has its own wikipedia page :) And I _didn't_ do it! Honest!) Something must be done. This is something. Therefore we must do it! :) Unfortunatetely, the Politician's Syllogism is not restricted to television comedies. It's alive and well in Brussels, and mixes very nicely with the Dunning-Kruger effect. Laura
[toc] | [prev] | [next] | [standalone]
| From | Jussi Piitulainen <jpiitula@ling.helsinki.fi> |
|---|---|
| Date | 2015-06-27 15:23 +0300 |
| Message-ID | <lf5d20h9w7o.fsf@ling.helsinki.fi> |
| In reply to | #93242 |
Laura Creighton writes: > Johannes, if you don't know "Yes, Minister" then you most likely do > not know the Politician's Syllogism (which now has its own wikipedia > page :) And I _didn't_ do it! Honest!) > > Something must be done. > This is something. > Therefore we must do it! Surely that's to be worded as follows? To have a stricter syllogistic form. We need to do something. This is something. Therefore we need to do this. Or, We must do something. This is something. Therefore we must do this. Or, but this feels weaker to me, Something must be done. This is something. Therefore this must be done. ISWIM. In particular, I think the move from the agentless passive (must be done) to the specific expression of agency (we must do) seems to me to be a *different* joke. (I was tempted to call it passive temperature but that would have been yet another, unrelated joke.) :)
[toc] | [prev] | [next] | [standalone]
| From | Laura Creighton <lac@openend.se> |
|---|---|
| Date | 2015-06-27 14:48 +0200 |
| Message-ID | <mailman.136.1435409306.3674.python-list@python.org> |
| In reply to | #93242 |
In a message of Sat, 27 Jun 2015 15:23:07 +0300, Jussi Piitulainen writes: >Laura Creighton writes: > >> Johannes, if you don't know "Yes, Minister" then you most likely do >> not know the Politician's Syllogism (which now has its own wikipedia >> page :) And I _didn't_ do it! Honest!) >> >> Something must be done. >> This is something. >> Therefore we must do it! > >Surely that's to be worded as follows? To have a stricter syllogistic >form. > >We need to do something. >This is something. >Therefore we need to do this. Somehow doesn't have the same comedic ring, though. So the version I posted is what was on the tv show. (Or rather in Yes, Prime Minister.) The Minister becomes Prime Minister for the last 2 seasons. In the television show it is just called 'Politician's Logic'. Not sure who started calling it the Politicians Syllogism. Laura
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2015-06-27 11:12 +0200 |
| Message-ID | <mmlpd7$n64$1@news.albasani.net> |
| In reply to | #93230 |
On 27.06.2015 10:38, Steven D'Aprano wrote: > Can you say "timing attack"? > > http://codahale.com/a-lesson-in-timing-attacks/ > > Can you [generic you] believe that attackers can *reliably* attack remote > systems based on a 20µs timing differences? If you say "No", then you fail > Security 101 and should step away from the computer until a security expert > can be called in to review your code. Yes, as people do more and more proper crypto (in contrast to crappy stuff like LFSR-based custom keystream generators and such), side channels become of great importance. > I'm not a security expert. I'm not even a talented amateur. *Every time* I > suggest that "X is secure", the security guy at work shoots me down in > flames. But nicely, because I pay his wages <wink> :-) Being shot down in flames is the way to become a security expert, probably the *only* way. I don't know anyone who is an expert who hasn't had that horrible experience at least a dozen of times. It is amazing how many holes you can poke in designs if you look at it from enough angles. Having holes poked in my designs gives you a thourough appreciation for the true crypto experts (i.e. people doing theoretical cryptography). Best regards, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2015-06-27 09:09 -0600 |
| Message-ID | <mailman.139.1435417817.3674.python-list@python.org> |
| In reply to | #93230 |
On Sat, Jun 27, 2015 at 2:38 AM, Steven D'Aprano <steve@pearwood.info> wrote: > Can you [generic you] believe that attackers can *reliably* attack remote > systems based on a 20µs timing differences? If you say "No", then you fail > Security 101 and should step away from the computer until a security expert > can be called in to review your code. Of course. I wouldn't bet the house on it, but with the proposed substitution cipher system, I don't see why there would be any measurable timing differences at all based on the choice of key. The time to obfuscate a single byte is constant, so the total time to obfuscate the payload should just be a function of the length of the data. Secondly, the 200 (or whatever) response to the client does not depend on the outcome of the obfuscation step, so there is no reason that the server cannot simply respond first and obfuscate after, giving the client nothing to time.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2015-06-28 03:35 +1000 |
| Message-ID | <558eded8$0$1642$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #93250 |
On Sun, 28 Jun 2015 01:09 am, Ian Kelly wrote:
> On Sat, Jun 27, 2015 at 2:38 AM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> Can you [generic you] believe that attackers can *reliably* attack remote
>> systems based on a 20µs timing differences? If you say "No", then you
>> fail Security 101 and should step away from the computer until a security
>> expert can be called in to review your code.
>
> Of course. I wouldn't bet the house on it, but with the proposed
> substitution cipher system, I don't see why there would be any
> measurable timing differences at all based on the choice of key.
I wouldn't bet one wooden nickle on it. Not without a security audit of the
application. And then what happens when the implementation changes and the
audit is no longer valid?
Despite his initial claim that he doesn't want to use AES because it's too
slow implemented as pure Python, Randall has said that the application will
offer AES encryption as an option. (He says it is enabled by default,
except that the user can turn it off.) So the code is already there, all he
has to do is call it.
It might not be a timing attack. Maybe there's a vulnerability in the
application that if you upload a sufficiently large file, a buffer will
overflow and you can force the key of your choosing. Who knows? Bugs
happen. The nature of how the hypothetical key leakage happens is less
important than the consequences if there is one.
Randall can:
(1) bet the security of his application and his users on the key never
leaking;
"Why have you situated a naked flame right next to the gas tank?"
"It's okay, I'm confident that the tank will never leak."
or
(2) use something which, *even if the key leaks*, is still resistant to
preimage attacks.
The choice ought to be a no-brainer. The fact that folks are seriously
considering using something barely one step up from a medieval substitution
cipher in 2015 for something with real security consequences if it is
broken goes to show what a lousy job the IT industry does for security.
> The time to obfuscate a single byte is constant,
Are you sure about that? Bet your house? How about your computer?
# Python 3.3 on Linux, YMMV
py> text = 'NOBODY expects the Spanish Inquisition!'*50000
py> import string
py> s = string.digits + string.ascii_letters
py> t = (string.ascii_uppercase + string.digits[::-1] +
... string.ascii_lowercase)
py> trans1 = str.maketrans('abcdef', 'fedcba')
py> trans2 = str.maketrans(s, t)
py> trans3 = str.maketrans('aZ', 'Za')
py> with Stopwatch():
... x = str.translate(text, trans1)
...
time taken: 0.427513 seconds
py> with Stopwatch():
... x = str.translate(text, trans2)
...
time taken: 0.228869 seconds
py> with Stopwatch():
... x = str.translate(text, trans3)
...
time taken: 0.387105 seconds
> so the total time to
> obfuscate the payload should just be a function of the length of the
> data.
Good thing you didn't bet your house.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2015-06-28 03:58 +1000 |
| Message-ID | <558ee429$0$1662$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #93253 |
On Sun, 28 Jun 2015 03:35 am, Steven D'Aprano wrote: > On Sun, 28 Jun 2015 01:09 am, Ian Kelly wrote: >> The time to obfuscate a single byte is constant, > > Are you sure about that? Bet your house? How about your computer? Correction: the example I showed uses str, not bytes. With bytes, the timing differences are much smaller. Are they statistically distinguishable? Don't know. On my machine, they appear to be, although that could be just a fluke. Is there a guarantee that bytes.translate will always be constant time per byte? No of course not. Might the application itself some day start using str.translate? Who knows? The point is, you cannot rely on this. Preventing leakage is *hard*. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2015-06-27 14:16 -0600 |
| Message-ID | <mailman.145.1435436224.3674.python-list@python.org> |
| In reply to | #93253 |
On Sat, Jun 27, 2015 at 11:35 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Sun, 28 Jun 2015 01:09 am, Ian Kelly wrote:
>
>> On Sat, Jun 27, 2015 at 2:38 AM, Steven D'Aprano <steve@pearwood.info>
>> wrote:
>>> Can you [generic you] believe that attackers can *reliably* attack remote
>>> systems based on a 20µs timing differences? If you say "No", then you
>>> fail Security 101 and should step away from the computer until a security
>>> expert can be called in to review your code.
>>
>> Of course. I wouldn't bet the house on it, but with the proposed
>> substitution cipher system, I don't see why there would be any
>> measurable timing differences at all based on the choice of key.
>
> I wouldn't bet one wooden nickle on it. Not without a security audit of the
> application. And then what happens when the implementation changes and the
> audit is no longer valid?
I don't disagree about the security audit, although I think you'll
find that such things will require a greater investment of resources
than a wooden nickel.
> Despite his initial claim that he doesn't want to use AES because it's too
> slow implemented as pure Python, Randall has said that the application will
> offer AES encryption as an option.
Once again you're confusing what he said about the server with what he
said about the client. Just because he considers it too slow for data
mangling on the server doesn't make it too slow for any use.
>> The time to obfuscate a single byte is constant,
>
> Are you sure about that? Bet your house? How about your computer?
>
>
> # Python 3.3 on Linux, YMMV
>
> py> text = 'NOBODY expects the Spanish Inquisition!'*50000
> py> import string
> py> s = string.digits + string.ascii_letters
> py> t = (string.ascii_uppercase + string.digits[::-1] +
> ... string.ascii_lowercase)
> py> trans1 = str.maketrans('abcdef', 'fedcba')
> py> trans2 = str.maketrans(s, t)
> py> trans3 = str.maketrans('aZ', 'Za')
> py> with Stopwatch():
> ... x = str.translate(text, trans1)
> ...
> time taken: 0.427513 seconds
> py> with Stopwatch():
> ... x = str.translate(text, trans2)
> ...
> time taken: 0.228869 seconds
> py> with Stopwatch():
> ... x = str.translate(text, trans3)
> ...
> time taken: 0.387105 seconds
Your examples are using partial keys of different sizes. It's hardly
surprising that the timing varies when you pass dicts of varying sizes
as the translation tables.
py> a = list(range(256))
py> b = random.sample(a, 256)
py> c = random.sample(a, 256)
py> d = random.sample(a, 256)
py> min(timeit.repeat("str.translate(text, a)", "from __main__ import
text, a", number=10, repeat=10))
0.9780099680647254
py> min(timeit.repeat("str.translate(text, b)", "from __main__ import
text, b", number=10, repeat=10))
0.9837233647704124
py> min(timeit.repeat("str.translate(text, c)", "from __main__ import
text, c", number=10, repeat=10))
0.9627216667868197
py> min(timeit.repeat("str.translate(text, d)", "from __main__ import
text, d", number=10, repeat=10))
0.9793561780825257
py> min(timeit.repeat("str.translate(text, c)", "from __main__ import
text, c", number=10, repeat=10))
0.9840573272667825
I ran it on c a second time to see if the 0.962 timing was systemic or
a fluke. The fact that c produced both the shortest and longest
timings out of only two runs lends me confidence (for the purpose of
this discussion) that the variation seen in these timings is random
and not correlated to the keys used.
[toc] | [prev] | [next] | [standalone]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2015-06-28 13:41 +0000 |
| Message-ID | <slrnmovufq.1nu.jon+usenet@frosty.unequivocal.co.uk> |
| In reply to | #93253 |
On 2015-06-27, Steven D'Aprano <steve@pearwood.info> wrote: > Despite his initial claim that he doesn't want to use AES because it's too > slow implemented as pure Python, Randall has said that the application will > offer AES encryption as an option. (He says it is enabled by default, > except that the user can turn it off.) So the code is already there, all he > has to do is call it. You're still not listening to what he's saying. Everything you have said in the above paragraph is false. He said he is using AES encryption in the client, but that the server does not have the processing power to do so (nor does it need to). He has not said that the user "can turn it off", he's just acknowledging the fact that since the user controls their own computer, they can rewrite the client code to do whatever they want, and there's nothing he can do to stop them. > The choice ought to be a no-brainer. The fact that folks are seriously > considering using something barely one step up from a medieval substitution > cipher in 2015 for something with real security consequences if it is > broken goes to show what a lousy job the IT industry does for security. The fact that you think that is happening when it isn't shows what a lousy job you have been doing of following the thread.
[toc] | [prev] | [next] | [standalone]
| From | Robert Kern <robert.kern@gmail.com> |
|---|---|
| Date | 2015-06-27 08:58 +0100 |
| Message-ID | <mailman.127.1435391945.3674.python-list@python.org> |
| In reply to | #93217 |
On 2015-06-27 04:38, Steven D'Aprano wrote: > Maybe you use Python's standard library and the Mersenne Twister. The period > of that is huge, possibly bigger than 256! (or not, I forget, and I'm too > lazy to look it up). So you think that's safe. But it's not: Mersenne > Twister is not a cryptographically secure pseudorandom number generator. If > I can get some small number of values from the Twister (by memory, > something of the order of 100 such values) then I can predict the rest for > ever. 634. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
[toc] | [prev] | [next] | [standalone]
| From | Robert Kern <robert.kern@gmail.com> |
|---|---|
| Date | 2015-06-27 09:07 +0100 |
| Message-ID | <mailman.128.1435392450.3674.python-list@python.org> |
| In reply to | #93217 |
On 2015-06-27 08:58, Robert Kern wrote: > On 2015-06-27 04:38, Steven D'Aprano wrote: > >> Maybe you use Python's standard library and the Mersenne Twister. The period >> of that is huge, possibly bigger than 256! (or not, I forget, and I'm too >> lazy to look it up). So you think that's safe. But it's not: Mersenne >> Twister is not a cryptographically secure pseudorandom number generator. If >> I can get some small number of values from the Twister (by memory, >> something of the order of 100 such values) then I can predict the rest for >> ever. > > 634. Bah! 624. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.python
csiph-web