Cryptography-Digest Digest #536, Volume #13 Wed, 24 Jan 01 00:13:00 EST
Contents:
Problem solved & thanks... (psyclops)
Re: Dynamic Transposition Revisited (long) (AllanW)
Re: America can teach England something about GUNS ("Harry Krishnah")
Re: Secure game highscore server (graywane)
Re: Dynamic Transposition Revisited (long) ("Matt Timmermans")
Re: Secure game highscore server (Tom St Denis)
Re: 32768-bit cryptography (Tom St Denis)
Re: Secure game highscore server (Paul Rubin)
Re: Why Microsoft's Product Activation Stinks (zapzing)
Re: Question about security of Oracle get_hash_value (Paul Rubin)
caching passwords in windows registry ("Ben Newman")
Re: 32768-bit cryptography ("Scott Fluhrer")
----------------------------------------------------------------------------
From: psyclops <[EMAIL PROTECTED]>
Subject: Problem solved & thanks...
Date: Wed, 24 Jan 2001 03:02:19 GMT
Thanks for your comments on this subject - I now see that the oracle
hashing function is not the best bet at all!
I am still set on using MD5 though - but not in SQL as I had first
intended. I discovered that you can actually use Java programs as
stored procedures, so I wrote an MD5 Java program, figured out how to
load it into the database (thanks to http://www.auerbach-
publications.com/scripts/fast_track.html and the Oracle docs) using a
function wrapper. The compiled java md5 sproc is ~ 150 times faster
than the original PL/SQL one, I clocked it as crunching 10000 hashes in
61 seconds, as compared to 100 hashes in 94 seconds for raw sql....
Woohoo!
cheers,
nick.
____________________________________________________________
Nick Donaldson mailto:[EMAIL PROTECTED]
Bit Wrangler Extraordinaire! http://www.psyclops.com/
CLIQ Services Cooperative http://www.cliq.com/
510.531.8722 voice 510.593.5638 mobile
Sent via Deja.com
http://www.deja.com/
------------------------------
From: AllanW <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Wed, 24 Jan 2001 03:00:42 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote:
> Dynamic Transposition is unusual in that knowing the plaintext and the
> associated ciphertext does not reveal the enciphering permutation.
> The reason for this is that many different bit-permutations will
> produce the bit-for-bit exact same transformation between plaintext
> and ciphertext. Therefore, having known plaintext does not reveal the
> enciphering permutation, and thus cannot be exploited to begin to
> expose the RNG sequence.
>
> Note that even if the correct permutation were found, the RNG sequence
> which created it would not be exposed to any extent, if
> double-shuffling was used to create the permutation. The reason for
> this is that double-shuffling would use twice the amount of RNG
> sequence as needed for a selection among all possible permutations.
> Double-shuffling is literally an arbitrary permutation from a known
> state, and then another arbitrary permutation from that to any
> possible permutation. Any particular result permutation could be the
> result of any possible first permutation, with the appropriate second
> permutation, or vise versa. Accordingly, one knows no more about what
> sequence was involved than before one knew the correct permutation.
Consider this alternative to double-shuffling (or they could be
used together): Process the entire plaintext once using an
N-byte block. But instead of considering the output to be
ciphertext, pack it into blocks of M-bytes, where M is less than
N/3, and mutually prime to N. For instance, N=2187, M=512. Once
again, use filler bits so that the number of 0-bits and 1-bits
are balanced, and then shuffle that buffer. I haven't thought
this through all the way yet; you might have to use two PRNG's in
order to be able to decrypt the numbers later, but if we can find
a way to know which PRNG values are used for which decoder (i.e
first N for the first buffer, then 3M for the second buffer, and
then N more for the big one and so on), then a single PRNG might
still suffice. The smaller buffer will need slightly more values
than the big one, due to adding a very few bytes to each buffer
to balance 0-bits with 1-bits.
The point of using double-shuffling is to make known-plaintext
attacks more difficult by further masking the actions of the
PRNG. But you also acknowledged that the result of two rounds
of shuffling is equivalent to one round controlled by some
other unknown sequence of random numbers. On the other hand,
using two buffers of different sizes makes the two passes have
different meaning. Also, in order to know that you're using
PRNG values that will succeed, you will have to decode at least
4 of the smaller blocks in order to have enough data to feed
into the larger block. Using two different PRNG's might make
analysis even more difficult.
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Harry Krishnah" <[EMAIL PROTECTED]>
Crossposted-To:
soc.culture.jewish,uk.politics.misc,talk.politics.guns,misc.survivalism,nyc.food,uk.education.behavioural,ok.general,chi.general,tx.guns,uk.politics.censorship
Subject: Re: America can teach England something about GUNS
Date: Wed, 24 Jan 2001 03:13:44 GMT
I hardly think simply mentioning the nice fish in the restaurants qualfies
this post to be included in nyc.food. Its off topic and has nothing to do
with this group.
"Fred Johnson" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> I recently visited England. I had mixed impressions, on the one hand
> they have nice fish in restaurants, but on the other hand THE ENTIRE
> COUNTRY has NO FREEDOM!!! Would you believe it, you are not allowed to
> own even such a meager weapon as a pump action shotgun! Apparently, these
> Britons believe that it is too dangerous for the government to allow its
> subject to own weapons. This is because they are still ruled by kings
> and queens. So, these British socialists, have basically no idea about
> the concept of civil liberties and armed populace. As a result, as NRA
> points out, is that their crime rates are going up as the population is
> being disarmed! Only the richest people can own very primitive weapons. I
> think that the poor are some sort of outcasts in England, if you cannot
> afford an outrageously expensive gunsafe, you cannot own a gun.
>
> This made me think, how great it is that 200+ years ago American patriots
> kicked the British troops out of the country. Or our life would be like
> in England, with all its rising crime rates, no freedoms, socialism,
> nationalized healthcare etc. I rented the movie "Patriot" again and
> felt so relieved and victorious. Thank you, our courageous forefathers!
>
------------------------------
From: [EMAIL PROTECTED] (graywane)
Subject: Re: Secure game highscore server
Date: Wed, 24 Jan 2001 03:14:15 GMT
In article <1yrb6.2635$[EMAIL PROTECTED]>, Robert Larsen wrote:
> I am developing game applets that sends highscore data back to the server.
> How can I do that in a secure way ? It should not be possible to grap the
> highscore data and send it again. Also it should not be a problem if someone
> decompiled the applet.
> Is this possible ?
It depends on what you mean by "this".
If you take the view that the client side program is a black box that no one
can modify then yes, you can send data over the network in a secure fashion.
However, the client side program won't be a black box. Anyone with a
knowledge of assembly language and a good debugger will be able to figure
out the algorithm used. They can then write a program that takes any score
they want, uses your algorithm, and sends it to the server.
Regardless of what you do in the client program, it will eventually execute
on the users machine. The user can then examine or modify the contents of
every memory location. Try as hard as you can - you won't stop the sneaky
hacker if he really wants to trash your high score list.
The only way to maintain the integrity of your high score data is to have
the users connect to a server where the game is actually played. Of course,
then you get into the issue of whether or not your server is secure.
If you look at every popular network game that maintains such a high score
list, part or all of the game is always played on the company server. For
the reasons listed above, trusting the client program is the same as
trusting the user -- and you can't trust those users :)
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Wed, 24 Jan 2001 03:31:28 GMT
"Terry Ritter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Assume the supposedly "random" pad you have is in fact predictable.
> Surely you will not argue that a "OTP" with a completely predictable
> sequence is secure. But wait! Isn't the OTP *proven* secure?
The pad is defined to be random. If it's not random, then your're not using
OTP. Whatever cipher you _are_ using may very well be insecure.
> For proven OTP security it is not sufficient simply to use the
> sequence only once. It is *also* necessary for the sequence to be
> "random," or more explicitly, "unpredictable."
Yes. That's how OTP is defined.
> The problem with this requirement is that we cannot measure an
> arbitrary sequence and thus know how unpredictable it is.
You also cannot measure a Rijndael key to find out whether or not it is
known to other parties -- you don't use arbitrary sequences as keys.
> Nor can we
> assemble all sorts of measurements of radioactive events or other
> random sources with the guaranteed assurance of unpredictability that
> proof requires. That does not mean that most sequences we develop
> will not be very strong, what it means is that we cannot prove it.
Sure you can. You can collect a large amount of biased random data by
sampling natural phenomena, use IDA to divide it into many small chunks,
take one, and throw the rest away. Repeat until you have enough. The only
difficult part is making sure you underestimate the entropy of your
source -- and even that's not too hard. With certain types of natural
phenomena, you can even base a proof of unpredictability on the uncertainty
principle.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Secure game highscore server
Date: Wed, 24 Jan 2001 03:29:24 GMT
In article <1yrb6.2635$[EMAIL PROTECTED]>,
"Robert Larsen" <[EMAIL PROTECTED]> wrote:
> Hello
>
> I am developing game applets that sends highscore data back to the server.
> How can I do that in a secure way ? It should not be possible to grap the
> highscore data and send it again. Also it should not be a problem if someone
> decompiled the applet.
> Is this possible ?
What you are asking is impossible in many respects. There is nothing to stop
someone from sending invalid scores.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: 32768-bit cryptography
Date: Wed, 24 Jan 2001 03:30:25 GMT
In article <94j81o$umv$[EMAIL PROTECTED]>,
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
> news:94hlqv$n8q$[EMAIL PROTECTED]...
> > In article <94hh9v$gpg$[EMAIL PROTECTED]>,
> > "Scott Fluhrer" <[EMAIL PROTECTED]> wrote:
> > >
> > > I thought I outlined how to break it with considerably less known
> plaintext
> > > than that. In addition, I've been looking further at that (and, yes, I
> > > don't have a life -- why do you ask?). It appears (at first glance)
> that it
> > > shouldn't be that difficult to rederive the plaintext/key from 16-20k
> with a
> > > ciphertext-only attack, if the plaintext was known to be (say) ASCII
> > > English. If anyone wants to be bored with the details, ask.
> >
> > Well you could mount a linear attack with a prob of 1/8th very easily.
> Just
> > guess the rotation amount then you are set.
>
> Well, yes, but using linear cryptanalysis against this cipher feels like
> using a bazooka to take out a mouse. It'll work, but it lacks a bit of
> elegance...
Well I am still an amateur :-) I use the more direct methods of linear/diff
if I can :-)
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Secure game highscore server
Date: 23 Jan 2001 19:59:52 -0800
"Robert Larsen" <[EMAIL PROTECTED]> writes:
> I am developing game applets that sends highscore data back to the server.
> How can I do that in a secure way ? It should not be possible to grap the
> highscore data and send it again. Also it should not be a problem if someone
> decompiled the applet.
> Is this possible ?
The only thing that can come close is secure hardware (such as a smart
card) that you supply to the players, and even that will only slow them
down. Game hackers are incredibly determined and resourceful. All you
can do in practice if you don't want to cause a lot of user acceptance
problems (from installing drivers etc.) is react with code changes
to rampant cheating, and expect and tolerate a certain amount of low
level cheating.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Wed, 24 Jan 2001 04:03:34 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> In article <94i1dd$2nd$[EMAIL PROTECTED]>, zapzing
<[EMAIL PROTECTED]> wrote:
>
> > Void where prohibited by law.
> >
> Couldn't that get you in trouble?
I don't think so, what do you think?
Do you have any info on this?
--
Void where prohibited by law.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Question about security of Oracle get_hash_value
Date: 23 Jan 2001 20:13:53 -0800
psyclops <[EMAIL PROTECTED]> writes:
> I am designing a user authentication system that will run as PL/SQL
> functions within Oracle 8i. I want to store the usernames hashed in
> the db so that the user list cannot be stolen by hackers.
> ...
> So here is my question: if I were to split a 20 digit username into
> four separate 5-digit values, hash each substring, then multiply the
> four values together to get a ~124 bit result, will this provide a
> higher level of security / collision-resistance than simply hashing the
> full 20-digit username?
Um, no, but why are the usernames 20-digit numbers? Are they really
something valuable, like bank account numbers, not just user names?
Since the space of account numbers is probably really not that large,
even a perfectly secure hash function can still be attacked through
brute force search of the account number space. So you need to
include a secret key in the hash, e.g.:
lookup_key = hash ("some secret stuff" + username);
The trouble with that is the secret stuff is now either embedded in
your java code somewhere or else it's in the database; either way,
a determined attacker (you've after all postulated that your database
is compromised) can still get it.
If you're really trying to protect seriously valuable data and there's
a lot of it, the ultimate solution is a cryptographic hardware module
doing the hashing, so to attack the scheme, the attacker must steal
the actual hardware and not just the data. Be warned, this stuff is a
bit expensive and nontrivial to program. I have some experience with
it so I might be able to offer further advice if you think you need it.
Feel free to post here or send email.
------------------------------
From: "Ben Newman" <[EMAIL PROTECTED]>
Subject: caching passwords in windows registry
Date: Tue, 23 Jan 2001 23:57:12 -0500
I've developed an application that makes use of two calls in the Windows
crypt32 API, specifically CryptProtectData and CryptUnprotectData in order
to securely cache a password in the registry. According to the MSDN
documentation, however, these calls require NT 5.0 or later. Are there
comparable calls that are supported in NT 4.0? If not, how are passwords
cached? I'd like to avoid embedding a secret key in my executable since
security by obscurity is never a good idea...
As an aside, does anyone know how therse calls work? They do not require a
key as an argument, rather it derives the key from the data. How is that
possible? My understanding is that the strength of the crypto should lie in
the key, not the algorithm. What's to stop an interloper to rederive my key
from the ciphertext in the registry (assuming they know the Windows
decryption algorithm)?
Ben
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: 32768-bit cryptography
Date: Tue, 23 Jan 2001 18:56:47 -0800
lemaymd <[EMAIL PROTECTED]> wrote in message
news:94l9ds$k2m$[EMAIL PROTECTED]...
> Poncho,
> From what you've written, it's looks as though simplicity is not this
> cipher's weakness. What path would you suggest to strengthen it? I
don't
> truly understand how you would retrieve a completely random key (which of
> course it's not, but for simplicity let's say it is) when you have only
the
> ciphertext. Theoretically, as is the case with the true stream cipher,
one
> XOR operation between the key and data should be sufficient to make an
> entirely impossible to crack piece of ciphertext. Because of the huge
size
> of the key utilized by this algorithm, it almost qualifies as a stream
> cipher itself. Thanks for your valuable input! : - )
If an attacker had only one block of unknown plaintext, that would likely be
the case. It would appear to be difficult to retrieve either the key or the
plaintext, and it would obviously be totally impossible for an XOR
operation. However, if the attacker has multiple blocks encrypted under the
same key, that changes radically. If you look at my suggested attack, you
use one block to guess key bits, and another block (or more likely, several
blocks) to verify the guess.
As for what this cipher's weakness, it would appear to me caused by several
things:
- Lack of diffusion between plaintext bits -- the value of one byte never
affects the value of another byte. This means (for example) if the attacker
leaves that a plaintext "W" at offset 27 encrypts into the byte 0xf3, then
he knows that, for any other block, a ciphertext byte 0xf3 at offset 27
implies that the plaintext had a "W" there as well
- Lack of diffusion between key bits. You at least made an attempt during
your "key mutation" step, but it really doesn't help much -- knowing (for
example, if a < b) K1[a] through K1[b], K2[a] and K3[b], you also know K2[a]
through K2[b] and K3[a] through K3[b], and that totally defines the
transform for bytes a through b of the plaintext.
>
> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> news:94j39m$map$[EMAIL PROTECTED]...
> >
> > lemaymd <[EMAIL PROTECTED]> wrote in message
> > news:94i87e$d0e$[EMAIL PROTECTED]...
> > > Poncho,
> > > How does this algorithm look? Eight identical rounds are
performed
> on
> > > each byte and each key value is rotated to the left one position after
> > each
> > > round.
> > >
> > > C[I] =
> > >
> >
>
(((((((((K1[I]^P[I])+K2[I])>>>K3[I])^K2[I])+K1[I])>>>K2[I])^K3[I])+K3[I])>>>
> > > K1[I])
> > >
> > > K1, K2 and K3 are key derived values and the symbols use the
conventions
> > you
> > > listed in your post.
> > This looks almost as vulnerable to my attack. This attack is based on
the
> > following observations/assumptions:
> >
> > - In transforming N consecutive bytes of plaintext into ciphertext (that
> is,
> > 8*N bits), the transform can be fully described by specifying 8*N+11
bits
> of
> > internal keying data (based partially on how K1, K2, K3 are
interrelated).
> > The revised cipher increases that to 8*N+16 bits.
> >
> > - Given an arbitrary N byte plaintext section and N byte ciphertext
> section,
> > there are (at least reasonably often) approximately 2**11 values of the
> > above internal keying data that transforms that plaintext to that
> > ciphertext. This is the fishiest part of the attack, which is true if
we
> > model the actual cipher as a random function, which it is not. With the
> > revised cipher, this increases to approximately 2**16 values, but this
> > assumption also becomes rather more plausible.
> >
> > - Using dynamic programming, it is possible to explicitly derive the
> > approximately 2**11 internal keying values corresponding to a particular
> > plaintext/ciphertext pair. The revised cipher makes finding the values
> > somewhat more expensive, but not prohibitively so.
> >
> > - Given a potential setting of internal keying data, we can check it by
> > using it to decrypt the corresponding range of bytes in the ciphertext
of
> > other blocks, and seeing if it decrypts to plausible plaintext.
> >
> > - We can use "crib-dragging" to find plausible plaintext/ciphertext
> > sequences.
> >
> > That should be enough for you to draw in the dots to get the full
attack.
> >
> > >
> > > In the rotation operations the 5 lsbits of the key values are used.
> > Ummm, if we're talking about rotating 8 bit bytes, we need only specify
3
> > bits
> >
> > >
> > > "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> > > news:94b3hv$gda$[EMAIL PROTECTED]...
> > > >
> > > > lemaymd <[EMAIL PROTECTED]> wrote in message
> > > > news:94aqn0$qrs$[EMAIL PROTECTED]...
> > > > > To all interested:
> > > > > Bermuda Triangle 2001 is an extremely fast, easy-to-use and
> secure
> > > > > cryptography engine. It is based on a new, 32768-bit algorithm of
> the
> > > > same
> > > > > name. Algorithm details can be found at my site as well as a
> software
> > > > > product that uses the algorithm, Bermuda Triangle 2001 Golden
> Edition.
> > > I
> > > > > also have a free cryptography engine that uses a similar (but
> > > > incompatible)
> > > > > algorithm available for download. Visit the site at:
> > > > > http://www.bermudatriangle.f2s.com/
> > > > > These software packages are written entirely in 32-bit, win32
> assembly
> > > > > language and I can encrypt or decrypt an 8.4MB file on my
Pentium(R)
> > 166
> > > > in
> > > > > 8 seconds. Please give me your feedback!
> > > > This should be pretty easy to break given several encrypted blocks
> with
> > > > known plaintext (either several short messages encrypted with the
same
> > key
> > > > or one long one). As I understand it, your encryption algorithm is
> > > > essentially:
> > > >
> > > > C[i] = ((P[i] ^ x[i]) <<< y[i]) + z[i]
> > > >
> > > > where:
> > > >
> > > > P[i] is a byte of plaintext
> > > > C[i] is a byte of ciphertext
> > > > x[i], y[i], z[i] are key dependent values, and which are repeated
> > every
> > > > 4096 bytes (and are interrelated)
> > > > ^ is xor, <<< is bitwise rotate, and + is addition mod 256
> > > >
> > > > Because x[i], y[i], z[i] repeat every 4096 bytes, this repetition
> length
> > > is
> > > > called a block.
> > > >
> > > > Here's how to rederive a good portion of the keying data: for each
> byte
> > > > within a block, locate two plaintexts that differ in that byte by
one
> > bit.
> > > > If you have at least 16 plaintexts, and the plaintexts are random,
you
> > > have
> > > > a good chance of having such a pair. Then, examine the
corresponding
> > > > ciphertexts, and see the lsbit where they differ. The rotate that
> moves
> > > the
> > > > plaintext bit that differs to that lsbit ciphertext bit that differs
> > must
> > > be
> > > > correct, thus giving you the 3 lsbits of y[i]. A similar trick can
> work
> > > if
> > > > you don't have a single pair that differs by precisely one bit, but
> you
> > > have
> > > > several pairs with low-hamming weight difference.
> > > >
> > > > Once you have most of the y[i] values, you can use the
> > interrelationships
> > > to
> > > > derive the 3 lsbits of x[i] and z[i]. Once you have that,
> > reconstruction
> > > > the rest of the x[i], z[i] values should be straight-forward.
> > > >
> > > > --
> > > > poncho
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------
** 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
******************************
