Cryptography-Digest Digest #338, Volume #13 Fri, 15 Dec 00 18:13:01 EST
Contents:
Securing credit card numbers ([EMAIL PROTECTED])
Re: Q: Result of an old thread? (David Schwartz)
Re: Encryptian of data over radio transmission (John Bailey)
Re: Visual Basic Source Code (Simon Best)
Re: Protocol for computer go (Walter Hofmann)
Re: Protocol for computer go (Walter Hofmann)
Re: Q: Result of an old thread? (Simon Best)
Re: Q: Result of an old thread? (David Schwartz)
Re: Q: Result of an old thread? (Simon Best)
Re: Q: Result of an old thread? (Mok-Kong Shen)
Re: Protocol for computer go (Francois Grieu)
Re: Q: Result of an old thread? (John Myre)
On XTR (JCA)
Re: Protocol for computer go (David Schwartz)
Re: Q: Result of an old thread? (Simon Best)
Re: Q: Result of an old thread? (Simon Best)
Re: Custom Encryption Algorithm ("Michael")
Re: Q: Result of an old thread? (Bryan Olson)
Re: Visual Basic Source Code ("Jason Bock")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Securing credit card numbers
Date: Fri, 15 Dec 2000 20:21:08 GMT
Hi, I am working on an e-commerce site and I�m facing the problem of
storing credit card numbers securely on our database.
I have been researching for a solution for the last few weeks however I
still don't have a clear approach.
I would appreciate if you can give me a hand on the securing process.
The goal
======
- Credit card numbers must be stored encrypted on the database.
- For statistical analysis and fraud detection we need the encrypted
card number to be unique, I mean that the encrypted string for one card
is the same in all cases �this means that we cannot use random salt
values to help the encryption-.
Card number problems
================
The primary problem is that credit card numbers are not very long, and
are quite predictable. They use a 16-digit number for the card. The
first 4 digit is the bank identifier and the next 12 are a pseudo
random number. Considering about 300 major banks, we have about 300 x
10^12 possibilities. We can reduce, even more, the space of
possibilities because these 12 digits are not really random, they
follow a standard, and can be generated with a variety of algorithms.
So because the space of possibilities is too small, will it be easier
to break any encryption algorithm?
Also, if an attacker breaks into the system, he can generate all
possible credit cards for a big bank, encrypt them using our encryption
program, and then compare the result with the ones on the database.
Then if he has a match he will have a valid number with all the
cardholder information.
We could encrypt the rest of the cardholder information, but since this
is frequently used, we would like to avoid it.
Alternatives
=========
- Use 3DES to encrypt the credit card number.
- Use a one way hash to generate the unique number.
Questions
=======
- Given that the possible Credit Card numbers are only around 300 x
10^12, is it easier to break 3DES and find the key? If so, is it true
that adding some random data to the card number will avoid this
weakness?
- If an attacker knows the pair plain text, ciphered data, lets say a
100 pairs, would be easier for him to find the key? What about if he
has a million pairs?
- Using a one way hash could lead the attacker to find a valid credit
card number. Any idea how to avoid this, and generate a unique
identifier for the credit card number?
- Any other ideas on how to face the problem of keeping credit card
data secure?
Thanks in advance
G-
Sent via Deja.com
http://www.deja.com/
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Q: Result of an old thread?
Date: Fri, 15 Dec 2000 12:29:04 -0800
Simon Best wrote:
> Then, I get the multiplicative inverse of B, multiply that by SB, and
> I've got S, the secret message!
Is that the only defect you can think of?
DS
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: Encryptian of data over radio transmission
Date: Fri, 15 Dec 2000 20:30:22 GMT
On Fri, 15 Dec 2000 22:54:13 +1000, "Jordan McCallum"
<[EMAIL PROTECTED]> wrote:
>How can i encrypt voice data over FM. Schematics would be appreciated.
>Basically looking for a addon for a FM transciever i have. Also schematics
>for the decryptor
It is theoretically possible to turn an FM transciever into a Spread
Spectrum transmitter/reciever if the transciever uses a phase locked
loop to mod/demodulate the RF signal. The phased lock loop
demodulator recovers the audio from the FM signal by alternately
flipping the polarity of the RF. If you flipped using a quasi random
bit stream, as from a PRNG, and the flipping was done in
synchronization between transmitter and the receiver at the other end,
you have a reasonably secure channel, subject only to the quality of
your quasi random bit stream. I doubt if this is the newsgroup to ask
how to do that but check the schematic of any 900 mhz cordless phone
and you will see how its done. :-)
John
------------------------------
From: Simon Best <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Visual Basic Source Code
Date: Fri, 15 Dec 2000 20:35:45 +0000
Jason Bock wrote:
>
> Paul Schlyter <[EMAIL PROTECTED]> wrote in message
> news:91cp0a$78c$[EMAIL PROTECTED]...
> > In article <3a39a408$0$75795$[EMAIL PROTECTED]>,
> > Jason Bock <[EMAIL PROTECTED]> wrote:
> >
> > > People have done some amazing things in VB to break beyond its'
> > > boundaries (i.e. they don't fear "real programming").
> >
> > If they don't fear "real programming", why don't they switch to some
> > real programming language?
>
> First, define "real programming language." What are you criteria? What
> makes VB not a "real programming language"? BTW, technically VB isn't a
> language, it's a tool (I admit in this thread I've been calling it a
> language, but it's more of a language/tool combo).
>
> You type in some code, you compile it, it runs on a Windows-based
> workstation. I fail to see how that disqualifies it from being a "real
> programming language."
>
> Jason
Hang on, having just read the last few posts in this thread in quick
succession, I think there's been an error in this thread. The claim was
that VB programmers were 'lame', not necessarily the language.
I recognise this stereotype of VB programmers as generally not being
programmers. It's a stereotype even held by some managers who don't
have anything to do with programming! (I came across this from an
economist/accountant/management friend, who's description of VB
programmers was that they were 'just playing with Lego', mentioning that
they had to contract out to get any real software guts written.)
While the stereotype may well not be universally applicable to all who
use Visual Basic, it does seem that there are a surprisingly large
number of VB 'programmers' who do fit the stereotype. A more
appropriate description might be 'graphical user interface designers'
(as even the programming for that is done for them).
Simon
--
_______________________________________________________________________________
Personal: [EMAIL PROTECTED]
Yellow Skies: [EMAIL PROTECTED] http://www.yellowskies.com
Everyone does their own signature to be different. How does that work?
------------------------------
From: [EMAIL PROTECTED] (Walter Hofmann)
Subject: Re: Protocol for computer go
Date: Fri, 15 Dec 2000 21:37:58 +0100
On Fri, 15 Dec 2000 11:40:16 +0100, Francois Grieu <[EMAIL PROTECTED]> wrote:
>
>Now I get what David means: the counter should be in sync on the main
>program and on the replay program, without info from a transcript.
>In essence, he propose that the program together with its counter is
>deterministic and identical on both sides.
>
>How do we implement the counter ?
>No hardware counter works (deltas of QueryPerformanceCounter in Win32
>are not even reproducible on one given machine).
You could use the trace function of the processor. This will execute one
instruction at a time. Just have a debugger-line program trace the game
program and count the instructions.
>Now what about (d) ? Problem is, of course, that the behaviour of the
>main program depends on when the adversary has played (especialy when
>the program runs out of time).
The time the opponent plays is recorded and injected in the replay run
at exactly the right time, which is given by the instruction counter.
Walter
------------------------------
From: [EMAIL PROTECTED] (Walter Hofmann)
Subject: Re: Protocol for computer go
Date: Fri, 15 Dec 2000 22:01:07 +0100
On 15 Dec 2000 05:08:44 GMT, David Wagner <[EMAIL PROTECTED]> wrote:
>Let's see. How about the following alternative?
>
>The underlying `operating system' (which must be trusted) exports
>a query-clock-cycles operation which returns the number of clock cycles,
>plus or minus a random number. This random number can be generated
>in a secret yet verifiable way with techniques described in an earlier
>post of mine, so others can still verify that the transcript proceeded
>correctly -- yet the go-playing program cannot guess the exact number
>of clock cycles due to the randomization. Thus, the non-determinism
>inherent in the number of clock cycles it takes to execute the
>algorithm cannot be exploited to alter the behavior of the program.
>
>Can this sort of idea be made to work? I'm not too sure myself,
>and would welcome comments on it.
What about the following attack:
While the opponent calculates its move the program will display a number
of alternative moves in quick succession. The opponent decides on the
move and sends a network packet (via the referee) to the go program. The
human operator installed a variable network delay loop and tunes it so
that the opponent's packet arrives at exactly the time when the best
move is displayed. (The human operator has to anticipate the next move
of the opponent or think quickly.)
Possible workarounds:
- The OS prohibits every kind of output and stops the program at random
times.
- The OS adds an arbitrary delay to the packets before they are
forwarded to the program.
In any case one has to make sure that the OS is trusted.
Walter
------------------------------
From: Simon Best <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Q: Result of an old thread?
Date: Fri, 15 Dec 2000 21:12:49 +0000
David Schwartz wrote:
>
> Simon Best wrote:
>
> > Then, I get the multiplicative inverse of B, multiply that by SB, and
> > I've got S, the secret message!
>
> Is that the only defect you can think of?
>
> DS
Eh?
The question was whether or not the idea was secure. I outlined how it
was never secure if all three public transmissions were intercepted.
That was enough to answer the question. There may be various other ways
in which it is defective, but I just didn't bother to think about it any
further once I'd answered the original question.
After all, a trivially broken cryptosystem doesn't remain secure just
because there might be additional, but undiscovered, defects!
But, if you think other defects need to be pointed out, go ahead!
Simon
--
_______________________________________________________________________________
Personal: [EMAIL PROTECTED]
Yellow Skies: [EMAIL PROTECTED] http://www.yellowskies.com
Everyone does their own signature to be different. How does that work?
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Q: Result of an old thread?
Date: Fri, 15 Dec 2000 13:14:55 -0800
Simon Best wrote:
> Eh?
You are taking me *way* too seriously.
DS
------------------------------
From: Simon Best <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Q: Result of an old thread?
Date: Fri, 15 Dec 2000 21:30:59 +0000
David Schwartz wrote:
>
> Simon Best wrote:
>
> > Eh?
>
> You are taking me *way* too seriously.
>
> DS
Oh! Sorry, I misunderstood.
Simon
--
_______________________________________________________________________________
Personal: [EMAIL PROTECTED]
Yellow Skies: [EMAIL PROTECTED] http://www.yellowskies.com
Everyone does their own signature to be different. How does that work?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Result of an old thread?
Date: Fri, 15 Dec 2000 22:35:36 +0100
Simon Best wrote:
>
> Mok-Kong Shen wrote:
> >
> > Quite a time ago someone posted a scheme of transmission of
> > message without using a shared secret key as follows (all
> > matrices are of the same size):
> >
> > The message is in a singular matrix S (e.g. one with a zero
> > column). Alice chooses an arbitrary non-singluar matrix A
> > and sends AS to Bob.
>
> And, unbeknownst to Alice and Bob, AS is intercepted by me...
>
> > Bob chooses an arbitrary non-singular matrix B and sends ASB
> > to Alice.
>
> And, again, I intercept ASB...
>
> > Alice multiplies it with A^(-1) and sends SB to Bob, who can
> > multiply it with B^(-1) to obtain S.
>
> While I intercept SB, too...
>
> > If my memory is correct, nobody has commented at that time
> > whether the scheme is secure or not (or how secure it is).
> > Does anyone know more about the issue or can say something
> > concrete about the security of the scheme? Thanks.
>
> Correct me if I am making a basic blunder with basic matrix arithmetic
> here, but now that I have AS, ASB, and SB, can't I just get the
> multiplicative inverse of AS, multiply that by ASB, and end up with B?
> That get's me Bob's secret matrix. (I'm assuming that matrices are
> transposed as necessary for all of this stuff.)
>
> Then, I get the multiplicative inverse of B, multiply that by SB, and
> I've got S, the secret message!
>
> Then, I get the multiplicative inverse of S, multiply that by AS, and
> I've got A, too. So I end up with the secret message, and Alice's and
> Bob's secret matrices, too?
>
> Seems hopelessly insecure to me.
Have you noticed that S is singular?
BTW, let's assume that there is only passive attack.
M. K. Shen
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Protocol for computer go
Date: Fri, 15 Dec 2000 22:43:16 +0100
[EMAIL PROTECTED] (Walter Hofmann) wrote:
> You could use the trace function of the processor. This will execute one
> instruction at a time. Just have a debugger-line program trace the game
> program and count the instructions.
Requires identical instruction set on the play and replay machine. Does not
seem easy. Is not ANSI C.
About(d): letting a program work during its opponent's turn.
> The time the opponent plays is recorded and injected in the replay run
> at exactly the right time, which is given by the instruction counter.
I think I have found a similar solution: have the play program B, or a
referee, tell how much time (real, not estimated) program B has used, after
each move. Put that in the transcript. Give this info to play and replay
program A (do not give time used by play program A to replay program A).
Play and replay program A shall identically translate time used by B into
how much work the play program A could accomplish while B though its move;
play program A shall first finish this work, if not already done (program A
must either avoid doing work in advance of the estimation, or be able to
back up), so that replay program A can be kept in sync; replay program A
should do just this amount of work. Of course if the programmer does not
like this mess, it is possible to just do some small fixed amount of work
while B prepares its move.
In this way the only method I see for a human to sneak info would be to
influence the other program to make it take more or less time, but that is
an uncertain side channel. If a human operator is in the loop, a phone call
will do. If program is on the net, repeated ping might be sucessful.
Francois Grieu
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Q: Result of an old thread?
Date: Fri, 15 Dec 2000 14:51:32 -0700
Simon Best wrote:
<snip>
> Correct me if I am making a basic blunder with basic matrix arithmetic
> here, but now that I have AS, ASB, and SB, can't I just get the
> multiplicative inverse of AS
<snip>
S is singular, A and B are not, and so each of AS, ASB, and SB
are singular, and you can't invert any of them.
Nonetheless, at the time of the original thread, it was clear
that the scheme is not secure. I forget exactly why, maybe
you do an SVD (singular value decomposition) or something.
JM
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: On XTR
Date: Fri, 15 Dec 2000 13:46:46 -0800
I wonder if someone (or ones) with the relevant savvy
could make a few comments about XTR. Its author's
credentials are of course impeccable, and the performance
figures they mention impressive.
It's true that RSA is actually performed much faster
than they indicate, in general, and than XTR in particular
for equivalent security requirements; but we are talking
extremely fine-tuned RSA, with the computationally
intensive parts in hand-coded assembly language, versus
a demo C implementation of XTR - possibly quite good, but
no doubt not optimal and with no assembly language code.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Protocol for computer go
Date: Fri, 15 Dec 2000 13:52:13 -0800
Francois Grieu wrote:
> I think I have found a similar solution: have the play program B, or a
> referee, tell how much time (real, not estimated) program B has used, after
> each move. Put that in the transcript. Give this info to play and replay
> program A (do not give time used by play program A to replay program A).
> Play and replay program A shall identically translate time used by B into
> how much work the play program A could accomplish while B though its move;
> play program A shall first finish this work, if not already done (program A
> must either avoid doing work in advance of the estimation, or be able to
> back up), so that replay program A can be kept in sync; replay program A
> should do just this amount of work. Of course if the programmer does not
> like this mess, it is possible to just do some small fixed amount of work
> while B prepares its move.
I don't see how this could work. The only way to know how much actual
work the program got done while its opponent was thinking is to ask it.
For all the reasons previously discussed, there is no way to turn wall
clock time into exactly how much work a computer can get done. The basic
rules of the game allow each player to do as much thinking as the player
is physically capable of. And the only way to know how much thinking a
computer did in a fixed amount of wall time is to ask it, which creates
obvious side channels.
DS
------------------------------
From: Simon Best <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Q: Result of an old thread?
Date: Fri, 15 Dec 2000 22:09:44 +0000
Mok-Kong Shen wrote:
>
> Simon Best wrote:
[...]
> > Seems hopelessly insecure to me.
>
> Have you noticed that S is singular?
>
> BTW, let's assume that there is only passive attack.
>
> M. K. Shen
Okay, I was being too hasty (and forgot to remember that not all
matrices have multiplicative inverses, and didn't stop to think about
what a singular matrix is).
Yes, let's assume that only passive attacks are possible (which is what
I was sticking with anyway, but failed to make explicit).
Doesn't the whole thing still boil down to a few sets of simultaneous
equations? I'll look at it more thoroughly...
Simon
--
_______________________________________________________________________________
Personal: [EMAIL PROTECTED]
Yellow Skies: [EMAIL PROTECTED] http://www.yellowskies.com
Everyone does their own signature to be different. How does that work?
------------------------------
From: Simon Best <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Q: Result of an old thread?
Date: Fri, 15 Dec 2000 22:15:24 +0000
John Myre wrote:
>
> Simon Best wrote:
> <snip>
> > Correct me if I am making a basic blunder with basic matrix arithmetic
> > here, but now that I have AS, ASB, and SB, can't I just get the
> > multiplicative inverse of AS
> <snip>
>
> S is singular, A and B are not, and so each of AS, ASB, and SB
> are singular, and you can't invert any of them.
Oops! I _did_ make a basic blunder in my haste...
> Nonetheless, at the time of the original thread, it was clear
> that the scheme is not secure. I forget exactly why, maybe
> you do an SVD (singular value decomposition) or something.
>
> JM
I'll have a play around with it, and see if I can break it...
Simon
--
_______________________________________________________________________________
Personal: [EMAIL PROTECTED]
Yellow Skies: [EMAIL PROTECTED] http://www.yellowskies.com
Everyone does their own signature to be different. How does that work?
------------------------------
From: "Michael" <[EMAIL PROTECTED]>
Subject: Re: Custom Encryption Algorithm
Date: Fri, 15 Dec 2000 22:23:00 GMT
"Marc" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >You appear to have missed one of my main points. I designed the program
> >to protect my emails to my very close friends from ANYONE who would want
> >to read an email from me to them. I beleive I have accomplished that.
> >As I stated before, I beleive that more now than two weeks ago. And of
> >course, there isn't the $10,000 incentive to read my email.
>
> :-) Your email comm with your friends is very well protected from
> me even without any encryption, because I don't care about it..
Exactly.
> When selecting an algorithm and protocol, the cryptographer first
> makes a threat model. He judges the weaknesses of the problem and
> how much effort an attacker might come up with. The algorithm and
> protocol are then selected in a way, that the attacker has to put
> in considerably more effort than the secret is worth.
I agree.
> When protecting a $1 Million business secret, you use an algorithm
> that requries >$1 Million worth of computing power to crack.
>
> When protecting an incriminating confession that becomes unpunishable
> in 10 years, you use an algorithm that is likely to remain strong
> for 10 years (or select keysize acordingly for algorithms
> like RSA).
I agree.
> If in you own case the threat model sais "all possible attackers are
> casual net snoopers, noone will attack deliberately" and "this
> casual attacker will do not more effort than starting up an ASCII
> viewer", then even ROT-13 is an appropriate protection.
Actually, my model was "the attacker might go to a XXXX (you fill in the
blank, hacker, crypto, etc.) web site and purchase a program to do the work
for him if this program was under $100."
> I have also used weak algorithms successfully in the past, because
> the threat was even weaker than the algorithm.
It is fun to play with, even if it is weak. Think about all the people you
know (who are not crypto experts) and then think about how much effort it
would take the average one to crack even weak ciphertext.
Any thoughts on how to proceeded with my other 'problem?'
Michael
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Q: Result of an old thread?
Date: Fri, 15 Dec 2000 22:15:50 GMT
[EMAIL PROTECTED] wrote:
> Mok-Kong Shen wrote:
> > The message is in a singular matrix S (e.g. one with a zero
> > column). Alice chooses an arbitrary non-singluar matrix A
> > and sends AS to Bob.
>
> And, unbeknownst to Alice and Bob, AS is intercepted by me...
>
> > Bob chooses an arbitrary non-singular matrix B and sends ASB
> > to Alice.
>
> And, again, I intercept ASB...
>
> > Alice multiplies it with A^(-1) and sends SB to Bob, who can
> > multiply it with B^(-1) to obtain S.
>
> While I intercept SB, too...
> [...] I have AS, ASB, and SB, can't I just get the
> multiplicative inverse of AS, multiply that by ASB,
> and end up with B?
There's the problem that S is singular, so AS will
also be singular. While you can't get an inverse
and find a unique solution for B, you can set up the
linear equations to solve for B, and use _any_ of the
non-singular solutions.
> Seems hopelessly insecure to me.
Yup. Purely linear.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Jason Bock" <[EMAIL PROTECTED]>
Subject: Re: Visual Basic Source Code
Date: Fri, 15 Dec 2000 16:57:47 -0600
Simon Best <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I recognise this stereotype of VB programmers as generally not being
> programmers. It's a stereotype even held by some managers who don't
> have anything to do with programming! (I came across this from an
> economist/accountant/management friend, who's description of VB
> programmers was that they were 'just playing with Lego', mentioning that
> they had to contract out to get any real software guts written.)
>
> While the stereotype may well not be universally applicable to all who
> use Visual Basic, it does seem that there are a surprisingly large
> number of VB 'programmers' who do fit the stereotype. A more
> appropriate description might be 'graphical user interface designers'
> (as even the programming for that is done for them).
On this I will agree, and that's where I think the stereotype comes from.
It's not the language or the tool - it's the ones who have latched on.
Unfortunately, VB makes it so easy to create programs any yahoo can come
along and call themselves a "developer" (or a consultant, heaven forbid
;) ). I've been involved in 3 different projects where I had to take
someone's VB code base and either maintain it or substantially enhance it.
None of them were fun.
That said, in the hands of someone who knows what they're doing, it's not
all that bad ;).
Regards,
Jason
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
