Last November i decided to remove all incandescent lamps from the house and replace them with low power compact fluorescent one's.
I replaced 35 100 Watt lamps with the Osram EL Dulux 20W.
http://www.osram.com/osram_com/News/General_Interest_Press/2007/Press616042.jsp
I chose those because mainly i liked the type of light they produced and decided to pay the extra cost to save some CO2 from the planet and go "green" on lighting.
A compact fluorescent lamp is much more expensive to buy than a standard incandescent one, but you save on the long run from the lower electricity consumption and the *longer* working life its supposed to have.
The Osram El Dulux 20W was rated at 10.000h which would replace 10 normal lamps, according to what is printed on the box.
Assuming an average of 6h of working time for the lamp per day , it should last for approx 1666 days or 4.5 years before it fails.
Well i can report that in less than a year, 8 from the 35 lamps have failed and need it to be replaced.
That's almost 1 in 4 (or close to 25%) loss and sure is not what i had hoped for.
I am not sure why the lamps failed, as they failed in random intervals and random places in the house, with the first staring 3-4 months after it was installed.
I don't believe that anyone from Osram will read this blog post but in the case it does, i have kept most of the failed lamps,as i was looking for a place that would accept them for recycling (yes lamps get recycled and need to be recycled as they contain some "serious" metals and not so good chemicals) and if you want i can send them back for you to test with all expenses paid.
In any case, Osram, you should check your quality as you have a really dissatisfied customer.
Saturday, September 12, 2009
Saturday, June 13, 2009
European Commission pushes for software patents via a trusted court
First of all a warning. If part of the following text looks Greek to you,it's because it is. :)
It's part of a message i received from Konstantina Zoehrer regarding the new "initiative" to get software patents in EU, through the backdoor by use of a "trusted court".
For more info check this link.
There is a petitionalso you can sign.
Well it looks like "special interests" follow the good old saying "if you fail once, try again"
So, let's try and stop them one more time.
Greek text follows
Προτρέπουμε τους νομοθέτες μας
* να περάσουν εθνικές νομικές διευκρινίσεις για το δίκαιο ευρεσιτεχνίας για να αποκλείσουν οποιοδήποτε πατέντα λογισμικού,
* να ακυρώσουν όλους τους εγκεκριμένους ισχυρισμούς για πατέντες που μπορεί να παραβιάζονται από λογισμικό το οποίο τρέχει σε προγραμματιζόμενες συσκευές,
* επίσης να αγωνιστούν για τη διάδοση των εν λόγω κανόνων σε Ευρωπαϊκό επίπεδο, συμπεριλαμβανομένης της Ευρωπαϊκής Σύμβασης Διπλωμάτων Ευρεσιτεχνίας.
ΥΠΟΓΡΑΨΤΕ ΤΗΝ ΑΙΤΗΣΗhttp://petition.stopsoftwarepatents.eu/stats/
Διαβάστε περισσότερα εδώ http://press.ffii.org/Press_releases/European_Commission_pushes_for_software_patents_via_a_trusted_court
It's part of a message i received from Konstantina Zoehrer regarding the new "initiative" to get software patents in EU, through the backdoor by use of a "trusted court".
For more info check this link.
There is a petitionalso you can sign.
Well it looks like "special interests" follow the good old saying "if you fail once, try again"
So, let's try and stop them one more time.
Greek text follows
Προτρέπουμε τους νομοθέτες μας
* να περάσουν εθνικές νομικές διευκρινίσεις για το δίκαιο ευρεσιτεχνίας για να αποκλείσουν οποιοδήποτε πατέντα λογισμικού,
* να ακυρώσουν όλους τους εγκεκριμένους ισχυρισμούς για πατέντες που μπορεί να παραβιάζονται από λογισμικό το οποίο τρέχει σε προγραμματιζόμενες συσκευές,
* επίσης να αγωνιστούν για τη διάδοση των εν λόγω κανόνων σε Ευρωπαϊκό επίπεδο, συμπεριλαμβανομένης της Ευρωπαϊκής Σύμβασης Διπλωμάτων Ευρεσιτεχνίας.
ΥΠΟΓΡΑΨΤΕ ΤΗΝ ΑΙΤΗΣΗhttp://petition.stopsoftwarepatents.eu/stats/
Διαβάστε περισσότερα εδώ http://press.ffii.org/Press_releases/European_Commission_pushes_for_software_patents_via_a_trusted_court
Tuesday, June 2, 2009
First results on a WiFi security survey
For the past few weeks i am working on a paper for the security of the wifi networks.
Part of my research was to look at the state of security of deployed wifi AP all over Athens.
Athens is a rather large city (4+ million people leave here) and i believe that a sample of that size could be indicative of the general state if wifi all over.
The first results are rather mixed.
The good news is that the number of wifi ap's deployed is really large.
By driving through some of th main streets crossing Athens, and some of the business areas i found more that 10.000 unique MAC's of AP.
Considering that i only covered a very small portion of the Athens metropolitan area and was only driving on main roads, i estimate that the number of deployed AP will be over 200.000 to 250.000 and this is a really a very conservative estimate.
The bad news now.
More than 50% of the AP's surveyed,are using no encryption or WEP and from those using WPA 70% is using the default ESSID's set by the ISP's that provided the unit,making them easy targets for rainbow table attacks.
It looks like that most people trust the settings their ISP provides when they get their adsl IAD, or don't how to change them or simply are unaware of how wifi works and the dangers.
One ISP in particular seems to be the "king of unprotected wifi AP" in Athens as 3/4 of all the AP's with their ESSID is either open or using WEP.
I am still collecting data and working on the paper, but given the rather large number of samples i allready got i don't think the results will change much,but this is something to see.
On the funny side of things, if people do decide to change their ESSID they can be very creative :)
Part of my research was to look at the state of security of deployed wifi AP all over Athens.
Athens is a rather large city (4+ million people leave here) and i believe that a sample of that size could be indicative of the general state if wifi all over.
The first results are rather mixed.
The good news is that the number of wifi ap's deployed is really large.
By driving through some of th main streets crossing Athens, and some of the business areas i found more that 10.000 unique MAC's of AP.
Considering that i only covered a very small portion of the Athens metropolitan area and was only driving on main roads, i estimate that the number of deployed AP will be over 200.000 to 250.000 and this is a really a very conservative estimate.
The bad news now.
More than 50% of the AP's surveyed,are using no encryption or WEP and from those using WPA 70% is using the default ESSID's set by the ISP's that provided the unit,making them easy targets for rainbow table attacks.
It looks like that most people trust the settings their ISP provides when they get their adsl IAD, or don't how to change them or simply are unaware of how wifi works and the dangers.
One ISP in particular seems to be the "king of unprotected wifi AP" in Athens as 3/4 of all the AP's with their ESSID is either open or using WEP.
I am still collecting data and working on the paper, but given the rather large number of samples i allready got i don't think the results will change much,but this is something to see.
On the funny side of things, if people do decide to change their ESSID they can be very creative :)
Monday, May 11, 2009
First results and thoughs on WPA security
I have spend the last few days reading about and playing around with the various tools available for cracking WPA and here is what i came to.
Contrary to the "hype" WPA is not cracked, as WEP was.
No "fatal" design flaw has been found that can be exploited to get access to your wifi network.
The *current* and *known* (there is no way to emphasize this more) ways of getting access to WPA protected network is by the "old" way of the dictionary and/or brute force attacks and "rainbow tables".
That been send, the "weak link" in your WPA security is actual your chosen password.
If your password can be easily "guessed" (8 characters passwords with numbers (i.e bith dates) or known words like "/dev/null" :) then you might get into trouble if someone targets you.
Another thing that i realized is that by hiding your ESSID you are actually becoming an easier target to an attack.
This has to do with the fact that your ESSID is actually part of the key and the empty ESSID is on the top 10 of ESSID's people have pre-calculated rainbow tables for.
So to make your WPA wifi more secure do the following
1)Select a unique ESSID, an as attacker could not use a ready-made rainbow table, and would have to recalculate the PMK's and that can take some time, even with the help of Pyrit and some serious hardware.
2) Try to select a random password at least 20 characters long.
3) Switch to AES insted of TKIP
Contrary to the "hype" WPA is not cracked, as WEP was.
No "fatal" design flaw has been found that can be exploited to get access to your wifi network.
The *current* and *known* (there is no way to emphasize this more) ways of getting access to WPA protected network is by the "old" way of the dictionary and/or brute force attacks and "rainbow tables".
That been send, the "weak link" in your WPA security is actual your chosen password.
If your password can be easily "guessed" (8 characters passwords with numbers (i.e bith dates) or known words like "/dev/null" :) then you might get into trouble if someone targets you.
Another thing that i realized is that by hiding your ESSID you are actually becoming an easier target to an attack.
This has to do with the fact that your ESSID is actually part of the key and the empty ESSID is on the top 10 of ESSID's people have pre-calculated rainbow tables for.
So to make your WPA wifi more secure do the following
1)Select a unique ESSID, an as attacker could not use a ready-made rainbow table, and would have to recalculate the PMK's and that can take some time, even with the help of Pyrit and some serious hardware.
2) Try to select a random password at least 20 characters long.
3) Switch to AES insted of TKIP
Friday, May 8, 2009
Getting Pyrit to work on my system and other WPA-PSK related rand
Recently i started reading about WPA-PSK security, as a client was using it, in their office, and after some discussion, wanted to see how (in)secure might be.
After some reading it looks like the best way to hack a WPA-PSK based system (for the moment) is to create a rainbow table of possible PMK's (Pairwise Master Key) and then let loose tools like cowpatty and aircrack-ng.
Basically you exchange time for space, as the same PMK can be used on any AP with same SSID.
The problem is, that a PMK requires something in the range of 16.000+ rounds of SHA-1 and this requires some really big computing power.
To give you an idea of the computing power required, my quad core@3Ghz can do about 1.2K PMK's/sec,which is not that bad, but will take weeks to go over a descent word list.
Doing some more search i found that there is a program called Pyrit, that uses the power of the GPU to do some serious PMK crunching. My "vanilla" (not over clocked) Nvidia 8800 GT does 4.800/sec while other, newer Nvidia cards can reach close to 50.000/sec PMK's
UPDATE 17/5/2009
The problem mentioned below is solved in revision 99 of Pyrit
Looks like it was a CUDA 2.2 bug
I am leaving the text for 'historical reasons' but you can safely ignore the fix
So i updated my CUDA drivers and SDK (Pyrit requires CUDA 2,2), got Pyrit from the SVN, build it and run my first benchmark, using only the CPU's.
Things were good, so i moved on to build the Nvidia CUDA module for Pyrit.
The build was ok
but when trying to run the benchmark again i got an error
For some reason the CUDA part was failing to load.
Googling about the error, i found a couple others had the same issue, so it was not just me, doing something wrong.
I emailed the author, but received no reply, so after a day started looking at the code to see where the problem comes from. Open Source rulez :)
It turned out that the module failed to load the CUDA kernel.
Pyrit "converts" the CUDA cubit module to an include file _cpyrit_cudakernel.cubin.h and then uses the CUDA API to load the kernel module.
In my case ,For some reason the _cpyrit_cudakernel.cubin.h seems to have an invalid
cuda kernel image.
So i changed the part that loads the kernel in _cpyrit_cuda.c from the include file
to
(P.S add the correct path to your cubit file)
that loads the cubit file directly.
That got the problem fixed and benchmark worked like a charm
Haven't looked at why the _cpyrit_cudakernel.cubin.h has a corrupted
kernel, will probably do so, during the weekend and post any patches to fix it.
After some reading it looks like the best way to hack a WPA-PSK based system (for the moment) is to create a rainbow table of possible PMK's (Pairwise Master Key) and then let loose tools like cowpatty and aircrack-ng.
Basically you exchange time for space, as the same PMK can be used on any AP with same SSID.
The problem is, that a PMK requires something in the range of 16.000+ rounds of SHA-1 and this requires some really big computing power.
To give you an idea of the computing power required, my quad core@3Ghz can do about 1.2K PMK's/sec,which is not that bad, but will take weeks to go over a descent word list.
Doing some more search i found that there is a program called Pyrit, that uses the power of the GPU to do some serious PMK crunching. My "vanilla" (not over clocked) Nvidia 8800 GT does 4.800/sec while other, newer Nvidia cards can reach close to 50.000/sec PMK's
UPDATE 17/5/2009
The problem mentioned below is solved in revision 99 of Pyrit
Looks like it was a CUDA 2.2 bug
I am leaving the text for 'historical reasons' but you can safely ignore the fix
So i updated my CUDA drivers and SDK (Pyrit requires CUDA 2,2), got Pyrit from the SVN, build it and run my first benchmark, using only the CPU's.
Things were good, so i moved on to build the Nvidia CUDA module for Pyrit.
The build was ok
stelios@Athena:~/pyrit/pyrit-read-only/cpyrit_cuda$ ./setup.py build
running build
running build_ext
Compiling CUDA module using nvcc 2.2, V0.2.1221...
ptxas info : Compiling entry function 'cuda_pmk_kernel'
ptxas info : Used 42 registers, 32+24 bytes smem, 12 bytes cmem[1]
Building modules...
stelios@Athena:~/pyrit/pyrit-read-only/cpyrit_cuda$ sudo ./setup.py
install
running install
running build
running build_ext
Skipping rebuild of Nvidia CUDA kernel ...
Building modules...
running install_lib
running install_egg_info
Removing /usr/lib/python2.5/site-packages/CPyrit_CUDA-0.2.3.egg-info
Writing /usr/lib/python2.5/site-packages/CPyrit_CUDA-0.2.3.egg-info
but when trying to run the benchmark again i got an error
stelios@Athena:~/pyrit/pyrit-read-only/cpyrit_cuda$ pyrit benchmark
Pyrit 0.2.3 (C) 2008, 2009 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3
The ESSID-blobspace seems to be empty; you should create an ESSID...
Failed to load CUDA-core (CUDA_ERROR_INVALID_IMAGE).
Running benchmark for at least 60 seconds...
CPU-Core (x86_64): 302.43 PMKs/s, 99.41% occupancy
CPU-Core (x86_64): 292.03 PMKs/s, 90.08% occupancy
CPU-Core (x86_64): 300.92 PMKs/s, 87.42% occupancy
CPU-Core (x86_64): 303.17 PMKs/s, 99.17% occupancy
Benchmark done. 1198.55 PMKs/s total.
For some reason the CUDA part was failing to load.
Googling about the error, i found a couple others had the same issue, so it was not just me, doing something wrong.
I emailed the author, but received no reply, so after a day started looking at the code to see where the problem comes from. Open Source rulez :)
It turned out that the module failed to load the CUDA kernel.
Pyrit "converts" the CUDA cubit module to an include file _cpyrit_cudakernel.cubin.h and then uses the CUDA API to load the kernel module.
In my case ,For some reason the _cpyrit_cudakernel.cubin.h seems to have an invalid
cuda kernel image.
So i changed the part that loads the kernel in _cpyrit_cuda.c from the include file
ret = cuModuleLoadData(&self->mod, &__cudakernel_module);
to
ret = cuModuleLoad(&self->mod, "/your/path/to/cubitfile/_cpyrit_cudakernel.cubin");
(P.S add the correct path to your cubit file)
that loads the cubit file directly.
That got the problem fixed and benchmark worked like a charm
stelios@Athena:~/pyrit/pyrit-read-only/cpyrit_cuda$ pyrit benchmark
Pyrit 0.2.2 (C) 2008, 2009 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3
Running benchmark for at least 60 seconds...
CUDA-Device #1 'GeForce 8800 GT': 4796.11 PMKs/s, 89.75% occupancy
CPU-Core (x86_64): 283.45 PMKs/s, 84.37% occupancy
CPU-Core (x86_64): 298.66 PMKs/s, 96.09% occupancy
CPU-Core (x86_64): 289.44 PMKs/s, 99.15% occupancy
Benchmark done. 5667.66 PMKs/s total.
Haven't looked at why the _cpyrit_cudakernel.cubin.h has a corrupted
kernel, will probably do so, during the weekend and post any patches to fix it.
Friday, April 3, 2009
Cudos to Intersys for their support
Yesterday i received the replacement for my 42" Toshiba LCD TV from Intersys, the local Toshiba distributor.
Although i am kind of disappointed with Toshiba's quality, as this is the second TV from Toshiba with panel problems in 2 years, i am really pleased by the support i received from their local agent.
In both cases not only they exchange the TV but i received a newer model. (This time i got a Toshiba REGZA 42ZV555DG as a replacement for REGZA 42XV505DG i had )
Intersys acknowledging my frustration even offered to replace it with a different brand they distribute and a much larger TV (a 50" Panasonic plasma) but for a number of reasons i decided not to do so.
They have send the new TV to my home and picked up the old one, without having to pay anything, or go through hoops.
In difficult economic times like this, keeping the service and support level to your customers is really difficult, but at the same time its a very good way to keep customer loyalty.
Bad times are not going to last for ever and on when things turn better, i believe all this effort will payback.
Although i am kind of disappointed with Toshiba's quality, as this is the second TV from Toshiba with panel problems in 2 years, i am really pleased by the support i received from their local agent.
In both cases not only they exchange the TV but i received a newer model. (This time i got a Toshiba REGZA 42ZV555DG as a replacement for REGZA 42XV505DG i had )
Intersys acknowledging my frustration even offered to replace it with a different brand they distribute and a much larger TV (a 50" Panasonic plasma) but for a number of reasons i decided not to do so.
They have send the new TV to my home and picked up the old one, without having to pay anything, or go through hoops.
In difficult economic times like this, keeping the service and support level to your customers is really difficult, but at the same time its a very good way to keep customer loyalty.
Bad times are not going to last for ever and on when things turn better, i believe all this effort will payback.
Thursday, March 26, 2009
It's been almost a month since my last blog post...
Day to day work and my new pet project TwitXL are taking most of my time these days.
The Athens MediaCamp09 was a nice "distraction" also.
Met some very interesting people, with cool ideas.
I have several "half baked" posts that i need to finish and clear up so i can post them. Hope that i'll get some free time during next week.
Day to day work and my new pet project TwitXL are taking most of my time these days.
The Athens MediaCamp09 was a nice "distraction" also.
Met some very interesting people, with cool ideas.
I have several "half baked" posts that i need to finish and clear up so i can post them. Hope that i'll get some free time during next week.
Subscribe to:
Posts (Atom)
Posts
