Cryptography-Digest Digest #768
Cryptography-Digest Digest #768, Volume #13 Thu, 1 Mar 01 01:13:01 EST
Contents:
Re: Keystoke recorder (Benjamin Goldberg)
Re: HPRNG ("Tom St Denis")
Re: Hash strength question (Bryan Olson)
Re: How to find a huge prime(1024 bit?) ("Dik T. Winter")
Re: philosophical question? (Nicol So)
Re: Keystoke recorder (Paul Rubin)
Re: Keystoke recorder (Ben Cantrick)
Re: Keystoke recorder ("Tom St Denis")
Re: Hash strength question (Benjamin Goldberg)
Re: HPRNG (Benjamin Goldberg)
Re: Keystoke recorder (nemo outis)
Re: what is the use for MAC(Message Authentication Code ), as there can be digital
signature? ("Scott Fluhrer")
Re: how long can one Arcfour key be used?? ("Scott Fluhrer")
Re: "RSA vs. One-time-pad" or "the perfect enryption" (Steve Meyer)
Re: how long can one Arcfour key be used?? ("Tom St Denis")
Re: what is the use for MAC(Message Authentication Code ), as there can be digital
signature? (John Savard)
Re: what is the use for MAC(Message Authentication Code ), as there can be digital
signature? ("Lyalc")
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Keystoke recorder
Date: Thu, 01 Mar 2001 02:16:09 GMT
Alberto wrote:
>
> It's seems that the easiest way to access encrypted data is to gain
> access to the target computer and install such device.
>
> Have you ever seen one of them? How does it look like? How can you
> defend yourself against this kind of attack?
Along this line of questioning -- How good is the xterm "secure
keyboard" function at preventing software keystroke logging?
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
--
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: HPRNG
Date: Thu, 01 Mar 2001 02:16:51 GMT
"Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Here's an idea for a TRNG, which uses components which are used in
> Quantum Cryptography. Get a device which produces one photon at a time,
> send it through a polarizer. Follow this with a second polarizer at 45
> degree angle from the first. Photons will go through the first 100% of
> the time, and through the second exactly 50% of the time. Measure
> photon/no photon as your bit of randomness. I call the system a
> Heisenburg Random Number Generator, or HRNG. Bits might be slightly
> biased, if the mirrors aren't exactly 45 degrees apart, but they should
> not be correlated in any way, shape, or form.
Sounds very neat. Of course you could xor a few HRNG bits together to
smoothen out any bias.
Tom
--
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Hash strength question
Date: Wed, 28 Feb 2001 19:39:26 -0800
Benjamin Goldberg wrote:
[...]
> There's a couple of reasons I want to use XOR, though, things I don't
> get from using a hash of hashes.
>
> 1) XOR is of course much faster.
Not in the greater scheme of things. To use the construct
you have to run the hash at least twice anyway. The
single-block hash at the end doesn't dominate the time.
> 2) Suppose that the hashes produced are 128 bits in length. Now suppose
> that one bit of the input is changed. This results in one of the output
> hashes changing with (1-1/2^128) probability. If I hash the hashes, the
> odds of the final result changing are (1-1/2^128)^2. If I XOR the
> hashes, the probability of the final result changing is (1-1/2^128).
How did that make your list of things to worry about? The
theorem Scott Fluhrer posted removes the concern: if the
hash is collision resistant, then the hash of hashes is
collision resistant. The same is not true of the XOR
scheme.
Note that the XOR scheme allows a time-space tradeoff that
square-roots the time to find a preimage for a given digest.
Surely the issue in 2) is trivial.
If you think 2) is really a problem, note that a
Merkle-Damgard-shaped hash function (MD5, SHA-1, most
others) repeatedly hashes the current chaining values along
with the next block of the message to get new chaining
values. If we hash two long strings which differ only near
the start, the state has a chance to collide after each
block-compression, and if it ever does then the final
digests collide. The "problem" is very much like the issue
in 2).
--Bryan
--
From: "Dik T. Winter" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,sci.math
Subject: Re: How to find a huge prime(1024 bit?)
Date: Thu, 1 Mar 2001 03:59:32 GMT
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Free-man)
writ
Cryptography-Digest Digest #768
Cryptography-Digest Digest #768, Volume #12 Mon, 25 Sep 00 10:13:00 EDT
Contents:
Re: New Strong Password-Authentication Software (Philip MacKenzie)
Re: Music Industry wants hacking information for cheap (Sagie)
(Long) Re: Tying Up Loose Ends - Correction (Guy Macon)
Re: What am I missing? (Lon Willett)
Re: Big CRC polynomials? ("Scott Fluhrer")
From: Philip MacKenzie <[EMAIL PROTECTED]>
Subject: Re: New Strong Password-Authentication Software
Date: Mon, 25 Sep 2000 08:18:18 -0400
Benjamin Goldberg wrote:
>
> Thomas Wu wrote:
> [snip]
> > PAK is more like EKE and SPEKE in that both client and server know the
> > same password, while SRP is verifier-based, so the server's secret
> > isn't enough to impersonate a client.
>
> Saying that the SRP server doesn't know enough to impersonate a client
> implies that a PAK server does... I don't know much about either
> protocol, but does this mean that a person with access to the data files
> of a PAK server can impersonate the client to another PAK server, or
> does it mean that he has the password in the clear?
>
> That last possibility sounds very bad.
>
The version of PAK used in the software release is resilient to server
compromise, just like SRP (except that for PAK there is
a formal proof of this). It is not the PAK-X protocol from
the posted paper, but a slightly revised protocol that
I call PAK-RY. I will post the revised protocol, along
with the full proof of security, within a couple days at:
http://www.bell-labs.com/user/philmac/pak.html
-Phil
--
From: Sagie <[EMAIL PROTECTED]>
Subject: Re: Music Industry wants hacking information for cheap
Date: Mon, 25 Sep 2000 12:34:48 GMT
> >Alice is a bank robber; she knows that Bob, the police officer, has
placed
> >a surveillance camera in the bank and it's attached to a recording
device
> >that detects watermarks and refuses to record marked data. So she
walks
> >into the bank wearing a T-shirt with a watermark printed on it, or
perhaps
> >puts a video screen playing a watermark pattern in view of the
> >camera. The recording device refuses to record it, and so her crime
> >doesn't show up on the tape.
>
> Yes, but realistically no watermark detector would ever pick up
> a mark after the extremely severe distortion of playing the
> content on a video screen back into a camera. Especially
> since security cams are not likely to be high quality nor
> recording onto DVD recorders.
>
> And if you're planning on introducing a video screen into the
bank
> lobby, going to the trouble to place it just so and keep from
> tilting relative to the camera, well, chewing gum over the lens
> is actually cheaper and less conspicuous.
Dude, I think I know what your problem is... You have absolutely no
sense of humor... :-P
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (Guy Macon)
Subject: (Long) Re: Tying Up Loose Ends - Correction
Date: 25 Sep 2000 13:40:27 GMT
David A. Scott wrote:
> Then your to stupid to read. Cause that ain't what it
>means. It means jerk look at the damn webpage. I can't
>spoon feed and burp you for ever. Grow up MOK.
You swine. You vulgar little maggot. You worthless bag of filth. As we
say in Texas, you couldn't pour water out of a boot with instructions
printed on the heel. You are a canker, an open wound. I would rather
kiss a lawyer than be seen with you. You took your last vacation in
the Isles of Langerhan.
You're a putrescent mass, a walking vomit. You are a spineless little
worm deserving nothing but the profoundest contempt. You are a jerk,
a cad, a weasel. Your life is a monument to stupidity. You are a
stench, a revulsion, a big suck on a sour lemon.
You are a bleating foal, a curdled staggering mutant dwarf smeared
richly with the effluvia and offal accompanying your alleged birth
into a hostile world. You are an insensate, blinking calf,
meaningful to nobody, abandoned by the puke-drooling, giggling
beasts who sired you and then died of shame in recognition of what
they had done. They were a bit late.
I will never get over the embarrassment of belonging to the same
species as you. You are a monster, an ogre, a malformity. I barf
at the very thought of you. You have all the appeal of a paper cut.
Lepers avoid you. You are vile, worthless, less than nothing. You
are a weed, a fungus, the dregs of this earth. And did I mention
that you smell?
Try to edit your responses of unnecessary material before attempting
to impress us with your insight. The evidence that you are a
nincompoop will still be available to
Cryptography-Digest Digest #768
Cryptography-Digest Digest #768, Volume #11 Sun, 14 May 00 00:13:00 EDT
Contents:
S-BOX Construction Tutorial? ("Simon Johnson")
Re: On higher level Feistel schemes (Tom St Denis)
Re: Living in my car in Miami ... 5/10/2000 - cryptography and other ("Douglas A.
Gwyn")
Re: How does one test an encryption algorithm? ("Douglas A. Gwyn")
Re: Help!? Accidental 'crypt' needs to be undone ("Douglas A. Gwyn")
Re: Two basic questions ("Douglas A. Gwyn")
Re: factor large composite ("Douglas A. Gwyn")
Re: On higher level Feistel schemes (zapzing)
Re: UK issue; How to determine if a file contains encrypted data? (zapzing)
Re: Scary Possibility: Ticklish Chips (zapzing)
Re: S-BOX Construction Tutorial? (Tom St Denis)
Re: Cipher contest analysis [several] (Boris Kazak)
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: S-BOX Construction Tutorial?
Date: Sat, 13 May 2000 14:49:10 -0700
Does any one have a PDF or HTML S-BOX construction tutorial?
If So please, leave a post with the URL as a reply to this message thanxs.
Simon Johnson
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: On higher level Feistel schemes
Date: Sun, 14 May 2000 01:22:39 GMT
In article <8fksf9$un8$[EMAIL PROTECTED]>,
zapzing <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> > Previously I suggested several possibilities of
> > variations of a given block cipher, including using
> > varaible keys, permuting the subkeys and permuting the
> > S-boxes for different rounds. In all these variations
> > the block size remains unchanged. In the following
> > a simple, in fact trivial, possibility of doubling
> > the block size of a given cipher is indicated.
> >
> > We note that a Feistel scheme is customarily applied
> > inside a block cipher, e.g. DES. However, given any
> > block cipher of size n bits, denoted by the function
> > E in the following, one can easily build a cipher of
> > block size 2n bits though defining a typical Feistel
> > round as follows:
> >
> > L_(i+1) = R_i
> >
> > R_(i+1) = L_i xor E(K_i, R_i)
> >
> > where L_i and R_i each have n bits and the subkeys
> > K_i are to be obtained through some appropriate
> > key scheduling.
> >
> > An apparent disadvantage of this lies of course in
> > speed. However, the scheme appears otherwise to be
> > o.k. At least theoretically, one could recursively
> > apply the Feistel scheme to obtain ciphers of
> > increasingly larger block size.
> >
> > Thanks for your critiques and comments in advance.
> >
> I was just thinking of something similar, but
> I decided that I wanted to quadruple a block
> of DES. I think that in order to do that, recursive
> Feistel networks would be too time consuming,
> But I think that Wrapped Cypher Block Chaining
> mode would just about do the trick.
>
> If one has four blocks, A thru D.
> then WCBC mode can be described as:
>
> Procedure 1:
> X=B+E(A)
> Y=C+E(X)
> Z=D+E(Y)
> W=A+E(Z)
>
> Where + indicates xor and E indicates
> encryption. If the underlying algorithm
> is secure then I believe (if I am not mistaken)
> this should be secure. Am I correct in this?
In the encryption direction only. Maybe. But the diffusion between
blocks would not be 100% ideal. (See the CAST-256 design), note a
change in 'D' will only change W, and the rest with prob 0.
So you would have to have afew rounds of the four FULL encryptions.
This is a terribly bad idea in terms of efficiency.
If you must be wierd try this.
A = A xor (Ek1(C) + Ek2(D))
B = B xor (Ek2(C) + Ek1(D))
(swap (a, b) <-> (c, d))
And repeat with new k1/k2 values for a round or two more, where E is an
encryption algorithm (say DES in this case...). Each round uses two
independant keys. This algorithm is terribly slow (slower then just
encrypting four blocks in CBC mode) but would be a 'block cipher' with
ideal avalanche, etc..
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Living in my car in Miami ... 5/10/2000 - cryptography and other
Date: Sun, 14 May 2000 01:33:29 GMT
"Markku J. Saarelainen" wrote:
> When I woke up in this morning, it was around 5:50 A.M. and I saw a
> shopping mall.
Remind me: Why do we care?
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How does one test an encryption algorit
Cryptography-Digest Digest #768
Cryptography-Digest Digest #768, Volume #10 Sun, 19 Dec 99 15:13:01 EST
Contents:
Re: compression & encryption (lordcow77)
Re: Casio's Multi Dimensional Space Rotation encryption (David A Molnar)
Re: First Bijective Arithmetic Compression ("Gary")
Re: random numbers straight out of MS BASIC (Scott Nelson)
Re: compression & encryption (John Savard)
Re: Enigma - theoretical question (Jim)
Re: Analogue encryption (Jim)
Re: compression & encryption (Tim Tyler)
Re: First Bijective Arithmetic Compression (Tim Tyler)
Re: Microsoft- PKI/E-comm Director Opening (Tim Tyler)
Re: First Bijective Arithmetic Compression ("Gary")
Re: dictionary attack (Guy Macon)
Re: Casio's Multi Dimensional Space Rotation encryption (CLSV)
Re: Sorry, I was unclear... ("Trevor Jackson, III")
Re: compression & encryption (lordcow77)
Re: Sorry, I was unclear... (Guy Macon)
Re: Analogue encryption ("Trevor Jackson, III")
Re: random numbers straight out of MS BASIC (Guy Macon)
SCOTT's H2COM weakness ("Gary")
D.SCOTT's Compressor Weakness ("Gary")
From: lordcow77 <[EMAIL PROTECTED]>
Subject: Re: compression & encryption
Date: Sun, 19 Dec 1999 08:13:27 -0800
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
> Jerry Coffin <[EMAIL PROTECTED]> wrote:
> [question about compressors addding opatetrened information to the
> file]
> : The alternative view is that the amount of known plaintext
> revealed by
> : this is typically so small that it makes no real difference --
> the
> : attacker has to have broken the encryption quite thoroughly
> before a
> : tiny amount of known plaintext is even marginally useful. A
> known-
> : plaintext attack against a block cipher normally has to have ALL
> the
> : plaintext for a complete block (e.g. 256 bits) known before it's
> of
> : any use at all.
> Curious. The ability to mechanically reject 65535 out of 65536
> keys
> based on decrypting only the first two bytes of a file effectively
> knocks sixteen bits off the key. It pretty much reduces (say) a
> 64-bit
> keyspace to a 48-bit one.
> Decrypting the first two bytes of a file is really not much effort
> compared to decrypting the whole thing, decompressing it and then
> looking
> for the statistics of English text.
> /Perhaps/ your cypher can withstand such a keyspace reduction - if
> it has
> a large enough key in the first place - but why should you
> tolerate such
> nonsense?
> If there is some other attack, or the attacker can determine some
> bits of
> the key by other means, the plaintext provided by the poor
> compression may
> be the final straw.
> Many types of compression leak information while compression is
> in progress - as well as any header they add.
> AFAIK, only things like Huffman and Arithmetic coding typically
> /only/
> leak information at the end of the file. Anything (orthodox) that
> uses a
> sliding window, for example, will leak all the way through the
> compression
> process.
> --
Pray tell, but how would one decrypt just the first two bytes from a
single block encrypted with a block cipher? You can't, and that's why
your "mechanically reject" comment is just wrong.
* 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: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Casio's Multi Dimensional Space Rotation encryption
Date: 19 Dec 1999 16:22:38 GMT
CLSV <[EMAIL PROTECTED]> wrote:
> Has anyone tried to analyze the algorithm?
> (I'm still busy trying to understand it.)
I'm also trying to understand it. At a very vague level, it looks
like "generate random vector and rotation, then rotate message vector
by rotation and OP by that vector." Then they run this in sort of
a chaining mode.
That could be a one-time-pad, but I suspect the difference will come in
the details they give for key generation. Especially that comment about
how XOR is "not safe."
Oh - wait. In the key generation part, they start with a random vector R,
and then rotate it by an angle dependent on some P parameters. So the key
consists of a series of vectors :
r_0 = seed
r_i = a * rotation(r_{i-1}) + c
where rotation() is defined in terms of a parameter set P. The last
section, as far as I can tell, is just a tutorial on how to build rotation
matrices.
They further specify that P and c can be made dependent on the time, but,
like, if you can guess about what time someone sent a message, this
doesn't seem to help much. Plu
Cryptography-Digest Digest #768
Cryptography-Digest Digest #768, Volume #9 Fri, 25 Jun 99 09:13:05 EDT
Contents:
Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (Robert
Harley)
Bytes of "truly random" data for PRNG seed. (Benjamin Goldberg)
Re: generated pad for OTP? (fungus)
Re: Bytes of "truly random" data for PRNG seed. ("Douglas A. Gwyn")
Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (Medical
Electronics Lab)
Re: one time pad ("Douglas A. Gwyn")
Cryptography FAQ (01/10: Overview) ([EMAIL PROTECTED])
Cryptography FAQ (02/10: Net Etiquette) ([EMAIL PROTECTED])
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length?
Date: 25 Jun 1999 11:40:03 +0200
Medical Electronics Lab <[EMAIL PROTECTED]> writes:
> No, Koblitz curves [...] These curves have
> structure of 2*prime, 4*prime or 18*prime. For 2 or 4*prime, and
> n large, where's the "extra" structure?
"Structure" covers a lot more than just the number of points over one
field. These curves have many special properties, for instance a
bunch of automorphisms as I mentioned. These properties are a minor
convenience for implementation but a major danger for security.
> After 15+ years of pounding, the basic ECC is still pretty secure.
This is true for most curves, but false for many of the special cases
that have been proposed. Special cases are dangerous. What's hard to
understand about that?
Bye,
Rob.
--
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Bytes of "truly random" data for PRNG seed.
Date: Fri, 25 Jun 1999 07:33:41 -0400
The seed generator used in java.security.SecureRandom says that it
"has not been thoroughly studied or widely deployed." Does anyone know
how I could go about verifying that the bytes provided by that method are
"truly random," in the sense that they are usable for cryptographic
purposes?
Incidentally, in case anyone is interested, I have my own implementation
of the SeedGenerator at
http://www.rpi.edu/~goldbb/src/java/util/SeedGenerator.java
which uses threads in such a way as to avoid causing the one-second
freeze-up when the class is loaded that the version in java.security does.
Ben Goldberg
--
The fountain code has been tightened slightly so you can no longer dip objects
into a fountain or drink from one while you are floating in mid-air due to
levitation.
Teleporting to hell via a teleportation trap will no longer occur if the
character does not have fire resistance.
- README file from the NetHack game
--
From: fungus <[EMAIL PROTECTED]>
Subject: Re: generated pad for OTP?
Date: Fri, 25 Jun 1999 15:12:19 +0200
Benjamin Goldberg wrote:
>
> If I have some secret sequence of bytes [as in a session key] and use this
> sequence as a seed for a psuedo random number generator, and use the
> output of this PRNG as my pad, how easy/hard is it to decrypt data that
> has been XORed with this generated pad? While I assume that it depends on
> the PRNG
Correct.
> are there generators that are "crytpographically strong?"
Yes. RC4 springs to mind, or you could do a web search for the
"Blum Blum Shub" (nice name!). You can also use a block cipher
like DES in feedback mode (keep re-encrypting the same block of
data).
> Java offers the class 'java.secuity.SecureRandom' which it *claims* is
> "crytpographically strong," but I don't know enough about cryptography to
> figure out how accurate that claim of strength is.
>
I assume the people who made Java do know enough to claim this.
> The "SecureRandom" generator produces 20 psuedo-random bytes at a time, by
> incrementing a 64-bit counter, and using a SHA-1 digest on that counter
> and a seed. While I know you can't reconstruct a message directly from a
> digest, we have, for many values of the counter, the digest of a known
> value followed by an unknown value... could one concievably trace the path
> of the bits of the counter through to the digest, and compute the next
> digest in the sequence? The counter of course starts at 0, and is
> incremented every time 20 bytes of psuedo-random data has been used.
>
No. If any part of the value is unknown then you can't predict the hash
value. Although you don't mention the size of the unknown data, this
algorithm sounds reasonable as a crypto random number generator.
Your security against a brute-force attack obviously depends on the size
of the secret data.
--
<\___/>
/ O O \
\_/ FTB.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED
