Re: Impending Crypto Monoculture
On Friday, 15 April 2016 9:46:40 AM AEST Chris Samuel via luv-main wrote: > There is an interesting rebuttal of the fanboyism remark in the LWN article > in one of the comments here: Grr... hit the shortcut to send once, got a popup dialog saying that this shortcut can lead to accidentally sending messages and giving me a range of options, the first of which was to disable the shortcut, which I did. Hit that again and it sent it without prompting! Sigh... Here's the link I was about to insert. https://lwn.net/Articles/682260/ cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Impending Crypto Monoculture
Hi folks, Given the ongoing crypto discussion I thought this post on LWN "The prospect of a crypto monoculture" from a few weeks back (publicly available now) might be of interest: https://lwn.net/Articles/681615/ It's a discussion of Peter Gutmann's post to comp.encryption.general entitled "On the Impending Crypto Monoculture" about how we are heading towards a situation where the only strong encryption that seems well designed is both designed and implemented by a single group, led by Dan Bernstein. There is an interesting rebuttal of the fanboyism remark in the LWN article in one of the comments here: Peter's post is archived here: https://lwn.net/Articles/681616/ Peter has been doing crypto for a long time and wrote the excellently titled "Everything you Never Wanted to Know about PKI but were Forced to Find Out": https://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf It's an interesting situation, though I think I'd trust Dan a bit more than I trust the USG now. :-) All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: SP Ausnet and ZigBee devices
On Saturday, 9 April 2016 10:38:41 PM AEST Chris Samuel via luv-main wrote: > So I guess we've got some time to wait still... I prodded them via their Zendesk support site and got this response: # At this point of time, AusNet Services does not support the customer # binding of ZigBee devices (eg In Home Display) to their smart meter. # # It will be possible to connect real time devices to most smart meters, # the estimated time of arrival for IHD devices is August 2016. # # Updates will be provided on www.ausnetservices.com.au So perhaps this year... -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: simple CLI MUA for GPG
[Warning: super ranty email follows.] Ben McGinnes wrote: > On Wed, Apr 13, 2016 at 10:06:11PM +1000, Russell Coker wrote: > > On Wed, 13 Apr 2016 05:26:49 PM Ben McGinnes via luv-main wrote: > > > >> As far as I'm concerned if you can't be bothered editing your > >> algorithm preference order in gpg.conf and editing your keys and > >> subkeys (actually they're set according to each UID) to match then you > >> have no business trying to make keys larger than the default maximums. > > > > Actually I think it's the responsibility of DDs in question (and > > other OS developers) to ensure that GPG defaults to the correct > > algorithm preference. > > Currently the default in most Linux distros (or OSes for that matter) > is to create ~/.gnupg/ if its not there when the program is invoked, > but not to generate a default gpg.conf. Why is it the DD's responsibility, rather than upstream GnuPG project's responsibility? Surely people *writing* crypto software know better than people *packaging* crypto software, what the Best Current Practice is. Upstream & distro might choose different defaults because of a balance between usability & security (especially if it's a specialist distro), but in general I'd expect upstream to lean heavily towards security. Is gnupg upstream defaulting to weak settings? If so, why? Just to avoid bikeshedding on the ML, or something? > Distributions could set more sensible defaults by setting a basic > system wide gpg.conf to be copied to a user's directory if it didn't > exist, but the problem is that the first command for a lot of new > users is --gen-key and if the gpg.conf is not already in place when > the command is run then it won't affect the results. If there's a host-wide default, it shouldn't need to be copied into ~ to take effect. If it has to be copied in, what happens when both /etc and ~ versions are edited? Do the upstream improvements just get ignored for existing users? Compare with how OpenSSH built-in defaults are overridden by /etc/ssh_config, which is in turn overriden by ~/.ssh/config. [BEGIN TANGENTIAL RANT] One problem I had configuring OpenSSH is that you can say My preferred cipher order is: But you can't have JUST a blacklist Never use: If means if I set up my .ssh/config sensibly TODAY, then forget to go back and maintain them, I'll end up with security that's *worse* than the upstream default, instead of better then the upstream default. Because upstream will say KexAlgorithms , And my .ssh/config will override it to say KexAlgorithms Where will equate to , and my config never sees . [END TANGENTIAL RANT] I dunno if that applies to GnuPG because, frankly, I've been obscenely lazy. >> Also it would be handy if there was a tool to check your GPG >> configuration and key setup for obvious mistakes. An actively maintained "linter" that checked both config and the keys themselves, to make sure they followed current best practice, sounds like a great idea. I am thinking something like lintian or perlcritic, which not only says "this is wrong", but also explains why it's wrong, & suggests how to fix it. ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: simple CLI MUA for GPG
On Wed, Apr 13, 2016 at 10:06:11PM +1000, Russell Coker wrote: > > Also it would be handy if there was a tool to check your GPG > configuration and key setup for obvious mistakes. And in proof that I had had neither enough caffeine nor blood moving through my brain; I have now remembered and confirmed that all that info is available from --list-packets and more human readable with pgpdump. So scripting something which uses export of the public key and then list-packets to check it should be fairly straight forward. I figure some little command line thing where you enter a key ID, fingerprint or UID and it'll do the rest. For UIDs then checking the secret keyring first is probably best, but multiple matches can either be dealt with a "pick one from the list" option or just running the check against every match (maybe, some public keyrings are getting a bit large now). Anyway, I'll check with the others and make sure there isn't already something like that tucked away somewhere and if not then it seems like a good side project to add somewhere. I just need to decide precisely where. Regards, Ben -- | Ben McGinnes | Adversarial Press | Twitter: benmcginnes | | Writer, Publisher, Systems Administrator, Trainer, ICT Consultant | | http://www.adversary.org/ http://publishing.adversary.org/ | | GPG Made Easy (GPGME) Python 3 API Maintainer, GNU Privacy Guard | | https://www.gnupg.org/ https://ssd.eff.org/ | | GPG key: 0x321E4E2373590E5D http://www.adversary.org/ben-key.asc | signature.asc Description: PGP signature ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
