how safe is xor encryption ?
Mark-Jason Dominus
Elaine -HappyFunBall- Ashton <eas...@bbnplanet.com> wrote:
>Your assumptions are dangerously ignorant. I am offended by anyone who
>puts CC data onine without SSL or better and thinks that it is
>sufficient.
The querent is talking about storing the credit card numbers in a
database in encrypted format, as an extra protection in case the
database file falls into the wrong hands. I don't see what SSL has
to do with it.
Mark-Jason Dominus
>say, a cracker has somehow reached to the database, full of credit card
>numbers encrypted in that manner.
1. If the cracker knows any one entire credit card number, perhaps
because they inserted it themselves, they can easily figure out
what your secret pad is, and decrypt all the other numbers.
2. A cracker who has gotten into the database has probably also gotten
into your source code.
>well, do all what i've talked about make sense? anything wrong you see?
The whole exercise seems rather futile.
bey...@my-dejanews.com
I am about to write a simple script to encrypt/decrypt credit card numbers
using xor and a key supplied by credit card owner. I wanted to learn your
thoughts about it:
CC owner will supply a phrase, credit card security code (CCSC)
credit card numbers are like: 1234 1234 1234 1234
$cc="1234123412341234";
$ccsc="merhaba istanbul"
(if length of CCSC is smaller than CC number's length, i will extend it to fit
in such a way that i have not thougth about yet)
$enc = $cc ^ $ccsc;
...store $enc to a database..
...later on..
$dec = $enc ^ $ccsc;
...use cc# to make transaction
I have figured out that bitwise XORing will xor characters using their ASCII
codes. for simplicity in explaining, if i write the first characters of two
operands in XORing operation above:
1 -> 00110001
m -> 01101101
xor
--------------------------
\ 01011100 (encrypted)
say, a cracker has somehow reached to the database, full of credit card
numbers encrypted in that manner.
s/he will see the "\" character. s/he needs character "m" to reach the credit
card number. Because, credit card numbers are made of only digits, for each
character she will have 10 possibility.
"\" xor XX = [0-9]
each digit's ASCII code has a common part:
0 - 00110000
1 - 00110001
. - 0011....
9 - 00111001
she knows "\" already: 01011100
thus s/he can immediately deduce the first 4 bits of XX:
01011100
xor XX
-----------------
0011[0-9]
the first 4 bits must be 0110 in order to have a "digit" result after an xor
with "\" character.
That's why s/he has 10 possibility for each character (instead of all 256)
Even after that reduction, since CC numbers are 16 digits (as far as I know),
the possibility of finding the correct number is:
10*10*10....10 (16 10's multiplied)
that number looks pretty safe??
if you are at that line, thanks for your patience :)
well, do all what i've talked about make sense? anything wrong you see?
thanks
ersin
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Elaine -HappyFunBall- Ashton
> well, do all what i've talked about make sense? anything wrong you see?
Your assumptions are dangerously ignorant. I am offended by anyone who
puts CC data onine without SSL or better and thinks that it is
sufficient. As someone who has been in some distress over the failing of
system security, I would suggest having a much closer look at what is
the weakness in your proposition. I think it should be obvious. Personal
CC data is not to be taken lightly. Would you give your CC number
on-line given your script? I think not.
e.
"All of us, all of us, all of us trying to save our immortal souls, some
ways seemingly more round-about and mysterious than others. We're having
a good time here. But hope all will be revealed soon." R. Carver
Elaine -HappyFunBall- Ashton
> The querent is talking about storing the credit card numbers in a
> database in encrypted format, as an extra protection in case the
> database file falls into the wrong hands. I don't see what SSL has
> to do with it.
The 'querant' I assumed was taking the cc info over the web, if not, my
mistake. Either way, I deal with "e-commerce" jockeys every day whom I
could take advantage of every day. Hello, does anyone realise the
seriousness of credit cards on the net when so many "webmasters" still
don't understand why 777 isn't an acceptable mode? Even encrypted it can
be compromised. If it is on-line, it is insecure. There is no such thing
as on-line security when it comes to financial data. At least not what I
have observed. There are too many amateurs thinking as you do. Take my
point.a
Elaine -HappyFunBall- Ashton
> 1. If the cracker knows any one entire credit card number, perhaps
> because they inserted it themselves, they can easily figure out
> what your secret pad is, and decrypt all the other numbers.
>
> 2. A cracker who has gotten into the database has probably also gotten
> into your source code.
A light dawns.
> The whole exercise seems rather futile.
Bingo. Not futile, but certainly enlightening. Please, with as many
people I have taken issue with over CC security, you don't even want to
start with me. _NOT_ for the beginners. GRRRR. Also, 1 is not always
equal to 2 but 2 is certainly leading to 1. :)
Mark-Jason Dominus
>mistake.
Yes, it was your mistake.
Perhaps he was taking credit card numbers over the web; perhaps not.
If he was, perhaps he was using strong encryption methods to tranfer
them. I don't know, and neither do you; the question was about
something else.
> There are too many amateurs thinking as you do.
I'm not sure what you mean to imply here. If you meant to say that
any amateur would think that you had missed the point of the question,
then I agree.
Since that was the only thing I said, I don't know what else you
might have meant.
Ronald J Kimball
> I am about to write a simple script to encrypt/decrypt credit card numbers
> using xor and a key supplied by credit card owner. I wanted to learn your
> thoughts about it:
What exactly is your Perl question?
If I'm not mistaken, xor encryption could be implemented in any
programming language. Thus, this is not a Perl issue at all. Try a
security or encryption newsgroup.
--
_ / ' _ / - aka - r...@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chip...@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
Allan Peda
call to rand(). Save the encrypted key in another database, perhaps
on another machine? There is also a module called Crypt.
In any event it's a heck of a lot better than XOR
Jim Michael
>
> >say, a cracker has somehow reached to the database, full of credit card
> >numbers encrypted in that manner.
>
> because they inserted it themselves, they can easily figure out
> what your secret pad is, and decrypt all the other numbers.
It was proposed that each CC# would be encrypted using a different key
supplied by the CC owner (CC owner will supply a phrase, credit card
security code (CCSC): $enc = $cc ^ $ccsc;), so deciphering one would not
supply the key to the others. However, CC#s have a common beginning
number sequence which identifies the CC type (MC, Visa, etc.), do they
not? By xor'ing these beginning sequences you may be able to guess the
ending sequence in many cases (people tend to use common words or
phrases for passwords) or greatly reduce the search space.
> 2. A cracker who has gotten into the database has probably also gotten
> into your source code.
Or your keys.
Cheers,
Jim
bbense+comp.lang.p...@telemark.stanford.edu
In article <35ff839e...@news.interport.net>,
Allan Peda <al...@interport.net> wrote:
>As a first guess... look into calling crypt() on a key generated by a
>call to rand(). Save the encrypted key in another database, perhaps
>on another machine? There is also a module called Crypt.
>
>In any event it's a heck of a lot better than XOR
- - Actually xor is perfect security if it's used correctly.
Unfortunately it's almost impossible to get a sufficiently
random set of key data and it's horrible security if used
incorrectly. In this case it almost makes sense, the problem
is with usablity.
- - The programmer is terribly naive about users if he thinks
that asking them for a string the length of their CC # + expiration
data is a workable solution. How are they going to remember it?
If he stores the key on the machine the encryption is useless.
- - The best reference on actually using encryption is
"Applied Cryptography", by Bruce Schneier
- - If the key and the encrypted data exist on the same machine
you don't gain any security from hackers. What you do gain is
a reduction in the internal "temptation" factor, sysadmins can't
inadvertantly see personal data. It requires that they demonstrate
intent to aquire the data.
- - Booker C. Bense
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNf/F9AD83u1ILnWNAQE3CwQA13j5OOlYmNj2kd01UR8ujlP5xw24z2JC
iLD8UYdJWd8CTalbPS53we7YRea2Ou/mOumNblSHXqlb5y59bGiUDMV8spR9+pZ/
oA1Z+EYgkyQKOLw7qbeSPyuXi7TaNbSlK42n+DlyPvmFo6yXGNzrGO+WgL+Rjwyz
DXhpNmw79vM=
=hBT5
-----END PGP SIGNATURE-----
Elaine -HappyFunBall- Ashton
> I'm not sure what you mean to imply here. If you meant to say that
> any amateur would think that you had missed the point of the question,
> then I agree.
>
> Since that was the only thing I said, I don't know what else you
> might have meant.
Yes, I probably missed the point of the question, which I believe to
have been 'How do I encrypt data over the web for credit cards'. I
perhaps overreacted but this is a bit of a mission for me. It's not that
I don't want e-commerce, but I want it to be done in a secure, sane way.
If I got the person to think about this, then it wasn't just so many
bits in the aether. If it is on-line, it is insecure. Period.
Mark-Jason Dominus
>It was proposed that each CC# would be encrypted using a different key
>supplied by the CC owner
Thanks; I missed that. It sounds a lot more useful to me now. For
example, suppose you collected the CC#s out of band, perhaps over the
phone. Then the users would never need to send CC#s over the
internet, only their pad keys. Even if sent insecurely, a snooper is
unlikely to get any value from the pad key; to do so, they must
intercept a pad key *and* acquire your database.
>However, CC#s have a common beginning number sequence which
>identifies the CC type (MC, Visa, etc.), do they not?
Yes, but I think it's only one digit long. Perhaps someone can confirm?
In any event, stronger encryption is probably more useful here.
For example, you might use the user-supplied phrase as a key for
DES-encrypting the credit card number. This is less likely to be
subject to this sort of attack.
>> 2. A cracker who has gotten into the database has probably also gotten
>> into your source code.
>
>Or your keys.
Yes, a malevolent person on your machine probably has several paths
of access to the information.
Encrypting the numbers in the database, and transmitting only the
decryption key, rather than the actual number, seems prudent to me.
Is there some problem I'm overlooking?
Abigail
in <URL: news:35FFB3...@gecm.com>:
++ Mark-Jason Dominus wrote:
++ >
++ > >say, a cracker has somehow reached to the database, full of credit card
++ > >numbers encrypted in that manner.
++ >
++ > 1. If the cracker knows any one entire credit card number, perhaps
++ > because they inserted it themselves, they can easily figure out
++ > what your secret pad is, and decrypt all the other numbers.
++
++ It was proposed that each CC# would be encrypted using a different key
++ supplied by the CC owner (CC owner will supply a phrase, credit card
++ security code (CCSC): $enc = $cc ^ $ccsc;), so deciphering one would not
++ supply the key to the others. However, CC#s have a common beginning
++ number sequence which identifies the CC type (MC, Visa, etc.), do they
++ not? By xor'ing these beginning sequences you may be able to guess the
++ ending sequence in many cases (people tend to use common words or
++ phrases for passwords) or greatly reduce the search space.
But assuming that the key has the same length as the CC#, that piece
of information gains you exactly nothing.
However, what do you gain by encrypting each CC# with a different key?
Instead of stealing the CC#, all they have to do is steal the CC#, key
combo. A task which isn't significantly harder than just stealing the
CC#. Unless you somehow have a way to store keys in a more secure way
than CC#.
Abigail
--
perl5.004 -wMMath::BigInt -e'$^V=new Math::BigInt+qq;$^F$^W783$[$%9889$^F47$|88768$^W596577669$%$^W5$^F3364$[$^W$^F$|838747$[8889739$%$|$^F673$%$^W98$^F76777$=56;;$^U=substr($]=>$|=>5)*(q.25..($^W=@^V))=>do{print+chr$^V%$^U;$^V/=$^U}while$^V!=$^W'
Michael J Gebis
}I am about to write a simple script to encrypt/decrypt credit card numbers
}using xor and a key supplied by credit card owner. I wanted to learn your
}thoughts about it:
Why are you home-brewing your own encryption when there is so much
good code available? It's HARD to get this stuff right--a lot of very
smart people have gotten it wrong in the past. Use proven
techniques.
}10*10*10....10 (16 10's multiplied)
}that number looks pretty safe??
It appears to me that your method is vulnerable (at least) to a
dictionary attack.
--
Mike Gebis ge...@ecn.purdue.edu mge...@eternal.net
bey...@my-dejanews.com
m...@op.net (Mark-Jason Dominus) wrote:
>
> >say, a cracker has somehow reached to the database, full of credit card
>
hi,
one thing i could not emphisize may be is that, there will not be "one" key
for all credit card numbers. each credit card number will have a unique key
that will be supplied by the owner. this key will not be stored in anywhere,
the key is not generated from credit card number but entered by the owner, so
there is no way to figure out what the key is by just looking at the credit
card number (say they inserted it themselves and now what the number is..).
again, the key is not a hard coded key in anywhere.
> 2. A cracker who has gotten into the database has probably also gotten
> into your source code.
sure! but the secret key is not stored anywhere, neither in database nor in
source code.. that's why even the programmer or the system admin will be able
to now what the secret key is and decrypt the credit card number. the credit
card owner determines the secret key of his/her CC number and in each
transaction, s/he enters that key and decryption occurs only at that moment.
> >well, do all what i've talked about make sense? anything wrong you see?
>
> The whole exercise seems rather futile.
thanks anyway
Abigail
<URL: news:6tom8m$4fp$1...@monet.op.net>:
++ In article <35FFB3...@gecm.com>, Jim Michael <jim.m...@gecm.com> wrote:
++
++ >However, CC#s have a common beginning number sequence which
++ >identifies the CC type (MC, Visa, etc.), do they not?
++
++ Yes, but I think it's only one digit long. Perhaps someone can confirm?
It wouldn't matter as it won't gain any additional information.
++ In any event, stronger encryption is probably more useful here.
Xorring with a key as long as the message is the strongest encryption
possible. Without the key, it's unbreakable; after all, for any given
encrypted CC#, there is a key that maps it to whatever CC# you want.
In fact, I can give you a random line of characters of appropriate
length, and only later worry what the key is. After all, the following
relations hold:
# $cc: Credit card number
# $enc: Encrypted credit card number
# $key: Key.
$enc = $cc ^ $key;
$cc = $enc ^ $key;
$key = $cc ^ $enc;
++ >> 2. A cracker who has gotten into the database has probably also gotten
++ >> into your source code.
++ >
++ >Or your keys.
++
++ Yes, a malevolent person on your machine probably has several paths
++ of access to the information.
++
++ Encrypting the numbers in the database, and transmitting only the
++ decryption key, rather than the actual number, seems prudent to me.
++ Is there some problem I'm overlooking?
If your database is potentially insecure, how secure are your transmission
lines? And since storing the encrypted CC# gives no benefit to the person
storing the CC#, wouldn't it be better not to store the CC# at all,
and use something like RSA to transmit the CC# when ever it's needed?
Abigail
--
sub _'_{$_'_=~s/$a/$_/}map{$$_=$Z++}Y,a..z,A..X;*{($_::_=sprintf+q=%X==>"$A$Y".
"$b$r$T$u")=~s~0~O~g;map+_::_,U=>T=>L=>$Z;$_::_}=*_;sub _{print+/.*::(.*)/s}
*_'_=*{chr($b*$e)};*__=*{chr(1<<$e)};
_::_(r(e(k(c(a(H(__(l(r(e(P(__(r(e(h(t(o(n(a(__(t(us(J())))))))))))))))))))))))
Mark-Jason Dominus
Abigail <abi...@fnx.com> wrote:
>However, what do you gain by encrypting each CC# with a different key?
>Instead of stealing the CC#, all they have to do is steal the CC#, key
>combo. A task which isn't significantly harder than just stealing the
>CC#. Unless you somehow have a way to store keys in a more secure way
>than CC#.
You store the encrypted CC#s on the disk. The customer knows the key.
When they want to authorize a purchase, they transmit you the key.
If the key is intercepted, it is not very useful to the snooper. They
can use it to authorize purchases from you, but not from anyone else.
If the entire database is stolen, it is not useful to the thief
without a database of decryption keys, and no such database exists.
You need both items, the encrypted CC# and the key, to get a real CC#.
Each item is useless by itself, and the two items are not stored in
the same place, so the arrangement is more secure than just storing
the unencrypted numebrs on the disk.
Someone might conceivably steal the entire database of encrypted
numbers, and then spend time snooping the keys from the network, but
that is still a better outcome than if they stole an entire database
of unencrypted numbers.
I still think `xor' is probably a poor choice.
Mark-Jason Dominus
Michael J Gebis <ge...@fee.ecn.purdue.edu> wrote:
>It appears to me that your method is vulnerable (at least) to a
>dictionary attack.
I don't think it is. Let's make it easy on you: I give you a list of
25,000 words, and I guarantee that one of these words is the key
phrase.
If you were trying to decrypt a message, you would try every word in
the list, and get 24,999 gibberish messages and one message that was
obviously correct. But you are not trying to decrypt a messaage; you
are trying to decrypt a 53-bit number. So the result of your brute
force search is a list of 25,000 random-looking numbers. Even if you
can throw away 97% of them because they have the wrong form for credit
card numbers (Wrong check digit, fail to begin with 3, 4, 5, or 6,
etc.) you still have 750 random numbers, only one of which is
actually a valid credit card number.
What are you going to do now? Call up the Eddie Bauer order line to
make a few fraudulent purchases, and read them numbers from your list
of 750 until you hit the one that works? The Eddie Bauer folks will
get tired of that pretty qucikly, and so will you. There are easier
ways to make a living.
If the customer-selected key phrases have at least 53 bits of entropy,
then a brute force search will fail utterly. A CC# is about 53 bits
long, so with a 53-bit key phrase you are doing one-time pad, and the
result of your brute-force search is nothing more than a list of every
possible credit card number.
Elaine -HappyFunBall- Ashton
> If the key is intercepted, it is not very useful to the snooper. They
> can use it to authorize purchases from you, but not from anyone else.
How so? If I can get the key, I can get the CC# and then I can make
purchases anywhere I want.
> If the entire database is stolen, it is not useful to the thief
> without a database of decryption keys, and no such database exists.
You presume that the key length is sufficient to render the decryption
impractical or impossible. Also, too, that the customer has chosen a
totally random key which, in my experience at least, is all too rare an
occurance.
> You need both items, the encrypted CC# and the key, to get a real CC#.
> Each item is useless by itself, and the two items are not stored in
> the same place, so the arrangement is more secure than just storing
> the unencrypted numebrs on the disk.
If I could get one, I'm sure I could get the other. It's not rocket
science.
> Someone might conceivably steal the entire database of encrypted
> numbers, and then spend time snooping the keys from the network, but
> that is still a better outcome than if they stole an entire database
> of unencrypted numbers.
True, though I have seen it done before. Encryption is not an answer to
security though it is a good step.
> I still think `xor' is probably a poor choice.
It is better than nothing, however, it is not a complete solution to the
problem. If e-commerce is to survive and thrive people must have
confidence that their cards are protected. I shop a lot on-line and have
had the one card I use for such purposes replaced 2 or 3 times due to
the number being stolen.
bey...@my-dejanews.com
> Thanks; I missed that. It sounds a lot more useful to me now. For
> example, suppose you collected the CC#s out of band, perhaps over the
> phone. Then the users would never need to send CC#s over the
> internet, only their pad keys. Even if sent insecurely, a snooper is
> unlikely to get any value from the pad key; to do so, they must
> intercept a pad key *and* acquire your database.
one thing, that makes a system attractive for crackers is the existence of
chunks of credit card numbers. having different pad keys for each CC#, the
sistem will not be so attractive to deal with and spend time for a cracker. so
psycologically system will be safer. just a thought :)
> >However, CC#s have a common beginning number sequence which
> >identifies the CC type (MC, Visa, etc.), do they not?
>
> Yes, but I think it's only one digit long. Perhaps someone can confirm?
yeah, in CreditCard.pm module the code reveals that:
Visa: 4xxxxxxxxxxxxxxxxx
MasterCard : 5xxxxxxxxxxxx
Discover:6xxxxxxxxxxxxxx
Amex: 37xxxxxxxxxxxxxxxx
knowing one digit will reduce possibilities by a factor of 10. one thing that
can be done is: in database, i can also encrypt the entry for the type of the
card so that it cracker will not now what type of a card that number belongs
to. that will increase the possibility by a factor of 3 or 4 maybe.
> In any event, stronger encryption is probably more useful here.
> For example, you might use the user-supplied phrase as a key for
> DES-encrypting the credit card number. This is less likely to be
> subject to this sort of attack.
I need to check that.
> Yes, a malevolent person on your machine probably has several paths
> of access to the information.
yes, actually i am assuming that cracker knows every bit of my system. paths,
source codes, etc etc.
> Encrypting the numbers in the database, and transmitting only the
> decryption key, rather than the actual number, seems prudent to me.
> Is there some problem I'm overlooking?
another thing is its convenience for the user, in each buying you do not have
to write all the digits of CC# but an easily remembered phrase.
thanks
ersin beyret
bey...@my-dejanews.com
>
> However, what do you gain by encrypting each CC# with a different key?
> Instead of stealing the CC#, all they have to do is steal the CC#, key
> combo. A task which isn't significantly harder than just stealing the
> CC#. Unless you somehow have a way to store keys in a more secure way
> than CC#.
>
there is no way to steal the key unless the credit card owner supplies it by
himself/herself. because key is not stored in "anywhere" but the memory of the
CC owner.
the key is used only during a final checkout of a shopping. and CC owner
enters his key in a https, a secure server environment (which is supposed to
be secure) then a CGI takes that key, gets the encrypted number from
database, use that key to decrypt it and send immediately to a bank account
via a merchant account agent (again a script). all the process takes let's
say 8-10 seconds. this transaction happens in a SSL secured environment. so
assume cracker free. (at least according to SSL people)
again, i do not (and do not want to) store the keys anywhere in the system.
that is the main point.
bey...@my-dejanews.com
> Why are you home-brewing your own encryption when there is so much
> good code available? It's HARD to get this stuff right--a lot of very
> smart people have gotten it wrong in the past. Use proven
> techniques.
any advice ? for commercial usage? I checked out PGP 5.0 for unix but its
licencing is rather expensive for us. (at least for a few months)
and i wanted to understand the issues embedded with encryption, to get some
feeling of it.
> }10*10*10....10 (16 10's multiplied)
> }that number looks pretty safe??
>
> It appears to me that your method is vulnerable (at least) to a
> dictionary attack.
yes, this is the part i could not yet find a solution.
bey...@my-dejanews.com
> Your assumptions are dangerously ignorant. I am offended by anyone who
> puts CC data onine without SSL or better and thinks that it is
> sufficient. As someone who has been in some distress over the failing of
> system security, I would suggest having a much closer look at what is
> the weakness in your proposition. I think it should be obvious. Personal
> CC data is not to be taken lightly. Would you give your CC number
> on-line given your script? I think not.
>
> e.
oops. something i did not write explicitly maybe. That scenario will already
take place in a SSL secured environment with secure servers and so on. The
machine is a linux redhat 5.1, with redhat secure webserver installed
(apache-ssl based). so transactions will already happen in SSL environment.
The point of my mail was related to "storage of CC numbers safely" not
transaction, since we already assume the SSL transaction as a secure
environment.
Many merchants store CC#'s in bare format. Since i do not take CC data
lightly, in your words, i care to search for an encyrption/decryption scheme
to protect the right of property of the CC owner. The merchant will not even
now the credit card numbers. only programs will know how to decrypt it and
only when the user wants and supplies the necessary secret key. and secret
key will not be stored anywhere.
in any case, i do not want to store bare CC numbers nor i want to store
encrypted numbers and keys. both are equally stressfull for a system admin.
bey...@my-dejanews.com
> > using xor and a key supplied by credit card owner. I wanted to learn your
> > thoughts about it:
>
> If I'm not mistaken, xor encryption could be implemented in any
> programming language. Thus, this is not a Perl issue at all. Try a
> security or encryption newsgroup.
well, yes I guess so. But I will implement this in some perl scripts so I
thougt that was the right place to mail to get some initial advices not to
fall into some perl specific pitfalls.
ersin
Mark-Jason Dominus
Abigail <abi...@fnx.com> wrote:
>Xorring with a key as long as the message is the strongest encryption
>possible.
Yes, but it's not clear that you can trust the user to select a 53-bit key.
In the absence of such a guarantee, there might be attacks other than
simple brute force that would be moer successful against xor than
against some other method.
>++ Encrypting the numbers in the database, and transmitting only the
>++ decryption key, rather than the actual number, seems prudent to me.
>++ Is there some problem I'm overlooking?
>
>
>If your database is potentially insecure, how secure are your transmission
>lines?
Comparing the relative security of two unrelated entities is silly.
The database might be compromised. The transmission lines might be
compromised. Just because one is compromised does not mean you have
to give up on the other one. It would be like saying `If your front
door lock is insecure, how secure is your burglar alarm?'
It is prudent to try to plan on redundancy in your security
mechanisms, so that if one or ther other is compromised, the damages
are as small as possible. That is why bank safe deposit boxes have
two locks.
>And since storing the encrypted CC# gives no benefit to the person
>storing the CC#,
Sure it does. Customers are sending them decryption keys, which they
can use to decrypt the real numbers. When the transaction is over,
decrypted numbers and keys are both discarded.
Snowhare
Nothing above this line is part of the signed message.
In article <6tovnr$5pb$1...@monet.op.net>, Mark-Jason Dominus <m...@op.net> wrote:
>In article <6toodk$l...@mozo.cc.purdue.edu>,
>Michael J Gebis <ge...@fee.ecn.purdue.edu> wrote:
>>It appears to me that your method is vulnerable (at least) to a
>>dictionary attack.
>
>I don't think it is. Let's make it easy on you: I give you a list of
>25,000 words, and I guarantee that one of these words is the key
>phrase.
>
>If you were trying to decrypt a message, you would try every word in
>the list, and get 24,999 gibberish messages and one message that was
>obviously correct. But you are not trying to decrypt a messaage; you
>are trying to decrypt a 53-bit number. So the result of your brute
>force search is a list of 25,000 random-looking numbers. Even if you
>can throw away 97% of them because they have the wrong form for credit
>card numbers (Wrong check digit, fail to begin with 3, 4, 5, or 6,
>etc.) you still have 750 random numbers, only one of which is
>actually a valid credit card number.
This is a code fragment from a number validator I wrote.
# Check if it passes the Mod10 Checksum
if (($cardtype ne "enroute") && (&LUHNFormula($cardnumber))) {
return 0;
}
# Verify correct length and prefix for each card type
if (($cardtype eq "visa") &&
(! ($cardnumber =~ m#^4(\d{12}|\d{15})$#o))) {
return 0;
} elsif (($cardtype eq "mastercard") &&
(! ($cardnumber =~ m#^5[1-5]\d{14}$#o))) {
return 0;
} elsif (($cardtype eq "amex") &&
(! ($cardnumber =~ m#^3[47]\d{13}$#o))) {
return 0;
} elsif (($cardtype eq "diners-club") &&
(! ($cardnumber =~ m#^3(0[0-5]|[68]\d)\d{11}$#o))) {
return 0;
} elsif (($cardtype eq "carte-blanche") &&
(! ($cardnumber =~ m#^3(0[0-5]|[68]\d)\d{11}$#o))) {
return 0;
} elsif (($cardtype eq "discover") &&
(! ($cardnumber =~ m#^6011\d{12}$#o))) {
return 0;
} elsif (($cardtype eq "enroute") &&
(! ($cardnumber =~ m#^(2014|2149)\d{11}$#o))) {
return 0;
} elsif (($cardtype eq "jcb") &&
(!(($cardnumber =~ m#^(2131|1800)\d{11}$#o) ||
($cardnumber=~m#^3(088|096|112|158|337|528)\d{12}$#o)))){
return 0;
} elsif (($cardtype eq "novus") && (length($cardnumber) != 16)) {
return 0;
}
Depending on the specific card used, the possibilites range from 25,000
to unique.
Benjamin Franz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNgALJOjpikN3V52xAQE7xwQAoZD442FSV2AgEsPNRTlYVSGSv0olVzK2
3RY9Mmz80c3xDIATWXwM4hNF0r8eZBo8E7q1kQiH1ViiBFwjd+T0w+Vtt0VHemC3
UQs7ngVqdltfMaj6fnAb33JmNsY/GalIDZjgZR6KLfgQLI8vEpGEr0XNHhyfwssb
+Sq3sTdArCU=
=pYkH
-----END PGP SIGNATURE-----
Mark-Jason Dominus
>
>> If the key is intercepted, it is not very useful to the snooper. They
>> can use it to authorize purchases from you, but not from anyone else.
>
>How so? If I can get the key, I can get the CC# and then I can make
>purchases anywhere I want.
No, you can't. The encrypted CC# is on my disk behind the firewall.
You have to get the key, and *then* you have to break into the machine
where the database is kept. Either one alone is not enough.
>You presume that the key length is sufficient to render the decryption
>impractical or impossible. Also, too, that the customer has chosen a
>totally random key which, in my experience at least, is all too rare an
>occurance.
Please see my followup to Mike Gebis.
Also, note that guessing the key does not compromise the credit card number.
>If I could get one, I'm sure I could get the other.
I don't think this is true. I can protect the transmission of they
key by exchanging it over an encrypted channel. Extracting such a key
is difficult and time-consuming.
I can protect the database the same way I protect any other sensitive
material resource: With system security protocols, a secure location,
and a well-designed firewall. Breaking into such a system is also
difficult and time-consuming.
>It's not rocket science.
You seem to be arguing that there is no point in taking any
precautions at all because all security is just going to be broken
anyway.
But rocket science or not, it can't be easier to steal the key *and*
break into the database than it is to just steal the key, and your
saying so doesn't make it true.
>If e-commerce is to survive and thrive people must have
>confidence that their cards are protected.
Only time will tell; I believe you are mistaken. The precautions
we're discussing in this thread are much stronger than the precautions
taken by conventional merchants. Nobody thinks twice about calling up
Eddie Bauer and giving their credit card number over the phone (which
is easy to tap) to a clerk who makes minimum wage doing data entry,
who might take the number home, and who might save the number in
plaintext form in a database.
But to you, an electronic security system is not secure enough even
when it requires that the thief break into a secure computer to steal
the database *and* tap the customer's transaction data from an
encrypted network connection.
Oh well, so much for online commerce.
bey...@my-dejanews.com
al...@interport.net (Allan Peda) wrote:
> As a first guess... look into calling crypt() on a key generated by a
> call to rand(). Save the encrypted key in another database, perhaps
> on another machine? There is also a module called Crypt.
>
> In any event it's a heck of a lot better than XOR
yes but i also want to decrypt it. crypt puts it into a not-easily-decryptible
form, am i wrong?
bey...@my-dejanews.com
> - - The programmer is terribly naive about users if he thinks
> that asking them for a string the length of their CC # + expiration
> data is a workable solution. How are they going to remember it?
> If he stores the key on the machine the encryption is useless.
yes, i do not, and will not store keys in anywhere.
the key I was planning to ask from credit card owner does not have to be at
the same length of their CC #+expiration data. then all the scheme would be
useless. the main point of storing CC# into database is not to make user be
have to enter again and again their CC# at every shopping but just enter the
secret key, which is easy to remember. if s/he forgets the secret key, there
is no way to find it, since it is not stored anywhere. but that is not a
problem, s/he just need to register again.
if the secret key is not an easy to remember key, than all these are useless.
that's why i did not want its length to be restricted with CC#+expiration. if
a shorter secret key is supplied, then the script will generate the other
parts from the supplied one.
CC#: 123412341234 1234
key: merhaba
the perl script must be able to generate the remaining part of the key from
the supplied one :"merhaba".
actually, this would me more secure than having 16 digits of long phrase.
because, users will give meaningfull phrases to make it easy to remmember.
but that increases the vulnerability to a dictionary attack. but instead of
16 characters, if user enters (or restricted to enter) say 10 characters and
remainig part is generated by an algorithm which will make dictionary
attackers job difficult by generating meaningless combination of characters,
i think that would make it safer.
the algorithm however, should generate the same combination everytime the same
phrase entered.
than that final string will be xored with CC# and stored.
you may say that since cracker has the source code s/he can also generate
this combination but s/he does not now how long the real phrase is. again,
only CC# owner knows about it. well maybe i am wrong. s/he can just run
her/his all words + generated combination for each of them and try. the
dictionary must be a real good one though.
in any case, if you were a cracker, would you attack to a system if you knew
that even if you could reach to the database, you still have to deal with
each CC# uniquely. or would you go for other system where credit cards are
available in chunks, either because they are stored as clear text or keys are
also stored in system or there is one key for all.
btw, i am not a professional programmer, thus my approach to the issue is as
good as my logic allows.
thanks
ersin beyret
Elaine -HappyFunBall- Ashton
> No, you can't. The encrypted CC# is on my disk behind the firewall.
> You have to get the key, and *then* you have to break into the machine
> where the database is kept. Either one alone is not enough.
So you are saying that if I can get the key, I can't get behind your
firewall? Hrm. I find that a bit tenuous.
> I don't think this is true. I can protect the transmission of they
> key by exchanging it over an encrypted channel. Extracting such a key
> is difficult and time-consuming.
So much faith in SSL?
> I can protect the database the same way I protect any other sensitive
> material resource: With system security protocols, a secure location,
> and a well-designed firewall. Breaking into such a system is also
> difficult and time-consuming.
But not out of the question. Look, I'm merely trying to point out that
there are people who would be able to do it just for the fun factor.
System security in many places is weak or like Fort Knox with a
twist-tie lock on the back gate.
> You seem to be arguing that there is no point in taking any
> precautions at all because all security is just going to be broken
> anyway.
No, take my point. Security has many facets. To merely encrypt the data
behind a firewall doesn't give me that warm and fuzzy feeling.
> But rocket science or not, it can't be easier to steal the key *and*
> break into the database than it is to just steal the key, and your
> saying so doesn't make it true.
No, but if I can get the key (the hard part), breaking into the system
is probably going to be trivial. Of course, I wouldn't know anything
about that :)
> Only time will tell; I believe you are mistaken. The precautions
> we're discussing in this thread are much stronger than the precautions
> taken by conventional merchants. Nobody thinks twice about calling up
> Eddie Bauer and giving their credit card number over the phone (which
> is easy to tap) to a clerk who makes minimum wage doing data entry,
> who might take the number home, and who might save the number in
> plaintext form in a database.
There are risks to our security everywhere. One nice, though somewhat
invasive, tactic CC are doing now is spending pattern correlation. I get
a phone call when I go on my annual jeans and turtleneck spending spree
since I so rarely buy clothes. But in the electronic universe there is
no clerk to check your signature, no camera to take your picture and
sometimes little way to track the transaction back to the point of
origin. And I'm not mistaken about some of the e-commerce solutions that
I have seen lately that have no regard for security. All written in some
really wicked ugly Perl I might add.
> But to you, an electronic security system is not secure enough even
> when it requires that the thief break into a secure computer to steal
> the database *and* tap the customer's transaction data from an
> encrypted network connection.
Everything is possible and with a will there is a way. Never say
anything is impossible as it will more than likely prove you wrong.
> Oh well, so much for online commerce.
e-commerce is great. I buy books and my groceries on-line. I even have
my take-out chinese waiting for me when I go home. I need to get them to
buy better fortunes for their cookies though.
Abigail
++
++ I still think `xor' is probably a poor choice.
"The next step up in complexity for the cryptographer is to use a key
longer than the plaintext, making the above attack useless. In fact,
constructing an unbreakable cipher is easy. First choose a random bit
string as the key. Then convert the plaintext into a bit string, for
example by using its ASCII representation. Finally, compute the
EXCLUSE OR of these strings, bit by bit. The resulting ciphertext
cannot be broken, because every possible plaintext is an equally
probable candidate. The ciphertext gives the cryptoanalyst no infor-
mation at all. In a sufficiently large sample of ciphertext, each
letter will occur equally often, as will every digram and every trigram."
Andrew S. Tanenbaum: "Computer Networks". Prentice/Hall. 1981.
ISBN 0-13-164699-0. pp 392-393.
Abigail
--
perl -e '$a = q 94a75737420616e6f74686572205065726c204861636b65720a9 and
${qq$\x5F$} = q 97265646f9 and s g..g;
qq e\x63\x68\x72\x20\x30\x78$&eggee;
{eval if $a =~ s e..eqq qprint chr 0x$& and \x71\x20\x71\x71qeexcess}'
Mary E Tyler
>
> In article <35FFB3...@gecm.com>, Jim Michael <jim.m...@gecm.com> wrote:
> >However, CC#s have a common beginning number sequence which
> >identifies the CC type (MC, Visa, etc.), do they not?
>
> Yes, but I think it's only one digit long. Perhaps someone can confirm?
>
the first 4 refer to the clearing house(for lack of a better term). the
second four refer to your bank. the third four are a reference internal
to your bank. the fourth are your account number. or so i have been
told.
it's really the last 8 that are important and the last 4 that are
crucial.
think what i might do is take the password they provide and use it as a
seed to your random number generator and encrypt with the number
produced... then you can easily reproduce the decryption key (unless i
misunderstand how RNGs work). if the password is submitted securely and
stored securely (remember the easiest way to make something safe on the
internet is to unplug the network connection... LOL)
am watching this closely, being at a point in a project where i need
some moderate protection on passwords and files, but nothing
incredible...
dejah
ps- would someone be so kind as to remind me via email what the heck xor
does and how you encrypt/decrypt with it. we just moved and my
programming books are locked away. i used it once a few years ago and
haven't needed it since... forgot how the hell it works.
--
i trust i make myself obscure, i have need of obscurity now- robert bolt
a heated exchange of unread mail would be welcomed by all- christensen
Skating Fiction. Featuring the highly acclaimed serial On The Edge!
http://www.DejahsPrivateIce.com
Abigail
September MCMXCIII in <URL: news:360000B8...@bbnplanet.com>:
++ Mark-Jason Dominus wrote:
++
++ > can use it to authorize purchases from you, but not from anyone else.
++
++ How so? If I can get the key, I can get the CC# and then I can make
++ purchases anywhere I want.
No. You need the key *and* the encrypted number.
++ > If the entire database is stolen, it is not useful to the thief
++ > without a database of decryption keys, and no such database exists.
++
++ You presume that the key length is sufficient to render the decryption
++ impractical or impossible. Also, too, that the customer has chosen a
++ totally random key which, in my experience at least, is all too rare an
++ occurance.
Impossible is the right answer. The beauty of XOR encryption is that even
if you brute force try all keys, and you hit the right one, you have
absolutely no idea it is the right key.
For instance, I might give you the encrypted text "t^R][S". You might
try keys, and find out that XORring with "123456" gives "Elaine". However,
XORring with "5-:)4=" will give you "Ashton". And a key of "<?16>!" will
give you "Hacker". For any 6 character string, there will be a unique,
6 character key that, when applied to the encrypted text, gives you the
target text.
Abigail
--
perl -wle 'print "Prime" if (1 x shift) !~ /^1?$|^(11+?)\1+$/'
Elaine -HappyFunBall- Ashton
> oops. something i did not write explicitly maybe. That scenario will already
> take place in a SSL secured environment with secure servers and so on. The
> machine is a linux redhat 5.1, with redhat secure webserver installed
> (apache-ssl based). so transactions will already happen in SSL environment.
> The point of my mail was related to "storage of CC numbers safely" not
> transaction, since we already assume the SSL transaction as a secure
> environment.
I'm not sure that RedHat would be my first choice for a host storing
sensitive data, encrypted or not due to the number of exploits that
currently exist for it and are proliferating everyday. Perhaps I have
been a bit obtuse as well. My point in all of this is that one must
consider all of the options if one truly wants to make a secure
e-commerce solution.
> Many merchants store CC#'s in bare format. Since i do not take CC data
> lightly, in your words, i care to search for an encyrption/decryption scheme
> to protect the right of property of the CC owner. The merchant will not even
> now the credit card numbers. only programs will know how to decrypt it and
> only when the user wants and supplies the necessary secret key. and secret
> key will not be stored anywhere.
I wasn't criticising the encryption idea, but the confidence it seems to
evoke. What if someone added a few lines of code to your script and
mailed all of the customers info at the time of sign-up to an email
address? You cannot always prevent things such as this, but dreaming up
ways to compromise your site and considering them in the solution is
important.
> in any case, i do not want to store bare CC numbers nor i want to store
> encrypted numbers and keys. both are equally stressfull for a system admin.
I'll second that :)
Elaine -HappyFunBall- Ashton
> No. You need the key *and* the encrypted number.
Correct. But, if I can get the key, I can probably get on the machine
and find the database. Unless, of course, I missed something.
> Impossible is the right answer. The beauty of XOR encryption is that even
> if you brute force try all keys, and you hit the right one, you have
> absolutely no idea it is the right key.
Well, brute force is an ugly way to go about spending a Sunday
afternoon, but I don't know that impossible is the correct term.
> For instance, I might give you the encrypted text "t^R][S". You might
> try keys, and find out that XORring with "123456" gives "Elaine". However,
> XORring with "5-:)4=" will give you "Ashton". And a key of "<?16>!" will
> give you "Hacker". For any 6 character string, there will be a unique,
> 6 character key that, when applied to the encrypted text, gives you the
> target text.
This is true and I may be dead before I could break it, but then again,
I could get lucky. Modern cryptanalysis is making great strides and with
more computing power than ever before. I never like to say that anything
is impossible, just improbable...for now. They broke purple without a
cray didn't they?
Abigail
<URL: news:6tp0qo$61r$1...@monet.op.net>:
++ In article <6totbc$fb7$1...@client3.news.psi.net>,
++ Abigail <abi...@fnx.com> wrote:
++ >Xorring with a key as long as the message is the strongest encryption
++ >possible.
++
++ Yes, but it's not clear that you can trust the user to select a 53-bit key.
But what keeps you from selecting one for them? At one point in time,
you need a secure transaction line - at the time they send their
encrypted numbers. (You cannot send both the encrypted number and the
key over a potential insecure line, as that would give a snooper the
credit card number). Once you have the secure line, send them the key
(which of course, you will not store), they send the encrypted number,
and keep the key. Next time, when they use the potential insecure line,
they send the key.
++ In the absence of such a guarantee, there might be attacks other than
++ simple brute force that would be moer successful against xor than
++ against some other method.
++
++ >++ Encrypting the numbers in the database, and transmitting only the
++ >++ decryption key, rather than the actual number, seems prudent to me.
++ >++ Is there some problem I'm overlooking?
++ >
++ >
++ >If your database is potentially insecure, how secure are your transmission
++ >lines?
++
++ Comparing the relative security of two unrelated entities is silly.
++ The database might be compromised. The transmission lines might be
++ compromised. Just because one is compromised does not mean you have
++ to give up on the other one. It would be like saying `If your front
++ door lock is insecure, how secure is your burglar alarm?'
Well, there is a problem. The database is safe, but the transmission
line isn't. You call the company, introduce yourself as Mark-Jason and
send your key. If I can snoop that transmission, what's keeping me from
calling the company, introducing myself as Mark-Jason, and order some nice
toys using your credit card number, that I unlock by sending your key?
It's true that I won't be able to snatch your CC# number that way, but
I can still use your number.
Uri Guttman
A> Mark-Jason Dominus (m...@op.net) wrote on MDCCCXLII September
A> MCMXCIII in <URL: news:6touoo$5j0$1...@monet.op.net>: ++ ++ I still
A> think `xor' is probably a poor choice.
A> "The next step up in complexity for the cryptographer is to use a
A> key longer than the plaintext, making the above attack useless. In
A> fact, constructing an unbreakable cipher is easy. First choose a
A> random bit string as the key. Then convert the plaintext into a bit
A> string, for example by using its ASCII representation. Finally,
A> compute the EXCLUSE OR of these strings, bit by bit. The resulting
A> ciphertext cannot be broken, because every possible plaintext is an
A> equally probable candidate. The ciphertext gives the cryptoanalyst
A> no infor- mation at all. In a sufficiently large sample of
A> ciphertext, each letter will occur equally often, as will every
A> digram and every trigram."
A> Andrew S. Tanenbaum: "Computer Networks". Prentice/Hall. 1981.
A> ISBN 0-13-164699-0. pp 392-393.
this is the well known one time pad technique and it is considered
unbreakable. you distribute a pair of pads which have the same sequence
of random numbers, one pad at home and one pad to the remote
spy. messages are encrypted using xor or something similar (a plain
letter substitution will work with random integers) with the next pad
sheet for each message (or part). only if you know the random sequence
can you break it. the problem is the secure distribution of the two
copies of the pad.
the resulting ciphertext has same the entropy of the random sequence and you
can't deduce when you have decoded it.
i hate to admit it, but dear abby is right here. xor is all you need
provided you have a random key and it is secure at both ends.
uri
--
Uri Guttman Speed up your web server with Fast CGI!
u...@fastengines.com http://www.fastengines.com
Felix S. Gallo
>[...]
>If the customer-selected key phrases have at least 53 bits of entropy,
>then a brute force search will fail utterly. A CC# is about 53 bits
>long, so with a 53-bit key phrase you are doing one-time pad, and the
>result of your brute-force search is nothing more than a list of every
>possible credit card number.
What M-J said is basically correct. But as a novitiate crank pedant,
I earn valuable Usenet points towards my next advancement by
pointing out that some of his language here tends towards the
careless: there's a difference between a '53-bit key phrase' and
a key phrase with 53 bits of entropy, normally, especially if the
phrase is 'customer-selected' -- and with a 53-bits-of-entropy key
phrase you are not doing 'one-time pad', but rather you are
ensuring that every bit in the plaintext is subject to possible entropic
change. Since the customer may reuse the key phrase, there are
dangers that don't exist with real one-time pads. But as far as
most of the readers of this post will ever need to know, Mark-Jason
is spot on.
Now that I have discharged my pedantic duties, I now go for the
bonus round by adding to the conversation.
Anyone keeping a database of credit card numbers on a
computer accessible to the Internet is asking for trouble,
no matter what their security implementation is. If a hacker
can get on that computer, then she can download the
decryption algorithm code or install a debugger.
One way to start being secure is to remove all network
interfaces from your credit card database box and
install a serial cable. Write some special software
for the box which answers queries only, and does not
permit download of the whole database. Insert trap
credit card numbers. Make sure the query box is
extremely secure, including tripwire, firewalling,
signalling, and of course more hacker traps.
The inconvenience to you is zero compared to
what you'd go through if the database were stolen.
The customer might not be extremely put out --
after all, the credit card company makes certain
anti-theft-loss guarantees -- but the buck has to
stop somewhere, and you're the obvious target.
Felix
Michael J Gebis
}Mark-Jason Dominus (m...@op.net) wrote on MDCCCXLII September MCMXCIII in
}<URL: news:6touoo$5j0$1...@monet.op.net>:
}++ I still think `xor' is probably a poor choice.
} "The next step up in complexity for the cryptographer is to use a key
} longer than the plaintext, making the above attack useless. In fact,
} constructing an unbreakable cipher is easy. First choose a random bit
} string as the key.
It is HIGHLY important to have a truly random bit string. People
choose correlated keys. The method as described in the orignal post
is not the one-time-pad tannenbaum is describing here.
Elaine -HappyFunBall- Ashton
100% secure, but certainly much more than I thought. I'll just go mug
the cute waiter instead for my CC fix. ;)
Interesting tidbit from www.cypher.net.
Why are One-Time Pads Perfectly Secure?
If the key is truly random, an xor-based one-time pad is perfectly
secure against ciphertext-only cryptanalysis. This means an attacker
can't compute the plaintext from the ciphertext without knowlege of the
key, even via a brute force search of the space of all keys! Trying all
possible keys doesn't help you at all, because all possible plaintexts
are equally likely decryptions of the ciphertext.
This result is true regardless of how few bits the key has or how much
you know about the structure of the plaintext. To see this, suppose you
intercept a very small, 8-bit, ciphertext. You know it is either the
ASCII character 'S' or the ASCII character 'A' encrypted with a one-time
pad. You also know that if it's 'S', the enemy will attack by sea, and
if it's 'A', the enemy will attack by air. That's a lot to know. All you
are missing is the key, a silly little 8-bit one-time pad.
You assign your crack staff of cryptanalysts to try all 256 8-bit
one-time pads. This is a brute force search of the keyspace.
The results of the brute force search of the keyspace is that your staff
finds one 8-bit key that decrypts the ciphertext to 'S' and one that
decrypts it to 'A'. And you still don't know which one is the actual
plaintext.
This argument is easilly generalized to keys (and plaintexts) of
arbitrary length.
Abigail
September MCMXCIII in <URL: news:36001D95...@bbnplanet.com>:
++ Abigail wrote:
++
++ > No. You need the key *and* the encrypted number.
++
++ Correct. But, if I can get the key, I can probably get on the machine
++ and find the database. Unless, of course, I missed something.
++
++ > Impossible is the right answer. The beauty of XOR encryption is that even
++ > if you brute force try all keys, and you hit the right one, you have
++ > absolutely no idea it is the right key.
++
++ Well, brute force is an ugly way to go about spending a Sunday
++ afternoon, but I don't know that impossible is the correct term.
Sure it is. Pick an encrypted string E. Pick a plain text P, any text
you want (with the same length). Create a key K = E xor P. That will
"decrypt" E to P.
++ > For instance, I might give you the encrypted text "t^R][S". You might
++ > try keys, and find out that XORring with "123456" gives "Elaine". However,
++ > XORring with "5-:)4=" will give you "Ashton". And a key of "<?16>!" will
++ > give you "Hacker". For any 6 character string, there will be a unique,
++ > 6 character key that, when applied to the encrypted text, gives you the
++ > target text.
++
++ This is true and I may be dead before I could break it, but then again,
++ I could get lucky. Modern cryptanalysis is making great strides and with
++ more computing power than ever before. I never like to say that anything
++ is impossible, just improbable...for now. They broke purple without a
++ cray didn't they?
It has nothing to do with number of keys to check. It has all to do
with not being able to answer the question "is this a correct key?".
Here it is again:
Encrypted text Key Plain text
t^R][S 123456 Elaine
t^R][S 5-:)4= Ashton
t^R][S <?16>! Hacker
There aren't separate encryption/decryption keys so you can perform
a M = D(E(M)) test. For *every* possible list of CC#, there will be
a (unique) key that decrypts a certain encrypted string to that CC#.
So, all your brute force can do is generate a list of all possible CC#'s.
But that's something I can do without using a list of encrypted numbers.
Abigail
--
perl -e '$_ = q *4a75737420616e6f74686572205065726c204861636b65720a*;
for ($*=******;$**=******;$**=******) {$**=*******s*..*qq}
print chr 0x$& and q
qq}*excess********}'
Michael J Gebis
}Ok. I stand corrected. I am still not absolutely certain that this is
}100% secure, but certainly much more than I thought. I'll just go mug
}the cute waiter instead for my CC fix. ;)
}Interesting tidbit from www.cypher.net.
}Why are One-Time Pads Perfectly Secure?
}If the key is truly random, an xor-based one-time pad is perfectly
^^^^^^^^^^^^^^^^^^^^^^^^^^
Nobody chooses "truly random" bitstrings for a key.
(Well, maybe Data does, but no _humans_)
Mark-Jason Dominus
Felix S. Gallo <f...@newsguy.com> wrote:
>But as a novitiate crank pedant,
>I earn valuable Usenet points towards my next advancement
Don't forget that you also need three box tops!
>pointing out that some of his language here tends towards the
>careless: there's a difference between a '53-bit key phrase' and
>a key phrase with 53 bits of entropy, normally, especially if the
>phrase is 'customer-selected'
Mea culpa. I was deliberately using shorthand to avoid confusing the
real issues with Too Much Jargon. But since you brought it up, what I
really meant to say is that the customers, considered as a source of
keys, must be an ergodic source with at least 53.15 bits of entropy
per key.
Pedantically Yours, and in Quest of Box Tops,
I remain,
Yr Humble and Obedient Servant,
Jas: Dominus
bey...@my-dejanews.com
>
> I'm not sure that RedHat would be my first choice for a host storing
> sensitive data, encrypted or not due to the number of exploits that
> currently exist for it and are proliferating everyday. Perhaps I have
> been a bit obtuse as well. My point in all of this is that one must
> consider all of the options if one truly wants to make a secure
> e-commerce solution.
well, i do not think that it is the distribution that matters for security
but the kernel version, versions of daemons etc. distributions are just combo
boxes, so another distribution using the same versions of sendmail, kernel,
etc etc. would have same vulnerabilities anyway.
> I wasn't criticising the encryption idea, but the confidence it seems to
> evoke. What if someone added a few lines of code to your script and
> mailed all of the customers info at the time of sign-up to an email
> address? You cannot always prevent things such as this, but dreaming up
> ways to compromise your site and considering them in the solution is
> important.
that is a very good point. i'll think about this. yeah, instead of wasting
time with decrypting CC#s in database, a cracker would prefer that way.
can a perl code be made human unreadable? write it once, and sort of convert
it to a format that is still executable but not readable?
if the CGI is written in C, since it is compiled to binary, code can not be
edited (say i chewed :) the source code after compilation and cracker can't
find it).
ersin
Uri Guttman
MJG> Elaine -HappyFunBall- Ashton <eas...@bbnplanet.com> writes:
MJG> }Why are One-Time Pads Perfectly Secure?
MJG> }If the key is truly random, an xor-based one-time pad is
MJG> perfectly ^^^^^^^^^^^^^^^^^^^^^^^^^^
MJG> Nobody chooses "truly random" bitstrings for a key.
a real one time pad doesn't have to be truly random, it just needs high
enough entropy and no way of deducing the next pad from the current
one.
in the discussed application, a simple text string for a key is not
random enough so that all possible messages can be decoded. therefore it
is possible to break it with a brute force test of many strings of
english, etc. but it still may take a while.
Michael J Gebis
#!/usr/bin/perl5 -w
$cc="012345678";
$k ="brainwash"; # Why not?
$ciphertext = $cc ^ $k;
undef $k; #FORGET THE KEY
@cipher = split(//,$ciphertext);
$regexp = "";
foreach $letter (@cipher) {
$regexp .= '[';
foreach $digit (qw(0 1 2 3 4 5 6 7 8 9)) {
print $letter ^ $digit;
$regexp.= quotemeta($letter ^ $digit);
}
$regexp .= ']';
print "\n";
}
print "Regexp is $regexp\n";
open(WORDS,'/usr/dict/words') or die "Blowme:$!";
while(<WORDS>) {
chomp;
if(m/^$regexp$/) {
print $_, ":",$_^$ciphertext,"\n";
}
}
# I get two possible matches. That sure seems pretty doable.
# Obviously, this particular program only works with a single word,
# and assumes the length is known, but it seems that it wouldn't be
# that difficult to extend it. I sure hope this proves my point.
Felix S. Gallo
Abigail writes:
>Mark-Jason Dominus (m...@op.net) writes:
>++ Yes, but it's not clear that you can trust the user to select a 53-bit
key.
>
>But what keeps you from selecting one for them?
Sociology and physics, normally. Which is to say, imagine if
your bank asked you to remember a 300 word text, or to recite
a 120 letter 'random string' over the telephone. People wouldn't
accept it, even if it were truly secure (and if they did, they'd likely
make errors and get mad). Until recently, it was also surprisingly
difficult to physically carry around 2 megabits.
Having thus achieved one boxtop for flagrant use of male
answer syndrome, I again go for the bonus round by suggesting
that this discussion be moved to sci.crypt after all the contestants
have thoroughly read the sci.crypt FAQs and Applied Cryptography
by Bruce Schneier. The important point that any reader will instantly
derive from holding this kind of discussion in sci.crypt is that there
are more innocent, naive and commonsensical ways to do something
absolutely stupid than there are in a room full of boobytrapped pinatas.
The person who is serious about the use of cryptography hires a
serious cryptography professional, lays out for expensive cryptographic
systems, or spends years of her life in menial toil pulling her hair out
over minutiae.
Felix
not a cryptography professional
Felix S. Gallo
bey...@my-dejanews.com writes:
>if the secret key is not an easy to remember key, than all these are
useless.
>that's why i did not want its length to be restricted with CC#+expiration.
if
>a shorter secret key is supplied, then the script will generate the other
>parts from the supplied one.
Length is not an important thing _at all_.
Entropy is the only important thing.
With Length _usually_ comes some amount of entropy, in practice; and
the maximum amount of available entropy does increase as length
increases; but the correlation is entropy-causes-length, not length-
causes-entropy.
>CC#: 123412341234 1234
>key: merhaba
>
>the perl script must be able to generate the remaining part of the key from
>the supplied one :"merhaba".
If it can do this, then the cracker can also generate the remaining part
of the key as part of her dictionary attack.
>actually, this would me more secure than having 16 digits of long phrase.
No, it depends on the entropy.
>because, users will give meaningfull phrases to make it easy to remmember.
>but that increases the vulnerability to a dictionary attack. but instead of
>16 characters, if user enters (or restricted to enter) say 10 characters
and
>remainig part is generated by an algorithm which will make dictionary
>attackers job difficult by generating meaningless combination of
characters,
>i think that would make it safer.
You are, in general, wrong -- 16 characters will, all else being equal, tend
to contain more entropy than 10 + any amount of algorithmic adding-on
(which, as it happens, totals to 10).
>in any case, if you were a cracker, would you attack to a system if you
knew
>that even if you could reach to the database, you still have to deal with
>each CC# uniquely. or would you go for other system where credit cards are
>available in chunks, either because they are stored as clear text or keys
are
>also stored in system or there is one key for all.
This argument is normally pretty good (when in a hunting group, it is not
important to be able to outrun a bear, but rather to be able to outrun the
slowest member of your group) -- but let's say someone does decide to
go after your database, and since it's weakly protected, gets it and starts
abusing the credit card numbers. Do you stand up in court and say,
"your honor, I'm completely vexed; there were easier targets than me"?
I'd rather not be in court at all.
>btw, i am not a professional programmer, thus my approach to the issue is
as
>good as my logic allows.
Nice try -- but the security world is littered with the heaped entrails of
a million nice tries.
Felix
mine own included
Mark-Jason Dominus
>
>#!/usr/bin/perl5 -w
>$cc="012345678";
I'm sorry I wasted your time by not making this clear earlier, but
you're not looking for the right thing here. You mustn't encode the
16-digit credit card number as 16 ascii digits, because that pads it
out to 128 bits, so that 75 of them are redundant. Of course it's
easy to brute-force when there's so much redundancy; you need 128-bit
keys, and the dictionary has only 14.
Instead, to properly encrypt a number, you should convert the 16-digit
credit card number to a 54-bit binary number, and pack it into 7 ascii
characters. The number 4071-2345-6789-3333, converted to binary, is
00001110,01110110,11000100,00101010,00110111,01110001,01010101. This
packs down to the string "\cNv\xc4*7qU". Xor this with a similarly
packed version of the secret key. The result, say "~\c^\xbbFV\c_-",
is your target that you stole from the database. If you xor this with
the correct key, you get the original credit card number back. If you
xor it with "Angstrom" instead, you get "?p\xDB) z_", which unpacks to
credit card number 17857010122914399. You can reject this one,
because it's too big, but in general you won't be so lucky.
>I sure hope this proves my point.
Again, I'm sorry I was unclear.
I invite you to discover my credit card number. I have selected a
random word from /usr/dict/words and xored it with the packed version
of the number. The result is "k\cN\242\324\352\303~".
Mark-Jason Dominus
>I have selected a random word from /usr/dict/words
Sorry; I forgot to include: When the words were longer than seven
characters, I truncated them; when they were shorter, I padded them on
the end with digits 1234567, so that "foo" became "foo1234", etc.
Obviously the real application would do better than this, mingling
extra bits as appropriate, but I was being lazy.
Mary E Tyler
> }100% secure, but certainly much more than I thought. I'll just go mug
> }the cute waiter instead for my CC fix. ;)
>
> }Interesting tidbit from www.cypher.net.
>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Nobody chooses "truly random" bitstrings for a key.
>
>
okay, so how random is random enough? if, as i suggested before, a
random key is generated using the password provided by the user... is
this random enough?
this is an actual question.
dejah
Mary E Tyler
>
> Mark-Jason writes:
> >[...]
> >If the customer-selected key phrases have at least 53 bits of entropy,
> >then a brute force search will fail utterly. A CC# is about 53 bits
> >long, so with a 53-bit key phrase you are doing one-time pad, and the
> >result of your brute-force search is nothing more than a list of every
> >possible credit card number.
>
> I earn valuable Usenet points towards my next advancement by
> pointing out that some of his language here tends towards the
> careless: there's a difference between a '53-bit key phrase' and
> a key phrase with 53 bits of entropy
though this is not exactly PERL related, it has been mentioned here? how
does one apply for the Usenet points system... i can think of several
people on my other favorite news group who need to have applications for
the program sent to them... i'd love to be able to oblige...
dejah, is being pedantic a cross newsgroup phenomina?
#Obligatiory perl comment
for (;;) {print "You msut bring us a shrubbery!";}
Mark-Jason Dominus
Mary E Tyler <de...@DejahsPrivateIce.com> wrote:
>> }If the key is truly random, an xor-based one-time pad is perfectly
The users, as a group, must constitute an ergodic source of
information with an entropy of at least 53.15 bits per key.
>this is an actual question.
That is the actual answer.
Hope this helps.
Michael J Gebis
}In article <6tpfbv$3...@mozo.cc.purdue.edu>,
}Michael J Gebis <ge...@fee.ecn.purdue.edu> wrote:
}>In response to M-J-D's challenge:
}>#!/usr/bin/perl5 -w
}>$cc="012345678";
}I'm sorry I wasted your time by not making this clear earlier, but
}you're not looking for the right thing here.
I feel I must point out that this _is_ the method described in the
original post of the thread. So I hope that I've at least proven THAT
method insecure. (I also think my program was pretty cool.)
}I invite you to discover my credit card number. I have selected a
}random word from /usr/dict/words and xored it with the packed version
}of the number. The result is "k\cN\242\324\352\303~".
This is a more interesting challenge, for certain. I'm not _yet_
convinced that it is secure. Providing the following
reference function would answer some questions I have about your
proposed method.
sub funkycrypt ($$) {
my($cc,$key)=@_;
#
# Do your stuff here
#
return $ciphertext;
}
Thanks.
David Formosa
[...]
>the first 4 refer to the clearing house(for lack of a better term). the
>second four refer to your bank. the third four are a reference internal
>to your bank. the fourth are your account number. or so i have been
>told.
So the first 12 digits are basicly known planetext.
>it's really the last 8 that are important and the last 4 that are
>crucial.
>think what i might do is take the password they provide and use it as a
>seed to your random number generator and encrypt with the number
>produced... then you can easily reproduce the decryption key (unless i
>misunderstand how RNGs work).
Then the system is crackable. If you know enough of the output of a PRNG
you can guess the rest. For the simple random number generators supplied
with your typical compiler (perl just links into C's one) this is
embrassingly short.
So an attacker could in most likely hoods larnch an attack against this
system. In addtion xor encrytion of this stlye to be secure needs a
real random number generator. You need something like /dev/random for
it to work correctly. Noraml random number systems just don't cut it.
David Formosa
>Mark-Jason Dominus (m...@op.net) wrote on MDCCCXLII September MCMXCIII in
><URL: news:6touoo$5j0$1...@monet.op.net>:
>++
>++ I still think `xor' is probably a poor choice.
> In fact,
> constructing an unbreakable cipher is easy. First choose a random bit
> string as the key. Then convert the plaintext into a bit string, for
> example by using its ASCII representation.
However xor is crititily dependent of the quality of the randomness that
it is provided with. In other words xor is only as strong as your random
number generator.
In addtion if that key is reused (as a number of peaple in the former USSR)
did the systems securaty becomes easyly broken.
Martin Gregory
>
> This is a code fragment from a number validator I wrote.
Whoo hoo - some perl code in this thread!
Elaine -HappyFunBall- Ashton
> though this is not exactly PERL related, it has been mentioned here? how
> does one apply for the Usenet points system... i can think of several
> people on my other favorite news group who need to have applications for
> the program sent to them... i'd love to be able to oblige...
Why do people have such a narrow idea of 'what is Perl related' and what
isn't. This was started by someone who wanted to do an e-commerce
solution via Perl. Now, this has digressed into something else, but I
firmly believe we are all learning something here other than 'Hey, read
the FAQ or Hey, Here is my code, deal!'. Every discipline can learn from
another. I learned something from this today so I feel warm and fuzzy.
> #Obligatiory perl comment
> for (;;) {print "You msut bring us a shrubbery!";}
Uh oh, David, another Python geek. 'We are the knights of Neet!'
Elaine -HappyFunBall- Ashton
Abigail
MCMXCIII in <URL: news:6tpd86$2...@mozo.cc.purdue.edu>:
++ Elaine -HappyFunBall- Ashton <eas...@bbnplanet.com> writes:
++
++ }Ok. I stand corrected. I am still not absolutely certain that this is
++ }100% secure, but certainly much more than I thought. I'll just go mug
++ }the cute waiter instead for my CC fix. ;)
++
++ }Interesting tidbit from www.cypher.net.
++
++ }Why are One-Time Pads Perfectly Secure?
++
++ }If the key is truly random, an xor-based one-time pad is perfectly
++ ^^^^^^^^^^^^^^^^^^^^^^^^^^
++
++ Nobody chooses "truly random" bitstrings for a key.
Ok. Suppose I want to encrypt my name with a 56 bit key, using XOR.
Which key(s) won't I pick? ;)
Don't forget we are talking about CC#. Simple, 16 digit numbers. We don't
even need 16 character strings to encrypt it; another 16 digit number
as key, using addition modulo 10 on a digit-by-digit bases as encryption
algorithm is enough.
(That will give a keyspace as large as the address space, with each key
defining a different bijection between the address space and itself)
Abigail
--
perl -MNet::Dict -we '(Net::Dict -> new (server => "dict.org")\n-> define ("foldoc", "perl")) [0] -> print'
Abigail
<URL: news:6tphj5$6...@enews4.newsguy.com>:
++
++ Abigail writes:
++ >Mark-Jason Dominus (m...@op.net) writes:
++ >++ Yes, but it's not clear that you can trust the user to select a 53-bit
++ key.
++ >
++ >But what keeps you from selecting one for them?
++
++ Sociology and physics, normally. Which is to say, imagine if
++ your bank asked you to remember a 300 word text, or to recite
++ a 120 letter 'random string' over the telephone. People wouldn't
++ accept it, even if it were truly secure (and if they did, they'd likely
++ make errors and get mad). Until recently, it was also surprisingly
++ difficult to physically carry around 2 megabits.
Uhm, uhm, what keeps you from creating a piece of plastic, about 4 inches
by 2.5 inches, with a nice logo and 16 digits on it - to be used as key?
Abigail
--
sub _'_{$_'_=~s/$a/$_/}map{$$_=$Z++}Y,a..z,A..X;*{($_::_=sprintf+q=%X==>"$A$Y".
"$b$r$T$u")=~s~0~O~g;map+_::_,U=>T=>L=>$Z;$_::_}=*_;sub _{print+/.*::(.*)/s}
*_'_=*{chr($b*$e)};*__=*{chr(1<<$e)};
_::_(r(e(k(c(a(H(__(l(r(e(P(__(r(e(h(t(o(n(a(__(t(us(J())))))))))))))))))))))))
Elaine -HappyFunBall- Ashton
> Uhm, uhm, what keeps you from creating a piece of plastic, about 4 inches
> by 2.5 inches, with a nice logo and 16 digits on it - to be used as key?
Well, what do you mean by 'key' in this sense. Practicality and expense
would be my first guess an this. Granted, credit cards do this but I do
generally regard credit cards as being rather behind the times and
barbaric. Besides, if were getting into that we could easily jump to
retinal scanning and other such 'id' sort of things.
Abigail
MCMXCIII in <URL: news:6tpqpl$mvl$1...@godzilla.zeta.org.au>:
++ In <6tp5ds$jap$1...@client3.news.psi.net> abi...@fnx.com (Abigail) writes:
++
++ >Mark-Jason Dominus (m...@op.net) wrote on MDCCCXLII September MCMXCIII in
++ ><URL: news:6touoo$5j0$1...@monet.op.net>:
++ >++
++ >++ I still think `xor' is probably a poor choice.
++ > In fact,
++ > constructing an unbreakable cipher is easy. First choose a random bit
++ > string as the key. Then convert the plaintext into a bit string, for
++ > example by using its ASCII representation.
++
++ However xor is crititily dependent of the quality of the randomness that
++ it is provided with. In other words xor is only as strong as your random
++ number generator.
Certainly.
++ In addtion if that key is reused (as a number of peaple in the former USSR)
++ did the systems securaty becomes easyly broken.
Yes, but only if the plaintext changes. In this scenario, it's really
the encrypted CC# number that is the key (which is stored on the more
safer database) while the cyphertext is send over the possibly snooped
transmission lines.
And CC# numbers aren't supposed to be reused.
Abigail
--
perl5.004 -wMMath::BigInt -e'$^V=new Math::BigInt+qq;$^F$^W783$[$%9889$^F47$|88768$^W596577669$%$^W5$^F3364$[$^W$^F$|838747$[8889739$%$|$^F673$%$^W98$^F76777$=56;;$^U=substr($]=>$|=>5)*(q.25..($^W=@^V))=>do{print+chr$^V%$^U;$^V/=$^U}while$^V!=$^W'
David Formosa
[...]
>can a perl code be made human unreadable? write it once, and sort of convert
>it to a format that is still executable but not readable?
No languge has this ability. Hideing your code dosn't gain you anything.
Ronald J Kimball
> Mary E Tyler wrote:
>
> > though this is not exactly PERL related, it has been mentioned here? how
> > does one apply for the Usenet points system... i can think of several
> > people on my other favorite news group who need to have applications for
> > the program sent to them... i'd love to be able to oblige...
>
> Why do people have such a narrow idea of 'what is Perl related' and what
> isn't. This was started by someone who wanted to do an e-commerce
> solution via Perl. Now, this has digressed into something else, but I
> firmly believe we are all learning something here other than 'Hey, read
> the FAQ or Hey, Here is my code, deal!'. Every discipline can learn from
> another. I learned something from this today so I feel warm and fuzzy.
Why do people have such a broad idea of 'what is Perl related'. This
was started by someone who wanted to do an e-commerce solution,
coincidentally in Perl. And the discussion has continued to have
nothing whatsoever to do with Perl.
If I wanted to read 50-odd messages about XOR encryption and CC
security, I'd be reading an encryption or security newsgroup. Since I
don't read those newsgroups, you may safely assume that I am not
interested in reading discussion of these issues.
Since they are not even remotely Perl specific, I do not expect to read
about them in comp.lang.perl.misc.
Here's a straightforward example:
Suppose I wanted to write a Hello World script in Perl. If I was asking
how to print "Hello World", that would be Perl specific. If I was
asking whether it would be better to follow "Hello World" with a period
or an exclamation mark, that would not be Perl specific.
--
_ / ' _ / - aka - r...@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chip...@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
Tom Mornini
: It is better than nothing, however, it is not a complete solution to the
: problem. If e-commerce is to survive and thrive people must have
: confidence that their cards are protected. I shop a lot on-line and have
: had the one card I use for such purposes replaced 2 or 3 times due to
: the number being stolen.
I don't understand why people are so paranoid about this! Do you use that
card ONLY for on-line transactions? If not, perhaps it was stolen out of
the trash can at the local 5 and dime...
For that matter, perhaps an employee at (your e-commerce vendor here) stole
it while placing the transaction, or auditing the transactions, etc.
I'm not saying that CC security is not an issue. And I would like to think
that EVERYONE who I give my card to EVERYWHERE I use it cares as much about
this as all the folks participating in this thread.
However, while everyone is sweating the online security issue, I've always
felt that a much more profitable attack would be a simple analog splice-in
on the phone system of (your non e-commerce vendor here). They could just
listen in, write the numbers and important information down (or just record
it) and then not have to be a propeller head at all!
-- Tom Mornini
-- InfoMania
Andrew Johnson
[snip]
> Here's a straightforward example:
> Suppose I wanted to write a Hello World script in Perl. If I was asking
> how to print "Hello World", that would be Perl specific. If I was
> asking whether it would be better to follow "Hello World" with a period
> or an exclamation mark, that would not be Perl specific.
obviously, 'Hello World' should be followed by an exclamation mark,
whereas, 'hello world' should simply be followed by period---is there
not a FAQ on this?!.
regards
andrew
:-)
Stefan Berglund
> I am about to write a simple script to encrypt/decrypt credit card numbers
> using xor and a key supplied by credit card owner. I wanted to learn your
> thoughts about it:
To use the words of Bruce Schneier in Applied Cryptography:
An XOR might keep your kid sister from reading your files, but it
won't stop a cryptanalyst for more than a few minutes.
An XOR is very simple to crack it is really just a polyalphabetic
Vigenere variant, this is how you do:
1. Discover the keylength.
Shift the ciphertext against itself various amounts of bytes and
count those bytes that are equal. When you have shifted a whole
keylength you will see a dramatic change in the number of equal
bytes, from less than .4% to something around 6%
The smallest shiftlength with this large index is the keylength.
2. Get rid of the key and get the plaintext
Shift the ciphertext that amount of bytes and XOR it against
itself. This removes the key and leaves you with the plaintext
XOR:ed with itself shifted keylength bytes. As you know that it is
a creditcard number and therefor has a specific format (with for
example a checksum) it is an easy task to discover the number.
This will only take a few seconds with a computer and a couple of
minutes with pen and paper.
What is really frightening is that this algorithm is actually used in
the MS-DOS and Mac world.
Why not use a real crypto algorithm?
PGP is freely available. So is some DES implementations and numerous of
others, see for example ftp://ftp.funet.fi/pub/crypt
I recommend that you get Bruce Schneiers book if you are generally
interested in cryptography and/or use cryptography in your work.
And BTW this has very little to do with perl you will get more
responses (or more probably get flamed...) in sci.crypt*
Hope that this got you on another track!
--
/Stefan
f94...@dd.chalmers.se
Life - the ultimate practical joke
finger f94st...@dd.chalmers.se for public pgp-key
Mary E Tyler
>
> In article <360063...@DejahsPrivateIce.com>,
> Mary E Tyler <de...@DejahsPrivateIce.com> wrote:
>
> The users, as a group, must constitute an ergodic source of
> information with an entropy of at least 53.15 bits per key.
>
> >this is an actual question.
>
> That is the actual answer.
>
> Hope this helps.
thanks mark!
it might have been an answer... but it was not one i understood. except
that it might be some sort of strange joke.
ask lori about having peas for supper tonight.
dejah
Mark-Jason Dominus
Stefan Berglund <f94stb...@dd.chalmers.se> wrote:
>An XOR might keep your kid sister from reading your files, but it
>won't stop a cryptanalyst for more than a few minutes.
Bruce is talking about XOR ciphers where the key is periodic. That is
not germane to this discussion.
>
>An XOR is very simple to crack it is really just a polyalphabetic
>Vigenere variant, this is how you do:
>
>1. Discover the keylength.
> Shift the ciphertext against itself various amounts of bytes and
> count those bytes that are equal. When you have shifted a whole
> keylength you will see a dramatic change in the number of equal
> bytes, from less than .4% to something around 6%
> The smallest shiftlength with this large index is the keylength.
In this case, you won't, because the ciphertext is only seven bytes
long, and the keylength is also seven bytes. In fact, you can skip
this step and just assume that the key is seven bytes; I will give you
that for free.
>2. Get rid of the key and get the plaintext
> Shift the ciphertext that amount of bytes and XOR it against
> itself.
Shifting the ciphertext seven bytes and XORing it with itself will
always yield "\0\0\0\0\0\0\0".
:)
> This removes the key and leaves you with the plaintext
> XOR:ed with itself shifted keylength bytes. As you know that it is
> a creditcard number and therefor has a specific format (with for
> example a checksum) it is an easy task to discover the number.
I think you're going to have a difficult task extracting a credit card
number, or anything else, from a string of nulls. :)
In all seriousness, I did post my credit card number encrypted in this
fashion. You are invited to decrypt it if you so desire.
>I recommend that you get Bruce Schneiers book if you are generally
>interested in cryptography and/or use cryptography in your work.
I agree. Schneier's book is really good.
I would join Felix Gallo in advising people to stay away from
cryptography. Here we have an example of a person with good
intentions, who read the right book, but who misunderstood the context
of what he read and ended up with a conclusion that was completely
wrong for the problem domain.
Mark-Jason Dominus
Mary E Tyler <de...@DejahsPrivateIce.com> wrote:
>it might have been an answer... but it was not one i understood. except
>that it might be some sort of strange joke.
Sorry. It wasn't a strange joke, although I admit that I've never
felt more peculiar about adding `hope this helps' at the end of an
article.
Maybe a better answer to this question is:
1. There are ways to measure the randomness of an information source.
2. The more random it is the more rapidly it generates information.
(Extreme example: A source that generates the same thing every time
is not random and is not generating any information either.)
3. Information content and randomness are both measured in `bits'.
4. To be suitably random, the source of keys (the users) must generate
information at a rate of at least 53.15 bits per key.
5. To find out what this really means, see (for example) `Symbols,
Signals, and Noise', by J.R. Pierce. (Harper, 1961.) It is a
really fun introduction to information theory.
Abigail
September MCMXCIII in <URL: news:36008482...@bbnplanet.com>:
++ Abigail wrote:
++
++ > Uhm, uhm, what keeps you from creating a piece of plastic, about 4 inches
++ > by 2.5 inches, with a nice logo and 16 digits on it - to be used as key?
++
++ Well, what do you mean by 'key' in this sense. Practicality and expense
++ would be my first guess an this. Granted, credit cards do this but I do
++ generally regard credit cards as being rather behind the times and
++ barbaric. Besides, if were getting into that we could easily jump to
++ retinal scanning and other such 'id' sort of things.
Uhm. So, it's ok for people to have to remember their 16 digit CC#,
but a 16 digit key is too much?
I fail to understand.
Abigail
--
perl -MLWP::UserAgent -MHTML::TreeBuilder -MHTML::FormatText -wle'print +(HTML::FormatText -> new -> format (HTML::TreeBuilder -> new -> parse (LWP::UserAgent -> new -> request (HTTP::Request -> new ("GET", "http://work.ucsd.edu:5141/cgi-bin/http_webster?isindex=perl")) -> content)) =~ /(.*\))[-\s]+Addition/s) [0]'
Elaine -HappyFunBall- Ashton
> Why do people have such a broad idea of 'what is Perl related'. This
> was started by someone who wanted to do an e-commerce solution,
> coincidentally in Perl. And the discussion has continued to have
> nothing whatsoever to do with Perl.
Take my point. Perl is not an entity living in a vacuum independent of
anything else. Yes, it did start out as a Perl question on e-commerce
but digressed into a discussion on security and encryption. Perhaps you
are uninterested in anything along those lines, but since Perl people in
my general experience tend to be 'jack of all trade' type of people, it
was somewhat a linear progression of the topic.
Security is an important point whether you're dealing with Perl or
something else. And certainly it was a much more interesting discourse
than 'hey, why doesn't this 3 line perl program work?'. It's only Usenet
Elaine -HappyFunBall- Ashton
> I don't understand why people are so paranoid about this! Do you use that
> card ONLY for on-line transactions? If not, perhaps it was stolen out of
> the trash can at the local 5 and dime...
What? You missed the point. I use e-commerce and I have been burned by
it too. I also have managed machines with 0 level security on home-grown
awful Perl CC transaction scripts. If we aren't asking the tough
questions about security, who will? My computer illiterate mother? I'm
not paranoid, but I do lock my door at night.
> For that matter, perhaps an employee at (your e-commerce vendor here) stole
> it while placing the transaction, or auditing the transactions, etc.
Perhaps, but as either the application developer or the SA, that is out
of my control.
> I'm not saying that CC security is not an issue. And I would like to think
> that EVERYONE who I give my card to EVERYWHERE I use it cares as much about
> this as all the folks participating in this thread.
Probably not. I usually thank the rare clerk that checks my signature
against the card. The amount of information collected around your CC is
staggering. I like to protect that.
> However, while everyone is sweating the online security issue, I've always
> felt that a much more profitable attack would be a simple analog splice-in
> on the phone system of (your non e-commerce vendor here). They could just
> listen in, write the numbers and important information down (or just record
> it) and then not have to be a propeller head at all!
There is no challenge in that.
Elaine -HappyFunBall- Ashton
> Uhm. So, it's ok for people to have to remember their 16 digit CC#,
> but a 16 digit key is too much?
No, what I'm saying that if you are going to go the way of the card for
a key then maybe consider other alternatives to that. The card is a
comfortable object that people already know. Why not a digital
signature, a finger-print scanning mouse (My boss wanted to start using
these for our workstations) as the key could be generated from the
pattern....I'm digressing but I was letting my imagination go astray.
> perl -MLWP::UserAgent -MHTML::TreeBuilder -MHTML::FormatText -wle'print +(HTML::FormatText -> new -> format (HTML::TreeBuilder -> new -> parse (LWP::UserAgent -> new -> request (HTTP::Request -> new ("GET", "http://work.ucsd.edu:5141/cgi-bin/http_webster?isindex=perl")) -> content)) =~ /(.*\))[-\s]+Addition/s) [0]'
This is cute.
Seth Gordon
*If* each user's credit card security code is (a) completely random, (b) not
intercepted between the user and your program, and (c) has at least as many bits
as (your representation of) the credit card number itself, then you have what's
called a "one-time pad", which is unbreakable. In theory.
In practice, it's hard to meet conditions (a) and (b). For example, people who
choose their own passwords will often choose English words, or common misspellings
of English words, or common words in other languages, etc. By taking advantage of
this regularity, a cryptanalyst can narrow the range of keys to be guessed.
Ten or twenty years ago, Unix systems would encrypt passwords using a system
similar to yours. Now, with a moderately fast computer and a dictionary on
CD-ROM, it's not hard to break a file of passwords encrypted this way.
In a later message, you discuss compiling the script so that it is no longer
human-readable. I'm not sure how much of an advantage this will get you.
Machine-language programming is not popular these days (you dang kids have it so
easy :-), but it's not too hard to disassemble binary code and then try to figure
out what it does.
The sci.crypt FAQs and have a lot of very useful information about cryptography,
and they include pointers to other resources. If you're working on this for
academic purposes or just out of your own curiosity, I encourage you to look at
these sources.
If you're actually building this system for commercial purposes, I strongly
encourage you to hire a professional. Look at it this way: you don't have
experience *making* crypto systems, but some day, people who *do* have lots of
experience *breaking* crypto systems might come across your site ... and if they
can steal a few thousand bucks by breaking into yours, they might do so.
--
I have a simply marvelous algorithm that will factor any number N
in O(log N) time, but it won't fit in this .signature block.
== seth gordon == sgo...@kenan.com == standard disclaimer ==
== documentation group, kenan systems corp., cambridge, ma ==
Stefan Berglund
> In article <6tqr7o$en6$1...@eol.dd.chalmers.se>,
> Stefan Berglund <f94stb...@dd.chalmers.se> wrote:
>>An XOR might keep your kid sister from reading your files, but it
>>won't stop a cryptanalyst for more than a few minutes.
>
> Bruce is talking about XOR ciphers where the key is periodic. That is
> not germane to this discussion.
I have to disagree as the original post <6tn6f5$h5s$1...@nnrp1.dejanews.com>
said:
" (if length of CCSC is smaller than CC number's length, i will extend
" it to fit in such a way that i have not thougth about yet)
Where CC is the credit card and CCSC is the key.
If (and only if) he demands a keylength of the same length as the
length of the credit card number it should be equivalent to a
one-time-pad and therefor secure. (I thought of that a little bit to
late, I admit guilty of posting to fast, so sue me :)
This will also mean that the key must have at least fair random
properties, I would not trust anybody to come up with such a key.
OTOH a credit card number has a very specific format so you know quite
a bit about your cleartext, this might prove important!
>>An XOR is very simple to crack it is really just a polyalphabetic
>>Vigenere variant, this is how you do:
>>
>>1. Discover the keylength.
>> Shift the ciphertext against itself various amounts of bytes and
>> count those bytes that are equal. When you have shifted a whole
>> keylength you will see a dramatic change in the number of equal
>> bytes, from less than .4% to something around 6%
>> The smallest shiftlength with this large index is the keylength.
>
> In this case, you won't, because the ciphertext is only seven bytes
> long, and the keylength is also seven bytes. In fact, you can skip
> this step and just assume that the key is seven bytes; I will give you
> that for free.
The number of numbers on a credit card varies with the "vendor", a
cleartext of seven bytes would correspond to 14 numbers on the CC.
AFAIK there can be up to 20 numbers. For example there is 16 on my cards.
This will mean a key of up to 10 characters, in my opinion to long for
people to remember => they will be set so that they will be
voulnerable to a dictionary attack.
> Shifting the ciphertext seven bytes and XORing it with itself will
> always yield "\0\0\0\0\0\0\0".
No! As the shift is cyclic ABCDEF shifted three steps will become
DEFABC, not \0\0\0ABC!
Which of cource mean that my attack sketch is not effective if the key
is the same length as the cleartext.
In another message the original poster says that he uses SSL etc for
transfers, why not have at least comparable strength for the database?
> I would join Felix Gallo in advising people to stay away from
> cryptography. Here we have an example of a person with good
> intentions, who read the right book, but who misunderstood the context
> of what he read and ended up with a conclusion that was completely
> wrong for the problem domain.
No I still doesn't think that my conclusion is wrong: Don't use XOR
with a key that is shorter than the data and isn't random.
But if those condictions holds than you will be safe, but they don't
hold in the original post and I very much doubt that they will hold in
real life.
Mark-Jason Dominus
Stefan Berglund <f94stb...@dd.chalmers.se> wrote:
>I have to disagree as the original post <6tn6f5$h5s$1...@nnrp1.dejanews.com>
>said:
Yes, my apologies. I made the same mistake here that I did when I
responded to Mike Gebis: I assumed that you would pack the CC# into 7
bytes before xoring it. But the original poster was planing to xor
the *unpacked* credit card number, which is 16 bytes long, not 7. I
answered you without making explicit that what I was thinking of was
something different from what the original poster was thinking of.
So we are both right, and the fault is mine for not making clear the
difference between the two strategies.
Mark-Jason Dominus
Seth Gordon <sgo...@kenan.com> wrote:
>Ten or twenty years ago, Unix systems would encrypt passwords using a system
>similar to yours.
I don't think so. Originally, the passwords were unencrypted. Later,
they were hashed the way they are now, but with a software version of
the M209 cipher machine. More recently (But certainly for the last
twenty years) the hashing system has been based on DES.
For full details, see ``Password Security: A Case History'' by Robert
Morris and Ken Thompson.
>Now, with a moderately fast computer and a dictionary on CD-ROM, it's
>not hard to break a file of passwords encrypted this way.
The situation with passwords is very different. With passwords, you
have a known plaintext and a known ciphertext, and you are trying to
guess the key. If you guess right, you know right away, because the
key turns the plaintext into the target ciphertext. But with the
credit card numbers, you have only the ciphertext, and you want to
figure out the plaintext without the key. If the key space is large
enough, guessing the key is impossible because even if you guess
right you cannot be sure that you have the plaintext you want and not
something else that just looks like it.
>If you're actually building this system for commercial purposes, I strongly
>encourage you to hire a professional.
Certainly good advice.
Felix S. Gallo
Abigail writes:
>Felix S. Gallo writes:
>++ Sociology and physics, normally. Which is to say, imagine if
>++ your bank asked you to remember a 300 word text, or to recite
>++ a 120 letter 'random string' over the telephone. People wouldn't
>++ accept it, even if it were truly secure (and if they did, they'd likely
>++ make errors and get mad). Until recently, it was also surprisingly
>++ difficult to physically carry around 2 megabits.
>
Possession of such a thing can easily be faked when purchasing over
long distances. For instance, right after figuring out Mark-Jason's
credit card number, I just ordered fifty copies of 'Applied Cryptography'
to be delivered to his house, courtesy of Amazon. He should've chosen
something larger than /usr/dict/words, and he should have known about
the credit card checksum. Tsk.
ObPerl: I hereby suggest a new primitive, 'forwords', which iterates
over the contents of /usr/dict/words. Would've saved me about 5
minutes.
Felix
p.s. psych
Mark-Jason Dominus
Felix S. Gallo <f...@newsguy.com> wrote:
>p.s. psych
Bah. I already mentioned the checksums. At best, they are only 91%
effective.
Mary E Tyler
why 53.15 bits... and how do you have 15% of a bit... i thought a "bit"
was either on or off... am i missing a piece of vocabulary here?
dejah, what i don't know, won't hurt me? much?
--
Abigail
in <URL: news:6trip1$1...@enews1.newsguy.com>:
++
++ Abigail writes:
++ >Felix S. Gallo writes:
++ >++ Sociology and physics, normally. Which is to say, imagine if
++ >++ your bank asked you to remember a 300 word text, or to recite
++ >++ a 120 letter 'random string' over the telephone. People wouldn't
++ >++ accept it, even if it were truly secure (and if they did, they'd likely
++ >++ make errors and get mad). Until recently, it was also surprisingly
++ >++ difficult to physically carry around 2 megabits.
++ >
++ >Uhm, uhm, what keeps you from creating a piece of plastic, about 4 inches
++ >by 2.5 inches, with a nice logo and 16 digits on it - to be used as key?
++
++ Possession of such a thing can easily be faked when purchasing over
++ long distances.
People seem to have no problem with that when it comes to CC#'s themselves.
Abigail
--
perl -wle 'print "Prime" if (1 x shift) !~ /^1?$|^(11+?)\1+$/'
Ben Coleman
<de...@DejahsPrivateIce.com> wrote:
>the first 4 refer to the clearing house(for lack of a better term). the
>second four refer to your bank. the third four are a reference internal
>to your bank. the fourth are your account number. or so i have been
>told.
Actually, I think this varies depending on the card type. E.g. for Visa
cards, the first 6 digits are a BIN(Bank Identification Number) identifying
the issuing bank. Note also that while credit card numbers are often 16
digits, they can be other lengths(American Express is typically 15).
Ben
--
Ben Coleman
Senior Systems Analyst
TermNet Merchant Services, Inc.
Atlanta, GA
Michael J Gebis
Last night, Mark-Jason Dominus posted a challenge: he encrypted his credit
card number and invited anyone to try to break it. Here's what I
found trying to do so.
PART I: THE BAD SYSTEM.
Please notice that this thread started with a proposal for an encryption
system which was not secure--I posted code which very quickly ran
a dictionary attack against the original system. For historical
sake, here's a very quick demonstration of that bad system:
-----------------------------------------------------------------------------
sub badcrypt ($$) {
my($cc,$key)=@_;
return $cc^$key;
}
# Prints "X\@QVCE]"
print badcrypt('12345678','insecure');
-----------------------------------------------------------------------------
What's wrong with this sytem? Well, given only the ciphertext "\[XQ", we
know the following:
The first letter must be one of "hijklmno`a"
The second letter must be one of "lmnohijkde"
The third letter must be one of "pqrstuvwxy"
The fourth letter must be one of "a`cbedgfih"
...and so on.
If we search the dictonary for words that match this, we find three:
hitherto:05493112
hothouse:03499668
insecure:12345678
The only knowledge about the plaintext we've used is that it is comprised
of only digits, and we're already down to three matches!
Addmittedly, people would probably choose better passwords, but with
some work, and more knowledge about the form of the plaintext (like it
must be a valid CC#) we could apply the same techniques recursively to
break pass phrases, not just a single word.
This is a bad system.
PART II: The good system.
Mark-Jason Dominus then proposed a new system. Here's how it works (see
his post for more examples):
If the credit card number is 1234-5678-9012-3456, treat it as a very
large integer, that is, approximately 1.23456*10^15. (I'm approximating
to convey the size of the number-in the actual implementation, you have
to deal with the number exactly.) Convert this number to binary, and
then pack that into a seven-digit string. Xor this string with a
seven-digit key.
Mark-Jason was bold enough to encrypt a real credit-card with a real
dictionary word and post the result.
Well, this system immediately looks better. We know that credit-card
numbers have 16 digits (we can ignore the ones that don't, since they
seem to be rare) so we can reject any ciphertext/key pair that
gives us a plaintext with 17 digits, and a back-of-the envelope
calculation shows us that lets us eliminate about 30% of the possible
keys right away. That sounds good, but it really doesn't produce anything
useful. Applying this to MJD's ciphertext let me eliminate around 10,000
of the 45,000 words in my /usr/dict/words.
We can do better by applying some knowledge about how credit card numbers
are structured. There is a checksum digit that lets us elminate
a full 90% of the remaining keys. If we assume it's a well-known
card (visa, mastercard, discover, amex) we can elminate a lot of keys.
Using this knowledge on MJD's ciphertext, we find that we've narrowed
the list of potential keys to 277 (11 of these are mastercard numbers,
266 are visa numbers).
Sounds promising, doesn't it? We've exhausted our list of rules, but
we've got a relatively short list.
Unfortunately, here's a problem: given a "random" ciphertext, and using
the same set of rules, we end up with a list of comparable length. In
other words, applying all of our assumptions to a key that does not
work still gets us a list of about 300 possiblities. All of our
work was for nothing, really-- we've done a lot of work to generate a list
of plausible credit-card numbers, but not much else.
Let's take another look at this. Based on the ciphertext posted yesterday,
here are some of the possiblities for key/plaintext pairs.
...
domino1,4329669516373071: visa
donatio,4329656498956817: visa
doorbel,4329660540823058: visa
doormen,4329660540757520: visa
dope123,4329682205667661: visa
dove123,4329690795602253: visa
dover12,4329690791211596: visa
dozen12,4329707969770060: visa
drafts1,4359304607871055: visa
dragons,4359304623009037: visa
drained,4359304790713882: visa
...
All of these encrypt to the SAME CIPHERTEXT. From an attacker's point
of view, they are indistiguishable. And we've made a whole truckload
of assumptions about the key that might not even be true. As MJD
pointed out yesterday, 277 is a lot of numbers to attempt.
I'm not ready to proclaim this system completely secure--I'm not a
cryptographer, and I may have easily overlooked something. (Are there
"weak" keys? Did I forget something? I'm just some shmoe on the
net for all you know.) But it does appear that you don't gain anything
by using a dictionary attack on MJD's system, and I don't immediately
see any other flaws. Once again, the "hire a professional if you
really care" phrase must be hauled out.
PART III: Details.
So, was MJD's key/cc# on my list? Well, apparently, one of us had a
bug in our implementation, because it did not show up on the list.
(Oddly enough, we both think it's our OWN software. I'd like to blame
Mark-Jason, but my code is really ugly.) I sent this list of
candidates to MJD last night, and this morning, when he did not see
his CC#, he realized he may have made a mistake and recalculated his
ciphertext. Unfortunately, he ruined the drama by sending me the
PLAINTEXT of his CC#.
It is interesting to note that I was immediately able to distinguish
the difference. This is a reflection of our knowledge about the
structure of the key and the plaintext.
I'm convinced that had our programs been bug free, his number would have
shown up on my list. I'm also convinced that this really wouldn't have
mattered, because I wouldn't have had enough information to get to a
smaller list.
----
I sent this off to Mark-Jason for comments before posting, and here's
what he had to say:
I guess I have one comment: I didn't use a program to encrypt the
original number. I used unix `bc' to convert the 16-digit credit card
number to the binary number, and then I used
perl -le 'print pack "B8 B8 B8 B8 B8 B8 B8", "00001100", "110101010", etc.'
to pack it into 8 characters. I did it all manually, and that's why I
think I got the wrong answer--it would have been easy to let some
digit slip somehow. When I did it again this morning, I got
k\cN\242\324\352\314\372
[Note from Mike: I can't post 8-bit, so this was converted by
hand. I may have mangled it. Beware. -MJG]
which is different from what I posted in the last two characters, and
that suggests that it really was my fault, and not yours. If you want
to mention the correct ciphertext, that would be fine with me.
You might also want to add that the card number was for a closed
account.
--
Mike Gebis ge...@ecn.purdue.edu mge...@eternal.net
Mark-Jason Dominus
Mary E Tyler <de...@DejahsPrivateIce.com> wrote:
One decimal digit contains the same information as 3.322 binary
digits. A credit card number is 16 digits long, so it contains
16*3.332 = 53.15 bits of information. (Less, if you discount for the
check digits.)
> and how do you have 15% of a bit...
In exactly the same way that the average family has 2.6 children.
Jim Michael
: any advice ? for commercial usage? I checked out PGP 5.0 for unix but its
: licencing is rather expensive for us. (at least for a few months)
I think there are no commercial restrictions on Blowfish.
Cheers,
Jim
Ben Sauvin
One suspects that the border between "perl-related" and something else
divides that which is explicitly furnished by the Perl programming language,
its various modules and incidental accompanying documentation from that
which can be addressed by any (or most) programming languages, even if only
at the concept level.
Elaine -HappyFunBall- Ashton wrote:
> Ronald J Kimball wrote:
>
> > Why do people have such a broad idea of 'what is Perl related'. This
> > was started by someone who wanted to do an e-commerce solution,
> > coincidentally in Perl. And the discussion has continued to have
> > nothing whatsoever to do with Perl.
>
> Take my point. Perl is not an entity living in a vacuum independent of
> anything else. Yes, it did start out as a Perl question on e-commerce
> but digressed into a discussion on security and encryption. Perhaps you
> are uninterested in anything along those lines, but since Perl people in
> my general experience tend to be 'jack of all trade' type of people, it
> was somewhat a linear progression of the topic.
>
> Security is an important point whether you're dealing with Perl or
> something else. And certainly it was a much more interesting discourse
> than 'hey, why doesn't this 3 line perl program work?'. It's only Usenet
>
Felix S. Gallo
Abigail writes:
>Felix S. Gallo writes:
>++ Possession of such a thing can easily be faked when purchasing over
>++ long distances.
>
>People seem to have no problem with that when it comes to CC#'s themselves.
Sociologically, they have no problem, but in reality, many millions of
dollars
are lost per year because of credit card fraud and theft. Which is why I
said that what you really want is to carry around 2 megabits of key.
By the way, if I keep posting unrelated topics to a perl newsgroup, pretty
soon I'm going to catch up to Tom Christiansen in Usenet points!
Felix
gerald clark
We don't need a news group! it's ALL in the manual, and anything else is
OFF TOPIC !!!
-^-----=
{ (O_ \ =
{ (O / =
-v-----=
--
Gerald L. Clark
Remove the -nospam- when replying.
Ronald J Kimball
>
> Ronald J Kimball wrote:
>
> > Why do people have such a broad idea of 'what is Perl related'. This
> > was started by someone who wanted to do an e-commerce solution,
> > coincidentally in Perl. And the discussion has continued to have
> > nothing whatsoever to do with Perl.
>
> Take my point. Perl is not an entity living in a vacuum independent of
> anything else. Yes, it did start out as a Perl question on e-commerce
> but digressed into a discussion on security and encryption.
I disagree. There was no Perl question in the original post. The
poster wanted to know if using XOR encryption to protect his CC database
was a good idea. Nothing about Perl in that.
> Perhaps you
> are uninterested in anything along those lines, but since Perl people in
> my general experience tend to be 'jack of all trade' type of people, it
> was somewhat a linear progression of the topic.
There was no linear progression. The discussion has been about
encryption and security from the beginning. The original post should
have been made to a newsgroup for encryption and/or security. Any Perl
programmers with a genuine interest in encryption and/or security would
have been able to find it there. More importantly, anyone at all with a
genuine interest, even non-Perl-programmers, would have been able to
find it there.
> Security is an important point whether you're dealing with Perl or
> something else. And certainly it was a much more interesting discourse
> than 'hey, why doesn't this 3 line perl program work?'. It's only Usenet
Exactly. "...or something else." Hence, it is not appropriate to
discuss general security issues in cl.perl.m. Unless you want to
exclude all those people who are dealing with something else?
Whether or not it was more interesting is entirely subjective, of
course.
:-)
--
_ / ' _ / - aka - r...@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chip...@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
Randal Schwartz
Mark-Jason> One decimal digit contains the same information as 3.322 binary
Mark-Jason> digits. A credit card number is 16 digits long, so it contains
Mark-Jason> 16*3.332 = 53.15 bits of information. (Less, if you discount for the
Mark-Jason> check digits.)
Exactly 3.332 bits less, by my determination. :)
(The final digit is completely computable from the remaining digits.)
--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <mer...@stonehenge.com> Snail: (Call) PGP-Key: (finger mer...@teleport.com)
Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me
Michael J Gebis
}>>>>> "Mark-Jason" == Mark-Jason Dominus <m...@op.net> writes:
}Mark-Jason> One decimal digit contains the same information as 3.322 binary
}Mark-Jason> digits. A credit card number is 16 digits long, so it contains
}Mark-Jason> 16*3.332 = 53.15 bits of information. (Less, if you discount for the
}Mark-Jason> check digits.)
}Exactly 3.332 bits less, by my determination. :)
}(The final digit is completely computable from the remaining digits.)
Actually, you can get as low as 47.01501624516068193992.
98.5779% of all 16-digit numbers can be immediately eliminated as not a
visa, mastercard, amex, diners-club, carte-blanche, discover, enroute, or
jcb card number.
Elaine -HappyFunBall- Ashton
> Actually, you can get as low as 47.01501624516068193992.
>
> 98.5779% of all 16-digit numbers can be immediately eliminated as not a
> visa, mastercard, amex, diners-club, carte-blanche, discover, enroute, or
> jcb card number.
True. But, regardless of the encryption algorithim, one can still obtain
the key by modern convention fairly easily. Encryption isn't the only
answer, good scripts, good admin and smart security is. No matter how
good the encryption, someone will have the time and the ingenuity to
break it. Purple was broken, XOR can be broken. Nothing is 100% secure.
Nothing. With 98.5% of the numbers eliminated you can pretty much go
through the national database and make an educated choice should you
choose to. There is little guesswork there.
I'll tell a little story here which may illuminate some of my earlier
posts. I was asked to help tiger team a financial server on a network
that was not in our baliwick by the president of the company. We hacked
the CC server in less than an hour and sent the Pres. a bouquet of
flowers via FTD on his CC shortly thereafter to illustrate our point.
The DBA got a wedgie and called the FBI due to his unwitting ignorance
about what was really going on..he thought he had a secure network....he
used XOR.
btw - To the person who broke MJD's CC#, I'll have a beer in your
general direction tonite just because. :)
GAZZA
>
> bey...@my-dejanews.com writes:
> >if the secret key is not an easy to remember key, than all these
> >are useless.
> >that's why i did not want its length to be restricted with
> >CC#+expiration. if a shorter secret key is supplied, then the
> >script will generate the other parts from the supplied one.
>
> Length is not an important thing _at all_.
>
> Entropy is the only important thing.
Err... we're talking about XOR here, right?
Let us suppose I have a key that is 4 bits long. Say, 0110.
The following 'plaintext' numbers encrypted with this key
give these results:
10110 xor 0110 = 10000
110110 xor 0110 = 110000
IOW, it means that there is a definite drop in entropy if
you decrease the length of the key to less than the length
of the plaintext - the above example shows that MSBs are
not encrypted at all.
A trivial example would be a 1 bit key, where I only have
to guess that single bit. Or a 0 bit key, where
ciphertext = plaintext.
I understand you're suggesting that entropy causes length,
rather than length causes entropy. While I agree that
extending the length does not automatically increase the
entropy of the key, REDUCING the length automatically DECREASES
the entropy of the key. So I think the two are interdependent,
rather than entropy being the determining factor.
--
Cheers,
GAZZA
Mary E Tyler
>
> In article <36016B...@DejahsPrivateIce.com>,
> Mary E Tyler <de...@DejahsPrivateIce.com> wrote:
> >why 53.15 bits...
>
>
> > and how do you have 15% of a bit...
>
> In exactly the same way that the average family has 2.6 children.
i'll ask Matthew's pardon, for feeling so dumb...
HUH!!!???
stupid self taught programmer.
dejah
Michael J Gebis
It also appears there is not a perl module for Blowfish.
This may need to be fixed. :)
Jim Michael
> gene...@netcom.com (Jim Michael) writes:
> }I think there are no commercial restrictions on Blowfish.
>
> It also appears there is not a perl module for Blowfish.
>
> This may need to be fixed. :)
Yes. For starters, here is a source for more info:
http://www.counterpane.com/blowfish.html
Cheers,
Jim
Mark-Jason Dominus
Mary E Tyler <de...@DejahsPrivateIce.com> wrote:
>> > and how do you have 15% of a bit...
>>
>> In exactly the same way that the average family has 2.6 children.
>
>i'll ask Matthew's pardon, for feeling so dumb...
>
>HUH!!!???
Well, let's try it a little differently. A bit it the amount of
information on one binary digit. Let's try to figure out how much
information is in one decimal digit. If I have a decimal digit, and I
want to tell you what it is, how many binary digits do I need to do
that?
I can make a table like this:
Digit Binary code
0 0000
1 0001
2 0010
3 0011
4 0100
5 0101
6 0110
7 0111
8 1000
9 1001
If I need to send a decimal digit, I can find the corresponding set of
binary digits from the table and send you that instead. You have a
copy of the table, and when you receive the for binary digits, you
look in the table, and then you know what decimal digit I am talking
about.
If we agree on the codes in advance, I can send you four binary
digits, and that is enough to tell you what decimal digit I am
thinking of. In fact, it's more than enough, because there are six
codes I didn't use at all. On the other hand, three binary digits is
not enough, because there are only 8 ways to put together three binary
digits, and I need at least 10 ways, one for each decimal digit.
So a decimal digit contains more than 3 bits of information, but less
than 4.
Now suppose we want to send three-digit decimal numbers. Obviously we
could use the table above and use 12 binary digits for each one. But
if we change the code table we can do better, only 10 binary digits
instead of 12:
Digit group Binary code
000 0000000000
001 0000000001
002 0000000010
... ...
729 1011011001
... ...
999 1111100111
Ten binary digits is enough. There are 1,024 ways to string together
ten binary digits. But nine binary digits is not enough, because
there are only 512 ways to string together nine binary digits, and we
need at least 1,000.
So
3 decimal digits contain more information than 9 binary digits
3 decimal digits contain less information than 10 binary digits
A decimal digit contains between 3 and 3.33 bits. 3.33 is much closer
to the truth, because 3 decimal digits (1000 combinations) are
*almost* enough to encode any combination of 10 binary digits (1024
combinations), whereas 9 binary digits (512 combinations) are only
enough to encode half the possible combinations of 3 decimal digits
(1000 combinations).
The actual answer turns out to be that one decimal digit contains
about 3.3219 bits of information. Over the long haul, in long
messages, you can replace a decimal digit with about 3.3219 binary
digits. In short messages of only a few digits, you won't be able to
do so well. If you're only sending one decimal digit, you can't send
3.3219 bits, because, as you pointed out, there is no such thing as a
fractional bit. You have to round up and send 4 binary digits instead
of 3.3219. If you're only sending three decimal digits, you have to
round up and send 10 binary digits instead of 9.9657. But if you're
sending 10,000 decimal digits, it is a very simple matter to encode
them with 33,220 binary digits.
That is how you can have a fractional number of bits.