Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Encryption and risk



I was thinking about this over night, and it really is both funny *and*
instructive for those with little security experience.

There is practically no way to come up with a usable 100% secure system.
There will always be an exploit. If not through the encryption algorithm
itself, through the implementation.

Take AES, and while my info may be dated, I still assume that it has not
been breeched algorithmically, but the breaches that have been seen have
been around implementations. The end result is the same, of course.

MD5 has been broken. That was always mathematically possible, just highly
improbable. GHZ processors make improbable somewhat more "likely."

If someone has custody of encrypted data for any non-trivial length of
time, you have to assume it can be broken.



> On Sat, Oct 3, 2009 at 12:23 PM, Mark Woodward <markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org>
> wrote:
>> Anyway, anyone interested in writing a really easy library as an open
>> source project?
>>
>> It should have:
>> ? ?Easily installable service modules
>> ? ?SSL/TLS Sockets
>
> please read
> http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing.html
> to avoid creating security holes.
>
>
> --
> Bill
> n1vux-WYrOkVUspZo at public.gmane.org bill.n1vux-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
>







BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org