Thursday, January 27. 2011
Energy effiency of cable modems and routers
I already wrote in the past that a couple of times that I'm worried about the insane high energy consumption of DSL and WLAN hardware that's supposed to run all the time.
Recently, I switched my internet provider from O2 to Kabel Deutschland and got new hardware. I made some findings I found interesting:
It seems very many power supplies today have a label on their energy effiency. If you find something called "EFFIENCY LEVEL: V" - that's it. V is currently the best, I the worst. Higher values are reserved for the future (so this is much more intelligent than the stupid EU energy label, where A stands for "this was the best when we invented this label some years ago"). I haven't tried that yet, but from what I read it seems worth replacing inefficient power supplies with better ones.
The cable modem I got eats 4 Watts. Considering that it's the crucial part that cannot be switched off as long as I want to be able to receive phone calls, I consider this rather high. The power supply had effiency level IV. If anyone knows of any energy saving cable modems, I'm open for suggestions.
I was quite impressed by the router I got for free. It's a D-Link 615 and it's using 2,4 Watts with wireless and 1,4 Watts without. That's MUCH better than anything I've seen before. So at least we see some progress here. (and for people interested in free software: it seems at least DD-WRT claims to support it and the other *WRT projects are working on it)
Though I still fail to understand why there can't be a simple law stating that every electronic device must put information about it's energy consumption on the package.
Recently, I switched my internet provider from O2 to Kabel Deutschland and got new hardware. I made some findings I found interesting:
It seems very many power supplies today have a label on their energy effiency. If you find something called "EFFIENCY LEVEL: V" - that's it. V is currently the best, I the worst. Higher values are reserved for the future (so this is much more intelligent than the stupid EU energy label, where A stands for "this was the best when we invented this label some years ago"). I haven't tried that yet, but from what I read it seems worth replacing inefficient power supplies with better ones.
The cable modem I got eats 4 Watts. Considering that it's the crucial part that cannot be switched off as long as I want to be able to receive phone calls, I consider this rather high. The power supply had effiency level IV. If anyone knows of any energy saving cable modems, I'm open for suggestions.
I was quite impressed by the router I got for free. It's a D-Link 615 and it's using 2,4 Watts with wireless and 1,4 Watts without. That's MUCH better than anything I've seen before. So at least we see some progress here. (and for people interested in free software: it seems at least DD-WRT claims to support it and the other *WRT projects are working on it)
Though I still fail to understand why there can't be a simple law stating that every electronic device must put information about it's energy consumption on the package.
Posted by Hanno Böck
in Ecology, English, Linux
at
21:22
| Comment (1)
| Trackbacks (0)
Defined tags for this entry: cablemodem, climate, d-link, ecology, efficiency, eletricity, environment, kabeldeutschland, o2, router, strom, stromverbrauch, umwelt
Wednesday, January 5. 2011
How to create a PGP/GPG-key free of SHA-1
If you've read my last blog entry, you saw that I was struggling a bit with the fact that I was unable to create a PGP key without SHA-1. This is a bit tricky, as there are various places where hash functions are used within a pgp key:
1. The key self-signatures and signatures on other keys. Every key has user IDs that are signed with the master key itself. This is to proofe that the names and mail adresses in the key belong to the keyholder itself and can't be replaced my a malicous attacker.
2. The signatures on messages, for example E-Mails.
3. The preference in side the key - this indicates to other people what sigature algorithms you would prefer if they send messages to you.
4. The fingerprint.
1 is controlled by the setting cert-digest-algo in the file gpg.conf (for both self-signatures and signatures to other keys). 2 is controlled by the setting personal-digest-preferences. So you should add these two lines to your gpg.conf, preferrably before you create your own key (if you intend to create one, don't bother if you want to stick with your current one):
It is also not really trivial to check the used algorithms. For message signatures, if you verify them with gpg -v --verify [filename]. For key signatures, I found no option to do that - but a workaround: Export the key whose signatures you'd like to check gpg --export --armor [key ID] > filename.asc. Then parse the exported file with gpg -vv filename.asc. It'll show you blocks like this:
The big question remains: Why is this so complicated and why isn't gnupg just defaulting to SHA256? I don't know the answer.
(Please also have a look at this blog entry from Debian about the topic)
1. The key self-signatures and signatures on other keys. Every key has user IDs that are signed with the master key itself. This is to proofe that the names and mail adresses in the key belong to the keyholder itself and can't be replaced my a malicous attacker.
2. The signatures on messages, for example E-Mails.
3. The preference in side the key - this indicates to other people what sigature algorithms you would prefer if they send messages to you.
4. The fingerprint.
1 is controlled by the setting cert-digest-algo in the file gpg.conf (for both self-signatures and signatures to other keys). 2 is controlled by the setting personal-digest-preferences. So you should add these two lines to your gpg.conf, preferrably before you create your own key (if you intend to create one, don't bother if you want to stick with your current one):
personal-digest-preferences SHA2563 defaults to SHA256 if you generate your key with a recent GnuPG version. You can check it with gpg --edit-key [your key ID] and then showpref. For 4, I think it can't be changed at all (though I think it doesn't mean a security threat for collission attacks - still it should be changed at some point).
cert-digest-algo SHA256
It is also not really trivial to check the used algorithms. For message signatures, if you verify them with gpg -v --verify [filename]. For key signatures, I found no option to do that - but a workaround: Export the key whose signatures you'd like to check gpg --export --armor [key ID] > filename.asc. Then parse the exported file with gpg -vv filename.asc. It'll show you blocks like this:
:signature packet: algo 1, keyid A5880072BBB51E42The digest algo 8 is what you're looking for. 1 means MD5, 2 means SHA1, 8 means SHA256. Other values can be looked up in include/cipher.h in the source code. No, that's not user friendly. But I found no easier way.
version 4, created 1294258192, md5len 0, sigclass 0x13
digest algo 8, begin of digest 3e c3
The big question remains: Why is this so complicated and why isn't gnupg just defaulting to SHA256? I don't know the answer.
(Please also have a look at this blog entry from Debian about the topic)
(Page 1 of 1, totaling 2 entries)