Cryptography-Digest Digest #769
Cryptography-Digest Digest #769, Volume #13 Thu, 1 Mar 01 05:13:01 EST
Contents:
Re: what is the use for MAC(Message Authentication Code ), as there can be digital
signature? ("Scott Fluhrer")
Re: How to find a huge prime(1024 bit?) ("david Hopkins")
Re: Sad news, Dr. Claude Shannon died over the weekend. ("John A. Malley")
Re: Again on key expansion. (Paul Crowley)
Re: how long can one Arcfour key be used?? (Paul Crowley)
Re: HPRNG ("Matt Timmermans")
Re: encryption and information theory (Mok-Kong Shen)
Re: How to find a huge prime(1024 bit?) (Mok-Kong Shen)
Question about MD5,CRC and SHA(1). (Zeljko Vrba)
Rijndael decryption (Panu =?iso-8859-1?Q?H=E4m=E4l=E4inen?=)
Re: Improved stream cipher? (was: Re: Simple, possibly flawed, stream cipher)
("Henrick Hellström")
Re: Keystoke recorder (Frank Gerlach)
Re: Rijndael decryption ("ajd")
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: what is the use for MAC(Message Authentication Code ), as there can be
digital signature?
Date: Wed, 28 Feb 2001 22:14:03 -0800
John Savard <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Wed, 28 Feb 2001 19:41:53 GMT, "david Hopkins"
> <[EMAIL PROTECTED]> wrote, in part:
>
> >Why use for MAC(Message Authentication Code ),
> >as there can be digital signature?
>
> Without a MAC, a digital signature would have to be a public-key
> encipherment (or, rather, a private-key encipherment) of the entire
> message. With a MAC, just the MAC needs to be enciphered to sign a
> long message.
Technically speaking, in that case, you don't use a MAC to preprocess the
message before signing it, you use a secure hash.
--
poncho
--
From: "david Hopkins" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: How to find a huge prime(1024 bit?)
Date: Thu, 01 Mar 2001 06:35:08 GMT
I find a easy way to find a huge prime in Java (see bottom). But I don't
know whether it is
secure enough.
public BigInteger(int bitLength,
int certainty,
Random rnd)
Constructs a randomly generated positive BigInteger that is probably prime,
with the specified bitLength.
Parameters:
bitLength - bitLength of the returned BigInteger.
certainty - a measure of the uncertainty that the caller is willing to
tolerate. The probability that the new BigInteger represents a prime number
will exceed (1 - 1/2certainty). The execution time of this constructor is
proportional to the value of this parameter.
rnd - source of random bits used to select candidates to be tested for
primality.
--
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Sad news, Dr. Claude Shannon died over the weekend.
Date: Wed, 28 Feb 2001 22:58:59 -0800
"Douglas A. Gwyn" wrote:
[...]
> Shannon in fact
> wrote an earlier version of his paper(s) for one of the wartime
> cryptologic agencies; it's in the US National Archives, and
> my own assessment is that he knew about decibans etc. and
> organized and systematized the ideas in formulating his theory
> of information.
That's why I hold Dr. Shannon's work in high esteem. In my opinion,
Claude Shannon is to information theory what Sir Isaac Newton is to
physics.
Newton's Laws of Motion and the Law of Gravity united the observations
of Galileo Galilei and the Three Laws of Planetary Motion of Johannes
Kepler with a logically consistent framework. Newton gave us our first
working model of force and gravity for engineering purposes.
Shannon's Mathematical Theory of Communication united the results of Dr.
Harry Nyquist (the Nyquist Sampling Theorem) and R. V. L. Hartley (the
concept of efficient encoding of messages with respect to their
information given by H = n log s, n = number of selected symbols and s =
number of possible symbols) in a logically consistent framework.
Shannon gave us our first working model of communications that (1)
related the information measure H to the probability of the symbol's
occurrence and (2) showed the existence of coding schemes maximizing
transmission bit rates through noiseless and noisy communications
channel. Shannon went on to apply the communications model to
cryptanalysis and cryptography - what a wonderful way to validate
aspects of the model!
John A. Malley
[EMAIL PROTECTED]
--
Subject: Re: Again on key expansion.
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Thu, 01 Mar 2001 06:33:42 GMT
"Cristiano" <[EMAIL PROTECTED]> writes:
> This sound a little strange in the world of cryptography, where averything
> is possible :-)
If only :-)
> I
Cryptography-Digest Digest #769
Cryptography-Digest Digest #769, Volume #12 Mon, 25 Sep 00 12:13:01 EDT
Contents:
Re: What am I missing? (Sagie)
Re: What am I missing? (Sagie)
Re: What make a cipher resistent to Differential Cryptanalysis? (SCOTT19U.ZIP_GUY)
Re: Question on biases in random-numbers & decompression (Bruno Wolff III)
Re: Why is TwoFish better than Blowfish? (Runu Knips)
Re: Encrypted File Systems..? (Gisle =?iso-8859-1?Q?S=E6lensminde?=)
Re: Tying Up Loose Ends - Correction (SCOTT19U.ZIP_GUY)
Re: Question on biases in random numbers & decompression (SCOTT19U.ZIP_GUY)
Re: Why is TwoFish better than Blowfish? (SCOTT19U.ZIP_GUY)
Re: Question on biases in random-numbers & decompression ("Trevor L. Jackson, III")
From: Sagie <[EMAIL PROTECTED]>
Subject: Re: What am I missing?
Date: Mon, 25 Sep 2000 14:13:50 GMT
> Try starting w/ the following excellent resources:
>
> http://www.cl.cam.ac.uk/~fapp2/steganography/
> http://www.isse.gmu.edu/~njohnson/
Okay, I'll give it a shot sometime, thanks.
> It would be unbelievable if they didn't. If you'd like, I
> can submit a compressed-then-decompressed audio track to one
> of their oracles, but I'm almost absolutely certain that
> all the proposed schemes do survive MP3.
You are being hypothetical again. It is obvious that they want it to
survive MP3, but the fact is that you have not tested it on either of
the technologies. Surviving MP3 compression is actually rather vague,
because I have no doubt it depends on the target MP3 parameters (stereo
mode, bitrate, encoder quality, sample rate, etc).
> >First of all, you don't know (well not for sure) what techniques are
> >being used by any of these watermark technologies. Secondly, I think
> >you are being short-sighted. Psycho-acoustic models are constantly
> >being improved.
>
> That doesn't matter. There are some operations that SHOULD
> NOT be undone by a compressor, even if they COULD.
The only modifications that should not be performed by a compressor are
such that are audible by the human ear.
> Here's a stupid example: take an audio clip (we'll call it
> clip B) and do a little multirate on it to shift all the
> frequencies up one half step (we'll call this version clip C.)
> Now sic some amazing compression algorithm on both clips B and
C.
> Is there any chance the compressor could undo that half-step
shift?
>
> Of course not: given clip C, there is no way a compressor could
> know whether C is a deformation of B, or if C was really
recorded
> that way, the musicians actually playing in a key a half step
up.
> Any compression scheme that compresses B and C to the same
thing is
> a broken compression scheme!
>
> It's a stupid example, of course, because shifting the
frequencies
> up a half-step is very unreasonable modification. Notice,
however,
> that without the original clip B for reference, most people
wouldn't
> notice anything "wrong" with clip C: only those musically
inclined,
> who may know the song is usually in the key of B.
>
> See?
As you said, it is a stupid example because the change can be detected
by the human ear. Even if some people normally would not detect it,
others would, and in general it means (as I said in a previous post)
that we are getting fucked up because the watermark screws the audio.
Audio technicians are working their ass off to create a final mix with
a pleasant sound and best EQ settings, and then some asshole comes and
fucks up the whole equalization.
> There's this set of operations that are considerably more
subtle,
> which would turn a clip A into a clip B such that A and B
> _should not_ be compressed to the same file. By "subtle" I mean
> such that one can listen to A and B one at a time and not tell
> how they are different. Maybe playing both at once one can hear
> the difference, but since only B will be distributed that
doesn't
> matter.
If the changes are so sublte and undetectable by the human ear you can
count on it that compression methods will use those tricks for the
compression process (if they create a more effective representation of
the signal, obviously) or remove these changes as part of the
optimization. Any watermarking technique that will use those tricks
will therefore be harmed. MP3 compression already replaces some
frequencies with others that sound the same, removes sounds that are
being obstructed by other sounds, and more. Who knows what techniques
will be used next?
> Really, t
Cryptography-Digest Digest #769
Cryptography-Digest Digest #769, Volume #11 Sun, 14 May 00 08:13:01 EDT
Contents:
Re: Crypto Export ("Stou Sandalski")
Re: UK issue; How to determine if a file contains encrypted data?
([EMAIL PROTECTED])
Re: S-BOX Construction Tutorial? (Terry Ritter)
Re: Destructive crypting ([EMAIL PROTECTED])
CipherText optimized for Page Tag Encryption. ("C. Prichard")
CipherText Optimized ("C. Prichard")
Re: Theoretical question (Mok-Kong Shen)
Re: On higher level Feistel schemes (Mok-Kong Shen)
Re: S-BOX Construction Tutorial? (Mok-Kong Shen)
Re: Destructive crypting (Daniel =?iso-8859-1?Q?=C5kerud?=)
Re: Destructive crypting (Daniel =?iso-8859-1?Q?=C5kerud?=)
Re: Destructive crypting (Daniel =?iso-8859-1?Q?=C5kerud?=)
Re: security (David Formosa (aka ? the Platypus))
Encryption of graphics by transposition (John Bailey)
From: "Stou Sandalski"
Subject: Re: Crypto Export
Date: Sat, 13 May 2000 22:00:45 -0700
Hey people thanx for the information, I am writing my paper now and its due
monday hehe, my idiotic ISP's news server was down all week so I couldn't
read this stuff (I am not down with deja)... but then again they run like NT
so how can I blame them... their MFM drives proly ran out of room or
something...
anyway thanks again
Stou
--
From: [EMAIL PROTECTED]
Subject: Re: UK issue; How to determine if a file contains encrypted data?
Date: Sun, 14 May 2000 05:12:32 GMT
On Sun, 14 May 2000 02:26:24 GMT, zapzing <[EMAIL PROTECTED]> wrote:
>>
>> The critical challenge to the UK law will not be using stenography to
>> hide the cipher text, but rather devising encryption apps that give no
>> appearance of being an encryption app.
>>
>> So who is going to be the first person to devise an encryption app
>> that is itself completely hidden and undetectable?
>>
>>
>But you could have a perfectly good reason
>for having that encryption app around
>Perhaps you actually do use encryption to
>send email to friends. Some files might just
>use a different key that you deny the
>existence of, that's all.
>You would give the police the key to your
>emails that you send to your "cover" friends.
>the other files, you say 'Gosh, I don't
>really know what that is".
Yes, I was supposing that most apps have a keyring which would give
away the existence of the other keys. So perhaps one doesn't need to
hide the app, but one does need the capacity to hide the existence of
keys.
Beyond the UK, in countries where the simple possession of an
encryption app might result in incarceration or even torture without
trial, I suspect an app that is itself hidden would be a decided
advantage. Especially since with the growing complexity of OSs, use
of caches, registry keys, etc etc, it is getting beyond the capacity
of all but the most sophisticated users to hide or remove all traces
of an app. and its use.
In such a situation, I suspect I'd use PGP loaded to a virtual drive
from a floppy on a DOS only machine, making sure the disk was removed
and physically hidden and secure when not in use.
>--
>Do as thou thinkest best.
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
--
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: S-BOX Construction Tutorial?
Date: Sun, 14 May 2000 05:26:39 GMT
On Sat, 13 May 2000 14:49:10 -0700, in
<8fjm8v$nqr$[EMAIL PROTECTED]>, in sci.crypt "Simon Johnson"
<[EMAIL PROTECTED]> wrote:
>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.
"S-boxes" are used in different ways in different ciphers, making
different things more or less important. Any particular construction
approach probably will be oriented toward a particular design, and the
approach you need should be oriented toward your particular needs.
Typically, a modern S-box has an even binary power number of elements
(e.g., 2**4 or 16, 2**8 or 256, etc.). There is one element of each
possible value and these are permuted or shuffled. Up to this point,
all we need to know is how to count and how to shuffle.
Some designs use "small" (e.g., "4-bit") S-boxes, but such small boxes
are often weak, and so should be tested before being used. There are
various tests including diffusion, Boolean function nonlinearity,
etc., with at least one new test found for every new attack on S-box
structure. An alternative is to use "large" ("8-bit" or larger)
S-boxes, but that is a cipher design decision.
DES-style ciphers often have a fixed set of boxes; that means
opponents will know the complete struct
Cryptography-Digest Digest #769
Cryptography-Digest Digest #769, Volume #10 Sun, 19 Dec 99 20:13:01 EST
Contents:
Re: Attacks on a PKI (Timothy M. Metzinger)
Re: compression & encryption (Jerry Coffin)
Commercial Cryptanalysis. (Glenn Larsson)
Re: dictionary attack (JPeschel)
Re: US Patent Office: How Stupid? Look Here... (Anthony Stephen Szopa)
Re: compression & encryption ("Matt")
Re: DES key safety (Peter Pearson)
S-Box evolution (Glenn Larsson)
Re: dictionary attack ("Michael Velten")
Re: compression & encryption (Guy Macon)
Re: S-Box evolution (Pelle Evensen)
Re: dictionary attack (Guy Macon)
Re: S-Box evolution (lordcow77)
Re: Commercial Cryptanalysis. (Jim Gillogly)
Re: DES key safety (CLSV)
From: [EMAIL PROTECTED] (Timothy M. Metzinger)
Subject: Re: Attacks on a PKI
Date: 19 Dec 1999 20:09:46 GMT
In article <83grhk$623$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Peter Gutmann) writes:
>That is, without e-commerce as an excuse, PKI vendors will have great
>difficulty in selling their wares to users because there's so little
>demonstrable need for them
Huh?
We look forward to PKI for lots of reasons that have nothing to do with
e-commerce. Just the ability to do away with lots of paper (that we had to keep
with wet signatures) is useful.
Of course PKI can be valuable for strong authentication of individuals too.
Timothy Metzinger
Private Pilot - ASEL - IA AOPA Project Pilot Mentor
DOD # 1854 '82 Virago 750 - "Siobhan"
Cessnas, Tampicos, Tobagos, and Trinidads at FDK
--
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: compression & encryption
Date: Sun, 19 Dec 1999 13:44:02 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> 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.
For this to make any sense at all, you have to start by showing a way
to decrypt the first two bytes of the file, independent of the rest of
the first block. If you can't, your argument is nonsense. If you
can, you've shown that the block cipher is SO weak that it makes
absolutely, positively NO difference what sort of compression or
anything else is in use: if you can treat two bytes separately from
the rest, it's _trivial_ to create a 65536 entry dictionary, and do a
simple lookup to break the cipher in a matter of nanoseconds with even
a relatively out of date computer.
Now if, OTOH, we have something vaguely similar to a decent block
cipher where we have to decrypt the entire first block to get anything
at all, what difference is there? Well, if the first two bytes are
fixed, we can (obviously) determine whether we have a good key by
decrypting only one block. For the moment, let's assume that your
version with no header gives _around_ a 50% compression ratio on
normal text, so a 256-bit block holds and average of 64 characters of
text. For our first attempt at saying whether a decryption is good,
we'll use the incredibly simple criteria that it hold only legal ASCII
characters -- I.e. that the high bit not be set in any byte.
The question is how often we'll accidentally decrypt a block with an
output having no high bits set. The chances of it being set in a
particular byte should be roughly 50%. The chances of accidentally
doing that 64 times in a row are .5^64, or about one in 2^64
(18446744073709551616 according to my calculator).
IOW, with a fixed header, we never have to decrypt a second block to
decide whether a key is good. If we don't have a fixed header, we
expect to decrypt a second block for one out of ever 2^64 blocks we
try. To use your example, that means there's about a 50% chance that
we'd decrypt ONE extra block in searching a 64-bit keyspace (of
course, a cipher with a 64-bit key and a 256-bit block doesn't make a
lot of sense, but we've GOT to restrict the keyspace to something
fairly small or your idea of doing a brute-force search at all simply
becomes too ridiculous to contemplate at all).
I won't work through all the math, but to even get CLOSE to your
65536:1 ratio in speed, we'd have to assume that we nearly always have
to decrypt several blocks of the message before we can guess whether
the content looks reasonable. From what I've seen, that's simply not
realistic at all -- quite the contrary, my expectation would be that
in many cases we'll be able to accept or reject a trial decryption
within the first few of bytes in either case. Yes, you're going to
decrypt a few extra blocks without known plaintext, but you need VERY
low criteria f
Cryptography-Digest Digest #769
Cryptography-Digest Digest #769, Volume #9 Fri, 25 Jun 99 09:13:05 EDT Contents: Cryptography FAQ (03/10: Basic Cryptology) ([EMAIL PROTECTED]) Cryptography FAQ (04/10: Mathematical Cryptology) ([EMAIL PROTECTED]) From: [EMAIL PROTECTED] Crossposted-To: talk.politics.crypto,sci.answers,news.answers,talk.answers Subject: Cryptography FAQ (03/10: Basic Cryptology) Date: 25 Jun 1999 13:03:33 GMT Reply-To: [EMAIL PROTECTED] Archive-name: cryptography-faq/part03 Last-modified: 93/10/10 This is the third of ten parts of the sci.crypt FAQ. The parts are mostly independent, but you should read the first part before the rest. We don't have the time to send out missing parts by mail, so don't ask. Notes such as ``[KAH67]'' refer to the reference list in the last part. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, sci.answers, and news.answers every 21 days. Contents: 3.1. What is cryptology? Cryptography? Plaintext? Ciphertext? Encryption? Key? 3.2. What references can I start with to learn cryptology? 3.3. How does one go about cryptanalysis? 3.4. What is a brute-force search and what is its cryptographic relevance? 3.5. What are some properties satisfied by every strong cryptosystem? 3.6. If a cryptosystem is theoretically unbreakable, then is it guaranteed analysis-proof in practice? 3.7. Why are many people still using cryptosystems that are relatively easy to break? 3.8. What are the basic types of cryptanalytic `attacks'? 3.1. What is cryptology? Cryptography? Plaintext? Ciphertext? Encryption? Key? The story begins: When Julius Caesar sent messages to his trusted acquaintances, he didn't trust the messengers. So he replaced every A by a D, every B by a E, and so on through the alphabet. Only someone who knew the ``shift by 3'' rule could decipher his messages. A cryptosystem or cipher system is a method of disguising messages so that only certain people can see through the disguise. Cryptography is the art of creating and using cryptosystems. Cryptanalysis is the art of breaking cryptosystems---seeing through the disguise even when you're not supposed to be able to. Cryptology is the study of both cryptography and cryptanalysis. The original message is called a plaintext. The disguised message is called a ciphertext. Encryption means any procedure to convert plaintext into ciphertext. Decryption means any procedure to convert ciphertext into plaintext. A cryptosystem is usually a whole collection of algorithms. The algorithms are labelled; the labels are called keys. For instance, Caesar probably used ``shift by n'' encryption for several different values of n. It's natural to say that n is the key here. The people who are supposed to be able to see through the disguise are called recipients. Other people are enemies, opponents, interlopers, eavesdroppers, or third parties. 3.2. What references can I start with to learn cryptology? For an introduction to technical matter, the survey articles given in part 10 are the best place to begin as they are, in general, concise, authored by competent people, and well written. However, these articles are mostly concerned with cryptology as it has developed in the last 50 years or so, and are more abstract and mathematical than historical. The Codebreakers by Kahn [KAH67] is encyclopedic in its history and technical detail of cryptology up to the mid-60's. Introductory cryptanalysis can be learned from Gaines [GAI44] or Sinkov [SIN66]. This is recommended especially for people who want to devise their own encryption algorithms since it is a common mistake to try to make a system before knowing how to break one. The selection of an algorithm for the DES drew the attention of many public researchers to problems in cryptology. Consequently several textbooks and books to serve as texts have appeared. The book of Denning [DEN82] gives a good introduction to a broad range of security including encryption algorithms, database security, access control, and formal models of security. Similar comments apply to the books of Price & Davies [PRI84] and Pfleeger [PFL89]. The books of Konheim [KON81] and Meyer & Matyas [MEY82] are quite technical books. Both Konheim and Meyer were directly involved in the development of DES, and both books give a thorough analysis of DES. Konheim's book is quite mathematical, with detailed analyses of many classical cryptosystems. Meyer and Matyas concentrate on modern cryptographic methods, especially pertaining to key management and the integration of security facilities into computer systems and networ
