Cryptography-Digest Digest #872, Volume #11 Sat, 27 May 00 16:13:01 EDT
Contents:
Re: looking for an 8-byte long output hashing function (Bill Unruh)
Re: Another possible 3DES mode. (John Savard)
Re: Short Secure Serial Numbers (Scott Nelson)
Re: Another sci.crypt Cipher ([EMAIL PROTECTED])
Re: Patent state of Elliptic Curve PK systems? (David Hopwood)
Re: Short signatures (David Hopwood)
Re: OAP-L3: Version 5.x Revealed (Anthony Stephen Szopa)
Re: RSA/PK Question (Roger Schlafly)
Re: Best crypto if encrypted AND plain text are known (and small) ? ("Thomas M.
Sommers")
Re: Another sci.crypt Cipher (tomstd)
Re: list of prime numbers (Johnny Bravo)
Re: Enigma reflectors ("Thomas M. Sommers")
Re: Another sci.crypt Cipher ([EMAIL PROTECTED])
Re: list of prime numbers ([EMAIL PROTECTED])
Re: Best crypto if encrypted AND plain text are known (and small) ? (TheGame)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: looking for an 8-byte long output hashing function
Date: 27 May 2000 18:12:21 GMT
In <T1IX4.103419$[EMAIL PROTECTED]> "Jean-Luc"
<[EMAIL PROTECTED]> writes:
]For a development task, I would need to use a hashing function with an
]output of 8 bytes (and not 16 or 20 like the popular algorithms). The
]increased collision is acceptable within the context of the application
](because of the lockout of the hardware token after several failed logins).
]However, I haven't been able to find such a function. Is there one? I've
]already searched the web and the Usenet but haven't found anything relevant.
The first 8 bytes of the output of a 16 or 20 byte hash is an 8 byte
hash.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Another possible 3DES mode.
Date: Sat, 27 May 2000 18:16:04 GMT
On 24 May 2000 08:15:04 -0700, [EMAIL PROTECTED]
(David A. Wagner) wrote, in part:
>In article <8gfo3a$l88$[EMAIL PROTECTED]>, zapzing <[EMAIL PROTECTED]> wrote:
>> In the faq, the following idea was
>> suggested as a way of accomplishing
>> 3DES on an enlarged block:
>> F(x)=Tran(E(k1,Tran(E(k2,Tran(E(k3,Tran(x)))))))
>I believe there are weaknesses in this -- Paul Crowley found
>an especially pretty attack -- and I do not recommend its use.
>See http://www.hedonism.demon.co.uk/paul/crypto/dtdtd.html.
I liked it so much, I added a description of the attack to my site, in
the section on block cipher modes at
http://ecn.ab.ca/~jsavard/co0409.htm
I am planning to add to my site, soon, a description of genetic
algorithms and hill-climbing techniques.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Short Secure Serial Numbers
Reply-To: [EMAIL PROTECTED]
Date: Sat, 27 May 2000 18:52:29 GMT
On 25 May 2000 "Rick Heylen" <[EMAIL PROTECTED]> wrote:
>I am trying to find a solution to the following problem.
>We have a serial number which the user types in (so it can't be too long).
>The serial number contains some information like a product ID, user number
>etc with a total information content of about 96 bits and 40 bits of
>"checksum" with the idea being that for all possible information contents,
>there is only one valid checksum and that in order to find a valid serial
>number, an attacker would have to test on average 2^39 possibilities.
>The code that verifies the serial number is public but we'd still like it
>to be time-consuming to generate different valid serial numbers.
>Normal public key cryptography would be suitable except that the message
>size for the system to be secure would be longer than what a user would be
>happy to type in.
>Has anybody got any ideas?
>
If you only want 40 bit security, then you could just hash all the
information provided with SHA1 or MD5, and look at the bottom 40 bits.
If they're all 0, (or any other value you like) then accept
the serial number as valid.
To produce the serial number, just try pseudo random values until
you get one that works.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Another sci.crypt Cipher
Date: Sat, 27 May 2000 18:54:48 GMT
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> In article <8goumb$6qa$[EMAIL PROTECTED]>, matthew_fisher@my-
> deja.com wrote:
> >Tom,
> >
...
>
> What enhancements ? I just cleaned up the code.
>
The the kbhit and the counter print out.
> BTW how did you find those differentials anyways? That is why I
> made this cipher. I want to learn how to spot them in less-then-
> obvious cases.
>
> Tom
Just by looking at the sboxes, mostly. The low bytes in the 0 box are
in a small set (0,4,8,C). So I got the idea to go from the set back to
the same set.
I wrote a short program along these lines
for(i=0;i<256;i++)
for(j=i+1;j<256;j++)
{
// look for S[i]^S[j] = 0x000000xx
if(((sbox[0][i]^sbox[0][j])&0xFFFFFF00) ==0)
{
diffArray[i^j][sbox[0][i]^sbox[0][j]]++
}
}
print diffArray[0xC][0xC]; // 2 hits
print diffArray[0x8][0x8]; // 0 hits
print diffArray[0x4][0x4]; // 0 hits
Nice attack on SC6, BTW. You should get credit on the cipher contest
web site.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sat, 27 May 2000 06:37:33 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Patent state of Elliptic Curve PK systems?
=====BEGIN PGP SIGNED MESSAGE=====
Paul Rubin wrote:
>
> In article <[EMAIL PROTECTED]>, Roger Schlafly <[EMAIL PROTECTED]>
> wrote:
> >Certicom says it has some patent applications pending, but
> >it is hard to see how they will stop anyone. Most people
> >get better performance in software with other bases, ie,
> >trinomial bases. Or one can use (non-optimal) normal bases.
> >Or use prime fields where you have more curves and fewer
> >known attacks.
>
> What about the technique of representing the point (x,y) as (x,sgn(y))
> in a message, since the rest of y can be computed from x? That's been
> given the fancy name "point compression" and I have dim memory of hearing
> it was patented.
It is not patented. A different point compression technique developed at
Hewlett-Packard, which shaves off one extra bit, has a patent pending. See
Gadiel Seroussi,
Compact Representations of Elliptic Curve Points over GF(2^n),
http://grouper.ieee.org/groups/1363/Research/Supporting.html#hp
(and http://grouper.ieee.org/groups/1363/P1363/patents.html, which
references a letter about the patent status from HP).
IMHO this technique is not particularly useful in practice (and is not
included in P1363 or any of the ANSI standards), although the paper is
worth reading if you're interested in the maths.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOS9e3TkCAxeYt5gVAQGZ2ggAzqHb6nuoG5QsD+aObXhSDKOC1LHfBNlR
k17RGkXnFAaDe/2EgL2mnffL9dyygYl9vIJ/GqcTeua6upCVoCUiV8rjtMmXKCEs
n/uOZPs0SYlKgAQcMntoo3YxOlI2ijrUC8GoCnwYHjrr40Uh7V6cIXaTvkkIApJ9
pV73QGx2ClvUYokK2hmFBgEKSYdjvvnyepGg0hNqG/bYoGammM0hdjPYEG5+SKWd
N8QaVf8aw1ccpx6hrjgGXmVFrDXqWlRHwI8iqMSwxUP9Jzgz9KYtJDR+Z0xdDWmP
4b5Nr4w08xP7jyROaoqbs6W8I+maGWGF9zMoEmvqcfXQ7R5Y1Ws2uA==
=18FL
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 27 May 2000 06:49:50 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Short signatures
=====BEGIN PGP SIGNED MESSAGE=====
I wrote:
[...]
> [1] Kaisa Nyberg, Rainer Rueppel,
> "Message Recovery for Signature Schemes Based on the Discrete
> Logarithm Problem,"
> Advances in Cryptology - EuroCrypt '94.
That should have been labelled as [NR94]. Note that the scheme normally
called "Nyberg-Rueppel" was in an earlier paper, not this one.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOS9h5TkCAxeYt5gVAQFukwf8CyrAfIcmNkYqJhfiSAZty+ifkTDqruE/
eBSBGBaJQ0hUZNfHgbFx8UJL3ww3ChExoiuYEdJts12K1PTvVSUj8xFwLLS4zDY9
5fel4VWROhdRnRBmF0ctNoqS1qpSSqoKknMnAMT2r52nMmQMGjYozjRTYwT+z3v5
XKMVPk5OahXFHFTyz7VRcDHR6OpT88ywmE2fQ3c4O3anQyAgAGOKuOP4RZwtsy95
8ZZWwK/TCIkaVGFgE5XiE/+vk5bTo0+8BHIIGTF2V4YS9MDe9XDTLpZ71/ARdtCm
uekHEDU3M+BHSZKJvLS0nE4lX2KgomgbPClZk0U41SpoR4jfaTR9ag==
=04KB
=====END PGP SIGNATURE=====
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Version 5.x Revealed
Date: Sat, 27 May 2000 12:12:30 -0700
Alan Mackenzie wrote:
>
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote
> on Fri, 26 May 2000 00:40:17 -0700:
>
> > OAP-L3: Version 5.x Revealed
>
> > (Both OAP-L3 Version 4.x and OAP-L3 Version 5.x are patent pending
> > under two separate patent applications.)
>
> [ .... ]
>
> > I am not going to discuss the implications of this new OAP-L3 Version
> > 5.x here in this news group at this time.
>
> Oh, what a shame :-)
>
> [ .... ]
>
> > With OAP-L3 Version 5.x, only one person need the full implementation
> > with an executable file near 2MB. This person would be responsible for
> > creating the data files (the table data files) used in the encryption /
> > decryption process.
>
> > The other person only needs to be supplied with software that
> > only encrypts and decrypts messages using such a table. I guess
> > that this executable file need only be about 50KB or maybe less (for
> > a windows executable.)
>
> Why the guess? Surely by now you'll have created this executable and know
> exactly how big it is.
>
> [ .... ]
>
> > The software and the data file (a data table) could be kept on a floppy
> > disk.
>
> Do you envisage a secure method of distributing the key floppies, other
> than by personal contact or by courier service? If not, what are the
> advantages of using OAP rather than a one-time pad?
>
> > And when the software is run, it could be read directly from this
> > floppy disk and loaded directly into RAM along with the data table.
>
> An _unencrypted_ key on a floppy disk, together with the program that
> uses it? Isn't that a _slight_ security hole? Why not encrypt the key
> with, say, IDEA, using a pass phrase, much like PGP does?
>
> > Additionally, there would be a few associated pointer / counter files
> > that would at most take up another 1000 bytes.
>
> > That's it: software of about 50KB capable of generating about 3E12
> > random digits with data files of about 8KB all of which will run
> > entirely in RAM (being loaded directly from floppy diskette). Then
> > when the encryption or decryption is completed, the only new data
> > written to the diskette would be the updated pointer / counter
> > files.
>
> > I could incorporate a short routine in the encrypt / decrypt software
> > to overwrite RAM to provide about as good of computer hardware
> > security imaginable or possible.
>
> Credit card terminals tend to store keys in smart card chips, or split
> them between those chips and battery backed ram inside a secure case
> designed to erase those keys if the case is tampered with.
>
> > Nothing from the diskette goes to your hard drive ....
>
> assuming you've somehow disabled swapping for the critical RAM regions.
>
> > .... and the RAM is overwritten. Very clean.
>
> > Get an 800MHz or faster Pentium III or AMD Athlon CPU with full speed
> > on board cache and I think encryption / decryption could be done quite
> > quickly and efficiently.
>
> Just about anything short of long range weather forecasting or running a
> Microsoft program could be done "quickly and efficiently" on such a
> machine. Most people who'll be wanting to encrypt will have lesser
> machines, like 166MHz Pentiums, or 33MHz 486s :-(.
>
> Why the "I think"? What sort of machines have you used for testing, and
> how fast did the encryption run on those machines, and how does the speed
> compare with other popular encryption programs?
>
> All the best with the patents and the program!
>
> --
> Alan Mackenzie (Munich, Germany)
> Email: [EMAIL PROTECTED]; to decode, wherever there is a repeated letter
> (like "aa"), remove one of them (leaving, say, "a").
Hope you found the information at the web site of some interest.
AS
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: RSA/PK Question
Date: Sat, 27 May 2000 19:13:34 GMT
In article <[EMAIL PROTECTED]>,
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> You are mixing energy and time. There's plenty of energy to run the
counter,
> but there's not enough time to run it at less than fantastic speeds.
The
> shortest interval I'm aware of is the time it takes light to cross
the distance
> enclosing a sub-atomic particle. If there's a computation speed
floor it's
> something like that. There can't be a computation energy floor
because of
> reversibility.
Making reversible computation practical is still an open research
problem, AFAIK. With current computer architectures, there is
both a time problem and an energy problem. The energy problem
is related to thermodynamics, and gives a lower bound on the
energy needed to change a bit. For more info, see:
http://www.zyvex.com/nanotech/reversible.html
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Thomas M. Sommers" <[EMAIL PROTECTED]>
Subject: Re: Best crypto if encrypted AND plain text are known (and small) ?
Date: Sat, 27 May 2000 19:25:19 GMT
TheGame wrote:
>
> Hi,
>
> Sorry for this basic question, but I'm wondering what the best algorithm
> would be to encrypt and decrypt a user name (e.g. 'fred'). The goal would
> be to give 'fred' his encrypted username as a cookie, and to be able to
> get back the original username 'fred' when decrypting the cookie.
>
> Obviously, it should not be possible for anyone else to claim to be 'fred',
> even by having thousands of plaintext and encrypted usernames to
> try and figure out the key...
A Bad Guy wouldn't need to figure out your system to impersonate fred.
All he would have to do is steal fred's cookie file, or snoop the
encrypted user name from the network.
------------------------------
Subject: Re: Another sci.crypt Cipher
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 27 May 2000 12:29:25 -0700
In article <8gp5lk$bc6$[EMAIL PROTECTED]>, matthew_fisher@my-
deja.com wrote:
>> What enhancements ? I just cleaned up the code.
>>
>
>The the kbhit and the counter print out.
Oh. well I always like to see the output...
>
>> BTW how did you find those differentials anyways? That is
why I
>> made this cipher. I want to learn how to spot them in less-
then-
>> obvious cases.
>>
>> Tom
>
>Just by looking at the sboxes, mostly. The low bytes in the 0
box are
>in a small set (0,4,8,C). So I got the idea to go from the set
back to
>the same set.
Well they are like that because of the bit permutation, not
specifically because of the 8x8 sboxes...
>I wrote a short program along these lines
>
>for(i=0;i<256;i++)
>for(j=i+1;j<256;j++)
>{
> // look for S[i]^S[j] = 0x000000xx
> if(((sbox[0][i]^sbox[0][j])&0xFFFFFF00) ==0)
> {
> diffArray[i^j][sbox[0][i]^sbox[0][j]]++
> }
>}
>print diffArray[0xC][0xC]; // 2 hits
>print diffArray[0x8][0x8]; // 0 hits
>print diffArray[0x4][0x4]; // 0 hits
Oh cool. Will have to try this idea myself sometime.
>Nice attack on SC6, BTW. You should get credit on the cipher
contest
>web site.
Thanks.
Well I must admit my difference was not complete (mainly because
I did that at 6 in the morning). It was the first 'non-tom'
cipher I broke (or attacked). I think I hurt his F function
too :)
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: list of prime numbers
Date: Sat, 27 May 2000 15:30:56 -0400
On Sat, 27 May 2000 06:32:37 GMT, [EMAIL PROTECTED] (Daniel)
wrote:
>On Thu, 25 May 2000 21:50:00 GMT, [EMAIL PROTECTED] (Dan Day) wrote:
>
>
>>Daniel, what were you hoping to do with the list? If you'll
>>explain your application, we can help you address your problem
>>more directly, since keeping a "list" of primes is likely to
>>be a poor way to get the job done, whatever it is.
>>
>>
>Thanks for all the replies.
>
>I'm trying to understand RSA and want to be able to factor a given
>'public modulus'. Or try it at least ;-)
Start small and work your way up. Eventually you will realize why
150 digits are such a problem.
>If one has a large number (say 150 digits), what are the ways to try
>and break this up into its factors? Where does one start? I think
>that there can only be a limited list of possible prime numbers which
>will actually (when multiplied) come up with the correct public
>modulus.
The list is indeed limited, but so is the number of atoms in the
Universe. The problem is that your "limited list" is more than that
number of atoms. You have three problems, 1: Generating the list, 2:
Storing the list, 3: Actually using the list to factor a number.
> Or am I wrong about this? All information is greatly
>appreciated.
Start with learning about prime numbers.
http://www.utm.edu/research/primes/
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: "Thomas M. Sommers" <[EMAIL PROTECTED]>
Subject: Re: Enigma reflectors
Date: Sat, 27 May 2000 19:36:33 GMT
John Savard wrote:
>
> On Sat, 27 May 2000 04:44:15 GMT, "Thomas M. Sommers"
> <[EMAIL PROTECTED]> wrote, in part:
>
> >When a new reflector became available, did it completely supercede the
> >earlier one, or did the reflector become another part of the key?
>
> From what I've read, it appears that it did supercede, even though the
> opposite happened with the regular rotors. However, that was true only
> the first time the reflecting rotor was replaced, before the war.
> After that, the reflecting rotor was not changed, for the Army and
> Navy at least, except by replacing it by either a rewirable reflecting
> rotor, or by replacing it with a set of two rotors. These two thin
> rotors could be set to simulate the old reflecting rotor, or to other
> settings.
Thanks for the info. My understanding is that the C reflector went into
service in 1941. Do you mean that it was not used? Or is that the change
you refer to? I assume that the rewirable reflectors were rewired
periodically. Do you know is that is correct?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Another sci.crypt Cipher
Date: Sat, 27 May 2000 19:28:44 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mark Wooding) wrote:
...
> I have a 16-round differential characteristic for your complete
cipher,
> with probability approximately 2^{62.5}.
>
> The characteristic evolves like this:
>
> 0: 00000000 00010000
> 1: 00010000 00000000 (01[1] -> 03[2], p = 4)
> 2: 00000300 00010000 (03[2] -> 01[1], p = 6)
> 3: 00000000 00000300
> 4: 00000300 00000000 (03[2] -> 01[1], p = 6)
> 5: 00010000 00000300 (01[1] -> 03[2], p = 4)
> 6: 00000000 00010000
> 7: 00010000 00000000 (01[1] -> 03[2], p = 4)
> 8: 00000300 00010000 (03[2] -> 01[1], p = 6)
> 9: 00000000 00000300
> 10: 00000300 00000000 (03[2] -> 01[1], p = 6)
> 11: 00010000 00000300 (01[1] -> 03[2], p = 4)
> 12: 00000000 00010000
> 13: 00010000 00000000 (01[1] -> 03[2], p = 4)
> 14: 00000300 00010000 (03[2] -> 01[1], p = 6)
> 15: 00000000 00000300
> 16: 00000300 00000000 (03[2] -> 01[1], p = 6)
> 17: 00010000 00000300
>
> The hex numbers on the left are the input differences to each round.
> The thing on the right is the differential through the S-box and
> permutation which it exploits, given as input and output
differentials,
> with the S-box to which each pertains. The probabilities given are
> fractions of 256.
>
> As you can see, it's basically a three-round iterative characteristic,
> which moves a difference between S-boxes 1 and 2.
>
Mr. Wooding,
I cannot verify this attack. Perhaps, I am confused on your notation.
> 1: 00010000 00000000 (01[1] -> 03[2], p = 4)
> 2: 00000300 00010000 (03[2] -> 01[1], p = 6)
The code numbers the sboxes
3 2 1 0
00 01 00 00
so
00 01 00 00 -> 00 00 03 00 is sbox 2 to sbox 1 or 01[2] -> 03[1]
I don't see any such differential.
If I am confused on the notation and you are numbering the boxes
0 1 2 3
00 01 00 00
then
00 01 00 00 -> 00 00 03 00 is sbox 1 to sbox 2.
I don't see that differential either.
What I do see is
00 03 00 00 -> 00 01 00 00 sbox 2 to sbox 2
and
00 00 01 00 -> 00 00 03 00 sbox 1 to sbox 1
There is no way to link these two however.
Can you clear up my confusion?
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: list of prime numbers
Date: 27 May 2000 19:43:09 GMT
Daniel <[EMAIL PROTECTED]> wrote:
> If one has a large number (say 150 digits), what are the ways to try
> and break this up into its factors? Where does one start? I think
> that there can only be a limited list of possible prime numbers which
> will actually (when multiplied) come up with the correct public
> modulus. Or am I wrong about this? All information is greatly
> appreciated.
Actually, for any RSA modulus n, there is a *VERY* limited list... in
fact, there are precisely 2 "prime numbers which will actually (when
multiplied) come up with the correct public modulus". But good luck
finding those 2 numbers.
You need to get a grasp of how many possible 150 digit numbers there
are to see how preposterous this is. You'd need an absolutely huge
hard drive (think terabytes) in order to store all the 13 digit prime
numbers -- now how big do you think a list of 150 digit primes is
going to be?
--
Steve Tate --- srt[At]cs.unt.edu | Gratuitously stolen quote:
Dept. of Computer Sciences | "The box said 'Requires Windows 95, NT,
University of North Texas | or better,' so I installed Linux."
Denton, TX 76201 |
------------------------------
From: [EMAIL PROTECTED] (TheGame)
Subject: Re: Best crypto if encrypted AND plain text are known (and small) ?
Date: Sat, 27 May 2000 19:49:52 GMT
In article <[EMAIL PROTECTED]>, "Thomas M. Sommers" <[EMAIL PROTECTED]>
wrote:
>TheGame wrote:
>>
>> Hi,
>>
>> Sorry for this basic question, but I'm wondering what the best algorithm
>> would be to encrypt and decrypt a user name (e.g. 'fred'). The goal would
>> be to give 'fred' his encrypted username as a cookie, and to be able to
>> get back the original username 'fred' when decrypting the cookie.
>>
>> Obviously, it should not be possible for anyone else to claim to be 'fred',
>> even by having thousands of plaintext and encrypted usernames to
>> try and figure out the key...
>
>A Bad Guy wouldn't need to figure out your system to impersonate fred.
>All he would have to do is steal fred's cookie file, or snoop the
>encrypted user name from the network.
Indeed, I know this scheme is less than fool-proof - it's not meant to be :)
But at least I'd like the basic encryption to be somewhat stronger than
what any script kiddie could crack in an hour...
In addition, I'd like to use some reversible encryption here, so all
one-way hashes are out, and I'm a bit lost in the relative strengths
of different algorithms for (very) small plaintexts like usernames
(or credit card numbers, for that matter).
TheGame
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
