a new 'Secret Key' Cryptographic Algorithm ~ any analysis/suggestions/weakness will be helpful ~ Variation of One-Time Pad
I agree completely with Claudio. You have to have a math-degree to design a
new algorithm.
Here is a open book to start with the basic theory behind cryptography
http://www.cacr.math.uwaterloo.ca/hac/
As you will see in the content, this is pure mathematics. I advise to use
minimal RC4, but better AES. I know it is block cipher, but you can also
stream with block ciphers.
Cheers,
DDT
Op schreef Claudio Telmon claudio@telmon.org:
I downloaded the code and simply tried to encode a block of zeroes... as
you can see if you look at the result with an hex editor, a clear
pattern appears in the cyphertext. See what happens instead if you try eg:
openssl enc -e -rc4 -in plain -out cypher
This is just to show that the fact that you're feeding the plaintext as
key, with minimal initialization, is weak and implies that both the key
and the cyphertext are almost as biased as the plaintext. BTW, I tried
to change the key from ABK to ACK, and a single bit changed as a
consequence in the cyphertext pattern. This is just to show that the
design is wrong, without going into math. Don't suppose that those
desining more complex algorythms do so because they don'y know better.
Not to be rude, but don't just try to change a couple of steps in your
code and resubmit: there's a lot of books and papers on cryptography,
this one has been recently recommended by a cryptographer on another
mailing list:
Regards,
- Claudio
--
Claudio Telmon
The Web Security Mailing List
WebSecurity RSS Feed
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 27 Apr 2011 09:55:36 +0530
"Abhishek [ABK] Kumar" abhikumar163@gmail.com wrote:
Making few things clear again:
First, it's a stream cipher... (though could be used as a block cipher
like others, as every Stream Cipher works on smallest block i.e.
bytes).
Currently it's just salted at the base and then an One-Time-Pad
(dynamically generated from from Key&Data) is XOR-ed to it. Some more
updates are pending to it once I'm sure with their effect.
--
Regards,
Abhishek Kumar
Yes, what you've built has nothing to do with one time pads (OTP). It
is a data-dependant stream cipher. The keying isn't salting but
seeding.
As it stands right now it's totally broken. For example, if you
encrypt a file full of NULLs you get:
00000000 00 00 00 bf be b5 bf be b5 bf be b5 bf be b5 bf |................|
00000010 be b5 bf be b5 bf be b5 bf be b5 bf be b5 bf be |................|
00000020 b5 bf be b5 bf be b5 bf be b5 bf be b5 bf be b5 |................|
00000030 bf be b5 bf be b5 bf be b5 bf be b5 bf be b5 bf |................|
00000040 be b5 bf be b5 bf be b5 bf be b5 bf be b5 bf be |................|
00000050 b5 bf be b5 bf be b5 bf be b5 bf be b5 bf be b5 |................|
The reason the first three bytes of the stream are null is that you key
"ABK" is three bytes and in a loop you do:
char new_chr = buf^new_secret[sec_idx];
new_chr = (char)((int)new_chr-(int)secret[sec_idx]);
new_secret[sec_idx]=buf;
So 0 ^ 'A' = A
And then A - A = 0
The same goes for B and K. Worse, you let at attacker control how the
stream evolves by setting new_secret[] to plaintext input.
That means that after K null bytes where K is the key size, the
internal state is set to all NULLs. At that point another K bytes will
reveal the original key.
So for example, I set the key to some unknown "secret" and I encrypt a
series of NULL bytes:
00000000 00 00 00 00 00 00 00 00 00 00 8c 98 97 8d 97 8d |................|
00000010 8d 98 97 8c 8c 98 97 8d 97 8d 8d 98 97 8c 8c 98 |................|
00000020 97 8d 97 8d 8d 98 97 8c 8c 98 97 8d 97 8d 8d 98 |................|
00000030 97 8c 8c 98 97 8d 97 8d 8d 98 97 8c 8c 98 97 8d |................|
00000040 97 8d 8d 98 97 8c 8c 98 97 8d 97 8d 8d 98 97 8c |................|
00000050 8c 98 97 8d 97 8d 8d 98 97 8c 8c 98 97 8d 97 8d |................|
As you can see the pattern "8c 98 97 8d 97 8d 8d 98 97 8c" emerges.
This is 0 - key byte. To recover the original key either do some basic
math or set the new key to "\x8c\x98\x97\x8d\x97\x8d\x8d\x98\x97\x8c\0"
and encrypt another file full of NULLs.
Here, I have done it for you:
00000000 00 00 00 00 00 00 00 00 00 00 74 68 69 73 69 73 |..........thisis|
00000010 73 68 69 74 74 68 69 73 69 73 73 68 69 74 74 68 |shitthisisshitth|
00000020 69 73 69 73 73 68 69 74 74 68 69 73 69 73 73 68 |isisshitthisissh|
00000030 69 74 74 68 69 73 69 73 73 68 69 74 74 68 69 73 |itthisisshitthis|
00000040 69 73 73 68 69 74 74 68 69 73 69 73 73 68 69 74 |isshitthisisshit|
00000050 74 68 69 73 69 73 73 68 69 74 74 68 69 73 69 73 |thisisshitthisis|
Note that this "attack" can be done at any point in the plaintext. So
if you encrypt a file with a long string of NULLs (say, a Windows
executable) you will reveal the original key.
Unless you are an expert (you are not), do not ever try to build
encryption yourself. This is why.
Brandon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iEYEARECAAYFAk2/XRgACgkQqaGPzAsl94LaMQCeNPqpxAIMOpu3Z3apTjjmPg8f
vtwAoJO0DtAvlT/SNl7mSdsj+LRSY1TH
=T+jj
-----END PGP SIGNATURE-----
*Note that this "attack" can be done at any point in the plaintext. So
if you encrypt a file with a long string of NULLs (say, a Windows
executable) you will reveal the original key.
*
First of all,* serious thanks for analyzing this algorithm* and pointing out
the flaws... at least after this may be replies to this thread would
remember that...
This algorithm is currently developed with a specific scenario-based
use-case (which I've mentioned already) requirement and that scenario in no
case entertains Chosen-Plaintext(etc. etc.) attacks.* The most attacker can
do in it's use-case, at a Pattern-Based approach is collect random
cipher-text (and not a cipher to given plain-text) and analyze it.*
* Unless you are an expert (you are not), do not ever try to build
encryption yourself. This is why.
*
I never replied here as if I'm an Expert, but what I said was an enthusiast
with proper training (that makes me non-novice not an expert... practice
would make me so, and I wouldn't leave that) .
--
Regards,
Abhishek Kumar
https://sites.google.com/site/abhikumar163/
--
--------------ABK-----mail.signature--------------------
<http://www.blogger.com/profile/06276198262605731980><http://abhishekkr.deviantart.com/><http://www.facebook.com/aBionic><http://www.twitter.com/aBionic><http://sourceforge.net/users/abhishekkr><http://www.youtube.com/user/1ABK><http://in.linkedin.com/in/abionic>
-----------------------------------------------------------
~=ABK=~
On Tue, May 3, 2011 at 7:10 AM, Brandon Enright <bmenrigh@ucsd.edu> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 27 Apr 2011 09:55:36 +0530
"Abhishek [ABK] Kumar" abhikumar163@gmail.com wrote:
Making few things clear again:
First, it's a stream cipher... (though could be used as a block cipher
like others, as every Stream Cipher works on smallest block i.e.
bytes).
Currently it's just salted at the base and then an One-Time-Pad
(dynamically generated from from Key&Data) is XOR-ed to it. Some more
updates are pending to it once I'm sure with their effect.
--
Regards,
Abhishek Kumar
Yes, what you've built has nothing to do with one time pads (OTP). It
is a data-dependant stream cipher. The keying isn't salting but
seeding.
As it stands right now it's totally broken. For example, if you
encrypt a file full of NULLs you get:
00000000 00 00 00 bf be b5 bf be b5 bf be b5 bf be b5 bf
|................|
00000010 be b5 bf be b5 bf be b5 bf be b5 bf be b5 bf be
|................|
00000020 b5 bf be b5 bf be b5 bf be b5 bf be b5 bf be b5
|................|
00000030 bf be b5 bf be b5 bf be b5 bf be b5 bf be b5 bf
|................|
00000040 be b5 bf be b5 bf be b5 bf be b5 bf be b5 bf be
|................|
00000050 b5 bf be b5 bf be b5 bf be b5 bf be b5 bf be b5
|................|
The reason the first three bytes of the stream are null is that you key
"ABK" is three bytes and in a loop you do:
char new_chr = buf^new_secret[sec_idx];
new_chr = (char)((int)new_chr-(int)secret[sec_idx]);
new_secret[sec_idx]=buf;
So 0 ^ 'A' = A
And then A - A = 0
The same goes for B and K. Worse, you let at attacker control how the
stream evolves by setting new_secret[] to plaintext input.
That means that after K null bytes where K is the key size, the
internal state is set to all NULLs. At that point another K bytes will
reveal the original key.
So for example, I set the key to some unknown "secret" and I encrypt a
series of NULL bytes:
00000000 00 00 00 00 00 00 00 00 00 00 8c 98 97 8d 97 8d
|................|
00000010 8d 98 97 8c 8c 98 97 8d 97 8d 8d 98 97 8c 8c 98
|................|
00000020 97 8d 97 8d 8d 98 97 8c 8c 98 97 8d 97 8d 8d 98
|................|
00000030 97 8c 8c 98 97 8d 97 8d 8d 98 97 8c 8c 98 97 8d
|................|
00000040 97 8d 8d 98 97 8c 8c 98 97 8d 97 8d 8d 98 97 8c
|................|
00000050 8c 98 97 8d 97 8d 8d 98 97 8c 8c 98 97 8d 97 8d
|................|
As you can see the pattern "8c 98 97 8d 97 8d 8d 98 97 8c" emerges.
This is 0 - key byte. To recover the original key either do some basic
math or set the new key to "\x8c\x98\x97\x8d\x97\x8d\x8d\x98\x97\x8c\0"
and encrypt another file full of NULLs.
Here, I have done it for you:
00000000 00 00 00 00 00 00 00 00 00 00 74 68 69 73 69 73
|..........thisis|
00000010 73 68 69 74 74 68 69 73 69 73 73 68 69 74 74 68
|shitthisisshitth|
00000020 69 73 69 73 73 68 69 74 74 68 69 73 69 73 73 68
|isisshitthisissh|
00000030 69 74 74 68 69 73 69 73 73 68 69 74 74 68 69 73
|itthisisshitthis|
00000040 69 73 73 68 69 74 74 68 69 73 69 73 73 68 69 74
|isshitthisisshit|
00000050 74 68 69 73 69 73 73 68 69 74 74 68 69 73 69 73
|thisisshitthisis|
Note that this "attack" can be done at any point in the plaintext. So
if you encrypt a file with a long string of NULLs (say, a Windows
executable) you will reveal the original key.
Unless you are an expert (you are not), do not ever try to build
encryption yourself. This is why.
Brandon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iEYEARECAAYFAk2/XRgACgkQqaGPzAsl94LaMQCeNPqpxAIMOpu3Z3apTjjmPg8f
vtwAoJO0DtAvlT/SNl7mSdsj+LRSY1TH
=T+jj
-----END PGP SIGNATURE-----
If you want to practice to get better at designing ciphers, implement FEAL-4 (you can do it in about 30 lines of Python) and write working code for the various attacks on it. You can configure FEAL as a stream cipher, if that's the only thing you're interested in playing with.
Your current strategy for "practicing" is a very bad one that will not work out for you.
On May 3, 2011, at 4:48 AM, Abhishek [ABK] Kumar wrote:
Note that this "attack" can be done at any point in the plaintext. So
if you encrypt a file with a long string of NULLs (say, a Windows
executable) you will reveal the original key.
First of all, serious thanks for analyzing this algorithm and pointing out the flaws... at least after this may be replies to this thread would remember that...
This algorithm is currently developed with a specific scenario-based use-case (which I've mentioned already) requirement and that scenario in no case entertains Chosen-Plaintext(etc. etc.) attacks. The most attacker can do in it's use-case, at a Pattern-Based approach is collect random cipher-text (and not a cipher to given plain-text) and analyze it.
~~~~~~~~~~
Unless you are an expert (you are not), do not ever try to build encryption yourself. This is why.
I never replied here as if I'm an Expert, but what I said was an enthusiast with proper training (that makes me non-novice not an expert... practice would make me so, and I wouldn't leave that) .
~~~~~~~~~~
Regards,
Abhishek Kumar
https://sites.google.com/site/abhikumar163/
--
--------------ABK-----mail.signature--------------------
~=ABK=~
On Tue, May 3, 2011 at 7:10 AM, Brandon Enright bmenrigh@ucsd.edu wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 27 Apr 2011 09:55:36 +0530
"Abhishek [ABK] Kumar" abhikumar163@gmail.com wrote:
Making few things clear again:
First, it's a stream cipher... (though could be used as a block cipher
like others, as every Stream Cipher works on smallest block i.e.
bytes).
Currently it's just salted at the base and then an One-Time-Pad
(dynamically generated from from Key&Data) is XOR-ed to it. Some more
updates are pending to it once I'm sure with their effect.
--
Regards,
Abhishek Kumar
Yes, what you've built has nothing to do with one time pads (OTP). It
is a data-dependant stream cipher. The keying isn't salting but
seeding.
As it stands right now it's totally broken. For example, if you
encrypt a file full of NULLs you get:
00000000 00 00 00 bf be b5 bf be b5 bf be b5 bf be b5 bf |................|
00000010 be b5 bf be b5 bf be b5 bf be b5 bf be b5 bf be |................|
00000020 b5 bf be b5 bf be b5 bf be b5 bf be b5 bf be b5 |................|
00000030 bf be b5 bf be b5 bf be b5 bf be b5 bf be b5 bf |................|
00000040 be b5 bf be b5 bf be b5 bf be b5 bf be b5 bf be |................|
00000050 b5 bf be b5 bf be b5 bf be b5 bf be b5 bf be b5 |................|
The reason the first three bytes of the stream are null is that you key
"ABK" is three bytes and in a loop you do:
char new_chr = buf^new_secret[sec_idx];
new_chr = (char)((int)new_chr-(int)secret[sec_idx]);
new_secret[sec_idx]=buf;
So 0 ^ 'A' = A
And then A - A = 0
The same goes for B and K. Worse, you let at attacker control how the
stream evolves by setting new_secret[] to plaintext input.
That means that after K null bytes where K is the key size, the
internal state is set to all NULLs. At that point another K bytes will
reveal the original key.
So for example, I set the key to some unknown "secret" and I encrypt a
series of NULL bytes:
00000000 00 00 00 00 00 00 00 00 00 00 8c 98 97 8d 97 8d |................|
00000010 8d 98 97 8c 8c 98 97 8d 97 8d 8d 98 97 8c 8c 98 |................|
00000020 97 8d 97 8d 8d 98 97 8c 8c 98 97 8d 97 8d 8d 98 |................|
00000030 97 8c 8c 98 97 8d 97 8d 8d 98 97 8c 8c 98 97 8d |................|
00000040 97 8d 8d 98 97 8c 8c 98 97 8d 97 8d 8d 98 97 8c |................|
00000050 8c 98 97 8d 97 8d 8d 98 97 8c 8c 98 97 8d 97 8d |................|
As you can see the pattern "8c 98 97 8d 97 8d 8d 98 97 8c" emerges.
This is 0 - key byte. To recover the original key either do some basic
math or set the new key to "\x8c\x98\x97\x8d\x97\x8d\x8d\x98\x97\x8c\0"
and encrypt another file full of NULLs.
Here, I have done it for you:
00000000 00 00 00 00 00 00 00 00 00 00 74 68 69 73 69 73 |..........thisis|
00000010 73 68 69 74 74 68 69 73 69 73 73 68 69 74 74 68 |shitthisisshitth|
00000020 69 73 69 73 73 68 69 74 74 68 69 73 69 73 73 68 |isisshitthisissh|
00000030 69 74 74 68 69 73 69 73 73 68 69 74 74 68 69 73 |itthisisshitthis|
00000040 69 73 73 68 69 74 74 68 69 73 69 73 73 68 69 74 |isshitthisisshit|
00000050 74 68 69 73 69 73 73 68 69 74 74 68 69 73 69 73 |thisisshitthisis|
Note that this "attack" can be done at any point in the plaintext. So
if you encrypt a file with a long string of NULLs (say, a Windows
executable) you will reveal the original key.
Unless you are an expert (you are not), do not ever try to build
encryption yourself. This is why.
Brandon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iEYEARECAAYFAk2/XRgACgkQqaGPzAsl94LaMQCeNPqpxAIMOpu3Z3apTjjmPg8f
vtwAoJO0DtAvlT/SNl7mSdsj+LRSY1TH
=T+jj
-----END PGP SIGNATURE-----
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
Thomas Ptacek // matasano security // founder, product manager
reach me direct: 888-677-0666 x7805
"The truth will set you free. But not until it is finished with you."
*Your current strategy for "practicing" is a very bad one that will not
work out for you. *
Now its the limit of making one simple thing clear from different
point-of-views... now, yeah I'm trying an evolving approach towards this
cipher and several other things that I mentioned... I also mentioned
(several times) that I'm going to use it in one of my personal project (from
where it all started) and it's well suited for it.
Currently it's not "Any Use-Case Cipher", and thus seems insecure... but not
if looked into the use-case I earlier referred to.
--
Regards,
Abhishek Kumar
https://sites.google.com/site/abhikumar163/
--
--------------ABK-----mail.signature--------------------
http://www.blogger.com/profile/06276198262605731980http://abhishekkr.deviantart.com/http://www.facebook.com/aBionichttp://www.twitter.com/aBionichttp://sourceforge.net/users/abhishekkrhttp://www.youtube.com/user/1ABKhttp://in.linkedin.com/in/abionic
~=ABK=~
On Tue, May 3, 2011 at 10:24 PM, Thomas Ptacek thomas@matasano.com wrote:
If you want to practice to get better at designing ciphers, implement
FEAL-4 (you can do it in about 30 lines of Python) and write working code
for the various attacks on it. You can configure FEAL as a stream cipher, if
that's the only thing you're interested in playing with.
Your current strategy for "practicing" is a very bad one that will not work
out for you.
On May 3, 2011, at 4:48 AM, Abhishek [ABK] Kumar wrote:
*Note that this "attack" can be done at any point in the plaintext. So
if you encrypt a file with a long string of NULLs (say, a Windows
executable) you will reveal the original key.
*
First of all,* serious thanks for analyzing this algorithm* and pointing
out the flaws... at least after this may be replies to this thread would
remember that...
This algorithm is currently developed with a specific scenario-based
use-case (which I've mentioned already) requirement and that scenario in no
case entertains Chosen-Plaintext(etc. etc.) attacks.* The most attacker
can do in it's use-case, at a Pattern-Based approach is collect random
cipher-text (and not a cipher to given plain-text) and analyze it.*
~~~~~~~~~~
- Unless you are an expert (you are not), do not ever try to build
encryption yourself. This is why.
*
I never replied here as if I'm an Expert, but what I said was an enthusiast
with proper training (that makes me non-novice not an expert... practice
would make me so, and I wouldn't leave that) .
~~~~~~~~~~
Regards,
Abhishek Kumar
https://sites.google.com/site/abhikumar163/
--
--------------ABK-----mail.signature--------------------
http://www.blogger.com/profile/06276198262605731980http://abhishekkr.deviantart.com/http://www.facebook.com/aBionichttp://www.twitter.com/aBionichttp://sourceforge.net/users/abhishekkrhttp://www.youtube.com/user/1ABKhttp://in.linkedin.com/in/abionic
~=ABK=~
On Tue, May 3, 2011 at 7:10 AM, Brandon Enright bmenrigh@ucsd.edu wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 27 Apr 2011 09:55:36 +0530
"Abhishek [ABK] Kumar" abhikumar163@gmail.com wrote:
Making few things clear again:
First, it's a stream cipher... (though could be used as a block cipher
like others, as every Stream Cipher works on smallest block i.e.
bytes).
Currently it's just salted at the base and then an One-Time-Pad
(dynamically generated from from Key&Data) is XOR-ed to it. Some more
updates are pending to it once I'm sure with their effect.
--
Regards,
Abhishek Kumar
Yes, what you've built has nothing to do with one time pads (OTP). It
is a data-dependant stream cipher. The keying isn't salting but
seeding.
As it stands right now it's totally broken. For example, if you
encrypt a file full of NULLs you get:
00000000 00 00 00 bf be b5 bf be b5 bf be b5 bf be b5 bf
|................|
00000010 be b5 bf be b5 bf be b5 bf be b5 bf be b5 bf be
|................|
00000020 b5 bf be b5 bf be b5 bf be b5 bf be b5 bf be b5
|................|
00000030 bf be b5 bf be b5 bf be b5 bf be b5 bf be b5 bf
|................|
00000040 be b5 bf be b5 bf be b5 bf be b5 bf be b5 bf be
|................|
00000050 b5 bf be b5 bf be b5 bf be b5 bf be b5 bf be b5
|................|
The reason the first three bytes of the stream are null is that you key
"ABK" is three bytes and in a loop you do:
char new_chr = buf^new_secret[sec_idx];
new_chr = (char)((int)new_chr-(int)secret[sec_idx]);
new_secret[sec_idx]=buf;
So 0 ^ 'A' = A
And then A - A = 0
The same goes for B and K. Worse, you let at attacker control how the
stream evolves by setting new_secret[] to plaintext input.
That means that after K null bytes where K is the key size, the
internal state is set to all NULLs. At that point another K bytes will
reveal the original key.
So for example, I set the key to some unknown "secret" and I encrypt a
series of NULL bytes:
00000000 00 00 00 00 00 00 00 00 00 00 8c 98 97 8d 97 8d
|................|
00000010 8d 98 97 8c 8c 98 97 8d 97 8d 8d 98 97 8c 8c 98
|................|
00000020 97 8d 97 8d 8d 98 97 8c 8c 98 97 8d 97 8d 8d 98
|................|
00000030 97 8c 8c 98 97 8d 97 8d 8d 98 97 8c 8c 98 97 8d
|................|
00000040 97 8d 8d 98 97 8c 8c 98 97 8d 97 8d 8d 98 97 8c
|................|
00000050 8c 98 97 8d 97 8d 8d 98 97 8c 8c 98 97 8d 97 8d
|................|
As you can see the pattern "8c 98 97 8d 97 8d 8d 98 97 8c" emerges.
This is 0 - key byte. To recover the original key either do some basic
math or set the new key to "\x8c\x98\x97\x8d\x97\x8d\x8d\x98\x97\x8c\0"
and encrypt another file full of NULLs.
Here, I have done it for you:
00000000 00 00 00 00 00 00 00 00 00 00 74 68 69 73 69 73
|..........thisis|
00000010 73 68 69 74 74 68 69 73 69 73 73 68 69 74 74 68
|shitthisisshitth|
00000020 69 73 69 73 73 68 69 74 74 68 69 73 69 73 73 68
|isisshitthisissh|
00000030 69 74 74 68 69 73 69 73 73 68 69 74 74 68 69 73
|itthisisshitthis|
00000040 69 73 73 68 69 74 74 68 69 73 69 73 73 68 69 74
|isshitthisisshit|
00000050 74 68 69 73 69 73 73 68 69 74 74 68 69 73 69 73
|thisisshitthisis|
Note that this "attack" can be done at any point in the plaintext. So
if you encrypt a file with a long string of NULLs (say, a Windows
executable) you will reveal the original key.
Unless you are an expert (you are not), do not ever try to build
encryption yourself. This is why.
Brandon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iEYEARECAAYFAk2/XRgACgkQqaGPzAsl94LaMQCeNPqpxAIMOpu3Z3apTjjmPg8f
vtwAoJO0DtAvlT/SNl7mSdsj+LRSY1TH
=T+jj
-----END PGP SIGNATURE-----
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
Thomas Ptacek // matasano security // founder, product manager
reach me direct: 888-677-0666 x7805
"The truth will set you free. But not until it is finished with you."