Cryptography-Digest Digest #767
Cryptography-Digest Digest #767, Volume #13 Wed, 28 Feb 01 21:13:01 EST
Contents:
Re: Keystoke recorder (nemo outis)
Re: What is the probability that an md5sum of a group of md5sums will be the
same? (Steve Roberts)
Re: What is the probability that an md5sum of a group of md5sums will be the
same? ("Sam Simpson")
Re: what is the use for MAC(Message Authentication Code ), as there can (Anton
Stiglic)
Re: DH Key Agreement in SSL (Anton Stiglic)
Re: Keystoke recorder (William Hugh Murray)
Re: what is the use for MAC(Message Authentication Code ), as there can be digital
signature? ("david Hopkins")
Re: encryption and information theory (Benjamin Goldberg)
Re: philosophical question? (Benjamin Goldberg)
Re: philosophical question? (wtshaw)
HPRNG (Benjamin Goldberg)
From: [EMAIL PROTECTED] (nemo outis)
Subject: Re: Keystoke recorder
Date: Wed, 28 Feb 2001 22:39:19 GMT
Software keyloggers include: skin98 (and later), keykey, winwhatwhere, PC
Activity monitor, and many others.
A good (software) keylogger *detector* is PC Investigator (aka Hookprotect)
One example of an inline hardware keylogger that goes on the end of the cable
rather than inside the keyboard is at:
http://www.keyghost.com/
Again, there are many others.
Regards,
In article <[EMAIL PROTECTED]>, Alberto
<[EMAIL PROTECTED]> 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?
>
>Thanks.
>Alberto
>
>
--
From: [EMAIL PROTECTED] (Steve Roberts)
Crossposted-To: sci.math
Subject: Re: What is the probability that an md5sum of a group of md5sums will be the
same?
Date: Wed, 28 Feb 2001 23:07:26 GMT
jtnews <[EMAIL PROTECTED]> wrote:
>Given:
>
> Files: 1 to N
>
> A program takes files 1 to N and generates
> an array of N md5sums S[1..N].
>
> An md5sum is then generated on array S.
>
> What is the probability that the md5sum
> generated on array S will be the same
> if only one of the files 1 to N
> is changed?
>
>Does anyone have a clue on how to proceed
>with such a calculation?
Yeah, an MD5 digest is 128 bits and essentially random.
So the chance that your new digest is the same as the old one, or as
any given digest, is 1 in 2^128
However there is a far greater (but still tiny) chance that two
digests from a large population are the same as each other. That's
simply because you can do more comparisons. If you took your N
digests from the N files separately, for example. But you'd still
need billions of files (N > 2^30 say) to have a hope of getting two
digests the same.
Steve
--
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: What is the probability that an md5sum of a group of md5sums will be the
same?
Date: Wed, 28 Feb 2001 23:17:09 -
Steve Roberts <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> jtnews <[EMAIL PROTECTED]> wrote:
> However there is a far greater (but still tiny) chance that two
> digests from a large population are the same as each other. That's
> simply because you can do more comparisons. If you took your N
> digests from the N files separately, for example. But you'd still
> need billions of files (N > 2^30 say) to have a hope of getting two
> digests the same.
I'd expect it to be somewhere nearer 2^64 files - it's the birthday paradox
of a 128-bit hash function.
--
Regards,
Sam
http://www.scramdisk.clara.net/
--
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: what is the use for MAC(Message Authentication Code ), as there can
Date: Wed, 28 Feb 2001 18:33:09 -0500
david Hopkins wrote:
>
> Why use for MAC(Message Authentication Code ),
> as there can be digital signature?
>
> thanks
Because MACs are typically much faster to compute.
Same kind of tradeoff like between symmetric
encryption schemes and public key encryption schemes.
--
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: DH Key Agreement in SSL
Date: Wed, 28 Feb 2001 18:48:18 -0500
You typicaly use what is called a key derivation function,
which has two purposes: get keys of the correct size and
scramble the bits in the shared secret in order to break
and algebraic structure.
Take a look at
http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-09.txt
the ietf draft for SSH2.
After the key agreement, you end up with two values, K and H
(H is the hash of a couple of stuff, K the DH secret key).
Cryptography-Digest Digest #767
Cryptography-Digest Digest #767, Volume #12 Mon, 25 Sep 00 08:13:01 EDT
Contents:
Re: LFSR as a passkey hashing function? (Bryan Olson)
Re: LFSR as a passkey hashing function? (Bryan Olson)
Re: HAC DES Test Vectors ("kihdip")
Re: Question on biases in random-numbers & decompression (Roger Schlafly)
Re: Big CRC polynomials? (Bryan Olson)
Re: RSA?? (Albert Yang)
A New (?) Use for Chi (John Savard)
Re: Tying Up Loose Ends - Correction (Mok-Kong Shen)
Re: Why is TwoFish better than Blowfish? (Albert Yang)
Re: Software patents are evil. (Vernon Schryver)
Re: Question on biases in random numbers & decompression (Mok-Kong Shen)
Re: What make a cipher resistent to Differential Cryptanalysis? (Mok-Kong Shen)
Re: What make a cipher resistent to Differential Cryptanalysis? (Mok-Kong Shen)
Re: Questions about how to run a contest (Sylvain Martinez)
Triple DES CBC test vectors ("MVJuhl")
Re: Tying Up Loose Ends - Correction (Tim Tyler)
Re: Why is TwoFish better than Blowfish? (Tom St Denis)
Re: What make a cipher resistent to Differential Cryptanalysis? (Tom St Denis)
Re: 128-bit Secure LFSR (Whoops) (Tom St Denis)
Re: Tying Up Loose Ends - Correction (Tim Tyler)
Re: Question on biases in random numbers & decompression (Tim Tyler)
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: LFSR as a passkey hashing function?
Date: Mon, 25 Sep 2000 06:40:46 GMT
Tom St Denis wrote:
> Try this.
>
> 1. Feed the state with 'n-bits' of userkey
> 2. Run the LFSR for 2n times thru a self-shrinking generator
> 3. Take the final state as the hash
Self-shrinking doesn't change the state sequence; it
only operates on the output. The above is just as
reversible as the original.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: LFSR as a passkey hashing function?
Date: Mon, 25 Sep 2000 07:01:14 GMT
Simon Johnson wrote:
> Say we take a 128-bit primitive polynomial mod 2 and
> covert it to an LSFR. If we want to store a 128-bit
> passkey for a 128-bit key encryption algorithm, for
> example, we would enter the key as the initial state
> of the register. We then clock it 128 times, to
> clear out the passkey. Then we clock it a futher
> 128-bit times, and record this bit sequence as the
> hash. Any problems with this design?
It's overly complicated as way to store a 128 bit
quatitity, which is the only stated requirment. As
Tom noted, the state transform is not one-way. But
before we consider the merits of solutions, we need
to define the problem. What security properties
are you looking for?
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Re: HAC DES Test Vectors
Date: Mon, 25 Sep 2000 09:12:36 +0200
Martin Wolters wrote in message <8ql3dr$1n8$[EMAIL PROTECTED]>...
>Hi,
>
>In the Handbook of Applied Cryptography,
>the following DES-Test Vectors are shown:
>
>Key: 0123456789ABCDEF
>
>P: 4E6F772069732074 68652074696D6520 666F7220616C6C20
>C: 3FA40E8A984D4815 6A271787AB8883F9 893D51EC4B563B53
>
>My Implemention returns:
>
>C: 5d1b45d8c23190cd 09b1c144bf6ff01b 603c73811b87f13b
>
>I once checked my Implementation with a Test vector making HTML file,
>and it seemed to be correct. Are the Test vectors in the HAC wrong?
Nope - The testvectors in Handbook of Applied Cryptography (p. 256) are 100%
right.
For other testvectors try the NIST Special Publication 800-17 at
http://csrc.nist.gov/nistpubs/800-17.pdf
(page 124 and forward)
Kim
--
From: Roger Schlafly <[EMAIL PROTECTED]>
Crossposted-To: comp.compression,sci.crypt.random-numbers
Subject: Re: Question on biases in random-numbers & decompression
Date: Mon, 25 Sep 2000 00:42:09 -0700
Benjamin Goldberg wrote:
> I've been looking for a way to convert a stream of unbiased random bits
> into an unbiased stream of random numbers in an arbitrary range, and I
> think I've hit on an idea that hasn't been suggested before:
>
> Take an arithmetic dececoder, and initialize it to believe that the
> values 0, 1, 2 are equiprobable, and no other values will occur. Then
> feed it the stream of random bits. This should result in an unbiased
> stream of random numbers in the range 0..2. However, I don't understand
> arithmetic decompression well enough to know for certain if this will
> work as I've suggested.
Yes, that will work, but why not just use the bits directly?
Ie, if you have 64 bits, convert to an unsigned 64 bit integer,
and
Cryptography-Digest Digest #767
Cryptography-Digest Digest #767, Volume #11 Sat, 13 May 00 21:13:01 EDT Contents: Q: How to find good characteristics for differential cryptanalysis? (JBR) Re: Cipher contest analysis [several] (Boris Kazak) Re: zeroknowledge.com and freedom.net - Snake oil? (Wei Dai) Destructive crypting (Daniel =?iso-8859-1?Q?=C5kerud?=) Re: incremental prng? (Tom St Denis) Re: Destructive crypting (stanislav shalunov) Re: Destructive crypting (Tom St Denis) Re: An argument for multiple AES winners (Bruce Schneier) Hitachi Patent (Tom St Denis) Re: zeroknowledge.com and freedom.net - Snake oil? (Guy Macon) Re: On higher level Feistel schemes (zapzing) Re: How does one test an encryption algorithm? (Mark Wooding) Re: Prime Generation in C,C++ or Java (Mark Wooding) From: JBR <[EMAIL PROTECTED]> Subject: Q: How to find good characteristics for differential cryptanalysis? Date: Sat, 13 May 2000 17:12:29 -0400 Hello sci.crypt'ers, Given an iterated cipher, how would you go about finding high-probability characteristics for differential cryptanalysis? I've read several descriptions of differential cryptanalysis and understood them (for the most part, but not completely). What the authors didn't say was how they came up with the high-probability characteristics in the first place. Is there a surefire method for finding the most probable n-round characteristic for specific round structures? If not, what would be a good heuristic for finding good (but not necessarily optimal) n-round characteristics for unfamiliar round structures? In general, are the characteristics used in published differential cryptanalyses known to be optimal, or do they just work well enough? I don't have convenient access to a technical library, so a brief description of the relevant algorithms and heuristics would be helpful. (Pointers are welcome too, of course). My sincere thanks in advance. -- From: Boris Kazak <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Subject: Re: Cipher contest analysis [several] Date: Sat, 13 May 2000 21:19:11 GMT Dear Joe: First, let me thank you for paying even as brief attention as you did (most attendants of the group don't grant the contest any glance at all). But then, your attitude strangely reminds me of the situation when an applicant sends a resume to the personnel office of a company. This resume must be specifically tailored down to the fact that no HR lady will look at any partucular resume for more than 25 seconds before reaching an all-important decision. If the resume failed to impress her in these 25 seconds, it goes straight to the trash bin. Thank you also for mentioning that the results of your preview are _preliminary_ (meaning we applicants still have some hope). ashwood wrote: > > I had some spare time today, so I decided to begin my analysis of the > entrants to the cipher contest. SO here we have preliminary results against > what I reviewed. > > I found Pikachu rather poorly written, with massive portions that would be > needed to make it work left out. There are two very good examples, 2PHT is > specified as the following > 2PHT(a, b) -> (a', b') >a' = 2a + b >b' = a + b > Where it is quite unclear whether the a used in the second line is the a > from the first line. It is also never specifed how the replacement is to > take place. The second example is his use of <<< which, since I know his > typical lanuage should be <<, but without more specification it is entirely > possible that he meant something else. Without a complete specification it > is impossible to analyze the result. I also found a description of the key > schedule conspicuously missing, leaving the only reasonable decision to be > that the same keys are used for each duoble round, so a slide attack is > perfectly valid. Even without a full specification if this is in fact the > case, the cipher is nearly trivial. > > MMBooze is also very incomplete, and makes no complaint about it, stating > that "there can be a zillion varients" I actually stopped reading there, > because going further would only have wasted time with something that is > again, not fully specified. - Sorry if this was boring - however, only 1 of this zillion is described, the one actually implemented in the cipher. BTW, Mr. D. Wagner understood the basic algorithm of MMBOOZE pretty well without asking me even a single question, and even presented the outline of a suggested attack. We are now in the process of mutual clarifications, if his attack will succeed, I will be the first to publicly admit it. - > > LJ
Cryptography-Digest Digest #767
Cryptography-Digest Digest #767, Volume #10 Sun, 19 Dec 99 11:13:01 EST
Contents:
Re: First Bijective Arithmetic Compression ("Gary")
Re: 'Simple' password storage (CLSV)
Re: The 20 years periods did apply to 2 of the 3 patents. >> Thanks for
([EMAIL PROTECTED])
Re: First Bijective Arithmetic Compression (SCOTT19U.ZIP_GUY)
Re: The 20 years periods did apply >> Avpr, jgfunj !!! ([EMAIL PROTECTED])
Re: Casio's Multi Dimensional Space Rotation encryption (SCOTT19U.ZIP_GUY)
AES and MATTS COMPRESSION (SCOTT19U.ZIP_GUY)
Re: CryptoPunk - 128 bit encryption? (Tom St Denis)
Re: random numbers straight out of MS BASIC (Tom St Denis)
Re: Casio's Multi Dimensional Space Rotation encryption (Tim Tyler)
Re: First Bijective Arithmetic Compression ("Gary")
Re: Casio's Multi Dimensional Space Rotation encryption (CLSV)
Re: compression & encryption (Tim Tyler)
dictionary attack ("Michael Velten")
Re: First Bijective Arithmetic Compression (Tim Tyler)
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: First Bijective Arithmetic Compression
Date: Sun, 19 Dec 1999 13:07:37 -
First of all you constantly state Compress(Decompress(X))=X, as if this is
all an analyst can use to confirm a sucessful decryption. However your
system still doesn't stop an analyst checking Decompress(X) for headers such
as those found in jpeg,bmp,exe and text strings like "the" " a ". IE your
compression routine is little more than a time consuming process an analyst
has to go through to get to the the actual information he wishes to analyse.
Seconly to get the one to one property you've had to introduce rules to
bodge illegal decompressions.
Take your 4th rule;
David says:"
Rule four: ( hardest rule of all) If the last byte has the last token start
in the last 7 bits of the last byte and only contains zeros on that byte .
You assume that there are hidden ones that where chopped off during
compression. Only if the file that is one token shorter than this one, would
have had hidden 1 bits cutoff during its compression. This rule means that
the all zero start of the last token in the last 7 bits could depend on what
would have happened to the next shorter file, and that file status could be
a function even further back in the file. It was the lack of focus on my
part that made me miss this recursive rule for a while, and I kept getting
more and more complicated special cases. I hope this solves this.
"
If an analyst found that this rule was invoked and knows that you never
randomly chopped off hidden ones in compression, it would indicate to him
that this is an illegal non 1-1 decompression and can be chucked out!
--
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: 'Simple' password storage
Date: Sun, 19 Dec 1999 13:30:31 +
Jerry Coffin wrote:
>
> [EMAIL PROTECTED] says...
> > Where do I find all of the AES entrants source code? I am relatively new to
> > cryptography, but a firm programming background makes it a lot easier to
> > understand what you are talking about.
Better get a firm crypto background. Reading source code
without understanding the cryptographic principles is not the
way to go. OTOH learning the basic principles with real-world
examples at hand is.
> Some of them are available from the individual entrants [...]
For links see the Block Cipher Lounge:
http://www.ii.uib.no/~larsr/aes.html
> Assuming (as appears to be the case) that you're located inside
> the US, you can also get a CD-ROM from NIST that contains source
> to all of them plus various other technical information about them.
You can also get this CD-ROM from NIST when you are outside
the US. Look at their homepage how to apply for an export
license:
http://csrc.nist.gov/encryption/aes/aes_home.htm
Regards,
Coen Visser
--
From: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp
Subject: Re: The 20 years periods did apply to 2 of the 3 patents. >> Thanks for
Date: Sun, 19 Dec 1999 08:38:35 -0500
Thanks for the contributions. It has been great !
--
Thanks, Richard
=
[EMAIL PROTECTED] wrote:
>
> The 3 most known patents in the encryption area are :
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: First Bijective Arithmetic Compression
Date: Sun, 19 Dec 1999 14:29:47 GMT
In article <83ilim$1b8$[EMAIL PROTECTED]>, "Gary" <[EMAIL PROTECTED]>
wrote:
>First of all you constantly state Compress(Decompress(X))=X, as if this is
>all an analyst can use to confirm a sucessful decryption. However your
>system still doesn't stop an analyst checking Decompress(X) for h
Cryptography-Digest Digest #767
Cryptography-Digest Digest #767, Volume #9 Fri, 25 Jun 99 07:13:04 EDT Contents: Re: one time pad (Greg Ofiesh) Re: one time pad ([EMAIL PROTECTED]) Re: one time pad ([EMAIL PROTECTED]) Re: one time pad ([EMAIL PROTECTED]) Re: TeraPi (fungus) Re: On an old topic of internet publication of strong crypto (Mok-Kong Shen) Re: one time pad (Benjamin Goldberg) Re: Converting arbitrary bit sequences into plain English texts (Mok-Kong Shen) Re: Converting arbitrary bit sequences into plain English texts (Mok-Kong Shen) Re: Converting arbitrary bit sequences into plain English texts (Mok-Kong Shen) Re: Encryptor that fits on a disk? (Robert G. Durnal) Re: Converting arbitrary bit sequences into plain English texts (Mok-Kong Shen) Re: Converting arbitrary bit sequences into plain English texts (Mok-Kong Shen) Re: Converting arbitrary bit sequences into plain English texts (Mok-Kong Shen) Re: xtea (Nikos Mavroyanopoulos) generated pad for OTP? (Benjamin Goldberg) From: Greg Ofiesh <[EMAIL PROTECTED]> Subject: Re: one time pad Date: Fri, 25 Jun 1999 05:50:54 GMT > Terry, I tend to agree with you about the fallaciousness of assigning > relative strengths to ciphers, but this usage of the term proof is > probably not a good one. It implies a mathematical level of proof. > Note that we have no equivalent proof that the earth is not flat... This will likely be my last post on this thread. I really can't say thank you all for your patience with me as you pointed some thing out to me I have not considered. I think the examples helped the best. Let me just clarify what I ment by mathematically provable. A cipher like PGP, RSA, DES, etc., all have a single conclusion, a single correct answer. If you ever get it, you know you have it. There is only one candidate and when you find it you win. These ciphers have no guarantee of security because no one knows if the NSA, for example, can crack any of them. People believe this thing, people believe that thing, but in the end no one knows for certain and therefore there exists no proof - no proof of security. The OTP on the other hand guarantees two things: 1. the candidates can be anything (without exception) and 2. that is where the work of the cryptanalyst ends. No one candidate can be proven correct. This difference is what I ment by proof of security, and I think you can write it out mathematically as a simple proof. It is really an issue of numbers - the number of candidates has to be brought to 1 to defeat the guarantee of security. Now I say all this with all the new information I have gleaned. For example, the scenarios painted by Terry would have to be avoided to maintain the OTP guarantee. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. -- Date: Thu, 24 Jun 1999 16:04:50 -0400 From: [EMAIL PROTECTED] Subject: Re: one time pad AllanW wrote: > > [EMAIL PROTECTED] (Terry Ritter) wrote: > > One approach to a solution might be to build a physically-random > > device which cannot be incorrectly built, cannot fail to perform, > > cannot be damaged in an undetectable way, and will meet every > > possible test for randomness, even if we have not yet defined > > those tests. Then we could say that our device was "provably > > random," which would imply a security proof for an OTP using > > such a device as a keystream generator. In my opinion, any > > attempt to build such a device would be a foolish quest. > > Would it? > > Consider a CPU which has no fixed clock speed. That is, instead > of (say) 450MHz, we allow the clock speed to "drift" very > slowly -- sometimes as low as 400MHz, other times as high as > 450MHz, in a cycle that repeats 100 times per second. > > To this we attach a single-bit counter attached to it's own > clock source, independant of the CPU and much faster. Give > the counter a known duty cycle; ideally, 50% of the time it > contains "0" and the other 50% of the time it contains a > "1". (Other duty cycles can be adjusted algorithmically.) > Like the CPU's clock, we will allow the counter's clock to > "drift", sometimes as low as 3GHz, other times as high as > 4GHz, in a cycle that repeats 500 times per second. > > Note that the CPU's clock drift is not connected to the > counter's clock drift in any way. This is an unreasonable assumption. It would require a massive effort to demonstrate a complete decoupling, and skeptics would still be able to question the rigor of the demonstration (proof). > > Even when the CPU is at it's fastest (450MHz) and the counter > is at it's slowest (3GHz), the counter will change states
