Cryptography-Digest Digest #348, Volume #11 Thu, 16 Mar 00 15:13:01 EST
Contents:
Re: Cipher Contest ("Adam Durana")
Re: EOF in cipher??? (Jerry Coffin)
Re: brute force attack on a 128 bit SSL key? (Jerry Coffin)
Re: Q: Coding of music notes ("Joseph Ashwood")
Re: Novice questions (Jerry Coffin)
Re: Blind recipient hiding with RSA (David Hopwood)
Re: SALT with RC4, where do I store the SALT? ("Joseph Ashwood")
Re: SALT with RC4, where do I store the SALT? (Johnny Bravo)
Re: how to introduce hs students to cryptography (Bob Silverman)
Re: Q: Coding of music notes (Stephen Houchen)
Re: streaming cyphoidians (No Brainer)
Re: Really Interested, Where do I look for ... (jack)
Re: Really Interested, Where do I look for ... (jack)
Re: how to encrypt (Withheld)
Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is trying to
silence our program? It's not working...) (Withheld)
Re: [Tabloid Humor] Greatest threat ever to computer security (Withheld)
----------------------------------------------------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Cipher Contest
Date: Thu, 16 Mar 2000 13:12:47 -0500
> I'd prefer a continual contest, every time a new analysis is
> completed the ordering is reconsidered. On first
> introduction the placement would have to be done based on
> intuition, because only a minor amount of analysis will
> likely have been performed. It's a fairly simple matter to
> create a cipher that can withstand 6 weeks of analysis (~240
> hours), and is still weak. In fact history is littered with
> such ciphers. Just start the contest, revise the rules as
> needed (for example if your key space is larger than the
> factorial of the block space your cipher is eliminated).
>
> Oh and 64/128/128 is fine with me.
> Joe
I like the idea of a continual contest. Maybe we could have no submission
deadline and just add ciphers to the "contest" as people submit them. And
once an attack was discovered on a cipher it would be removed from the
contest and the author could have the option to revise the cipher to fix
whatever attacks were found. We could have ciphers ranked by how long they
have been in the contest without being broken. If we did it this way I see
no reason why entries in any category could not have different block sizes
since the ranking would be decided totally by the security of the cipher.
Would we even need categories then? The only problem I see is when the
better ciphers find their way to the top and stay there for a long time
people will become discouraged and loose interest. Maybe we could retire a
cipher after it has spent X weeks at the top of the list.
- Adam
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Thu, 16 Mar 2000 11:14:03 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> But programs that strictly
> conform to the 1989 standard nearly all strictly conform to the
> 1999 standard as well.)
Almost undoubtedly. Unfortunately, "strictly conforming programs"
and "useful programs" are pretty much disjoint subsets, so this
doesn't really mean much. I suppose this isn't really the place to
rehash that subject though...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: brute force attack on a 128 bit SSL key?
Date: Thu, 16 Mar 2000 11:21:27 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Jerry Coffin <[EMAIL PROTECTED]> wrote:
>
> [time to break a 128-bit symmetric cipher by brute force]
[ ... ]
> : A practical attack
> : absolutely _requires_ that you find some method that reduces the
> : search by quite a large factor.
>
> Surely not "absolutely requires" - a "molecular oracle" may yet be
> discovered that answers your every question instantly...
Hmm...and you're of the opinion that being told the answer wouldn't
reduce the searching you have to do by a large factor? It seems to
me that a reduction from 2**128 items to one item is indeed a VERY
large factor...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Q: Coding of music notes
Date: Thu, 16 Mar 2000 10:23:41 -0000
> How do you distinguish a C# from a Db?
Find the best match for the key
> How do you put slurs in?
by changing the pitch with starting a new note
> How do you mark staccatos?
the notes are identified by their length, not by
quarter/half/eighth/etc, so staccato is simply an 80% length
Joe
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Novice questions
Date: Thu, 16 Mar 2000 11:26:00 -0700
In article <8ap9mr$hh2$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Hello,
>
> I have created a simple encryption program and would like to know if
> its "allowable" to post the source for people to review and comment.
Generally speaking, what you'd want to post here would be
descriptions of your algorithm and/or protocols, and something like
the URL of a place to get the source code.
Of course, that's somewhat flexible: if (for example) you were using
something like RC4, where the source code to the algorithm might fit
into a dozen lines or so, it's probably reasonable to post at least
that bit of the source code so, for example, somebody else can verify
that it implements the algorithm properly.
OTOH, posting hundreds or thousands of lines of code, much of it
devoted to a user interface, opening files, etc., probably wouldn't
be particularly appropriate...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
Date: Thu, 16 Mar 2000 18:12:38 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Blind recipient hiding with RSA
=====BEGIN PGP SIGNED MESSAGE=====
David A Molnar wrote:
> David Hopwood <[EMAIL PROTECTED]> wrote:
> > - low exponent attacks may apply. Normally this would not be a problem
> > when using OAEP padding, but for this scheme the most significant
> > third of the bits of the input block (compared to the size of n')
> > must be zero. I'm not sure how the low exponent attacks on RSA
> > generalise to moduli with three factors, but it would be prudent to
> > use e >= 65537;
>
> It seems worse than that - now there is a special form for correct
> decryptions. This is the problem that allowed Bleichenbacher to
> break PKCS 1.5.
That attack doesn't work in this case, because the recipient will only
retrieve the plaintext mod n, and all values on [0, 2^(bitlength(n)-1))
are possible. Also, even if that wasn't the case, the definition of OAEP
unpadding requires that decryptions outside this range result in an
"invalid" output, which can't be distinguished from the output due to
any other incorrectly padded decryption.
However, it's fairly academic, because of the attack that allows linking
two blinded public keys by taking the gcd of their moduli (see my other
post).
> An RSA approach was the first thing I thought of, but I couldn't make it
> work.
Given the gcd attack, I also can't think of any way to make this work for
RSA. However, I've made some progress on security proofs for BRH-DHAES,
and I'll post the results here when they're finished.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBONEj6jkCAxeYt5gVAQGHUQf/Qita98KnPhbY8EUqzLZbZMSVXJJqiHow
vIyB+6leDZLET86uqTp+1/JDdJXBiToJH2tWG6S00pBnXflRj3u9Hpz+rcVn2pj4
Glw/bO3sM+xLP74IznNjDY0HJutSIl3jzT0rijUQiDS++LXXe7GBx/GdxMpYSi+q
JryT26gT6aGsyD7l0tVfFab5QYUBvpNH1nmM7fzeTvUpcLWw78jaaiZPZ9Sj98Y2
IM6yGn9qW1dfQsH0LpqMkVTfBVj4LqbBuKeD1vfSx4rrEf2sG6VVrhLxUvj+rldK
3hhvJDP1iYOim6UHVbs07h6U9kQZ2ppzQsBl9fgEvC/OjQERwMjHHg==
=CM0G
=====END PGP SIGNATURE=====
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: SALT with RC4, where do I store the SALT?
Date: Thu, 16 Mar 2000 10:34:41 -0000
> Thanks again Joe. Could I bug you for one more thing?
Below is part of
Don't worry, I'll tell you if you "bug" me too much.
> 1) Is there an advantage to having more characters in the
salt? Can I
> have a 40 character salt for example?
With RC4 there _may_ be an inherent advantage to having a
longer salt, but it's likely to be trivial at best. The only
well understood reason for having a longer salt is to avoid
collisions between 2 messages. With RC4 this is of quite
high importance, since if someone has 2 messages encrypted
with the same key, the messages can be attacked as a
vigenere cipher (some details on the attacks are in the
FAQ). With each message having a different salt, the amount
of information that can be gleaned decreases very sharply.
In order to eliminate the attackable data more easily you
may want to pull a few hundred initial bytes out before
performing the encryption, 512 is a common (and fairly good)
number.
>
> 2) Is there a reason the person who wrote the code above
limited it to
> A-Z characters only? I see no reason to limit the salt
this way...
> Can't I just use all available ASCII characters? Perhaps
there is no
> real advantage to doing that, and that is why it was
written that way?
I can't vouch for the original author, but if the salt is
prepended to the key, it eliminates an attack on the first
byte of the ciphertext.
> Thanks again Joe... I wish I had more of a talent for math
(it was
> always my worst subject)
Most of us here wish we had more of a talent for math, and
I'm definitely in that category (and planning on learning
more).
Joe
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: SALT with RC4, where do I store the SALT?
Date: Thu, 16 Mar 2000 14:02:17 -0500
On Thu, 16 Mar 2000 10:34:41 -0000, "Joseph Ashwood"
<[EMAIL PROTECTED]> wrote:
>I can't vouch for the original author, but if the salt is
>prepended to the key, it eliminates an attack on the first
>byte of the ciphertext.
Slight correction, appended to the key. Putting the salt in front of
the key before mixing is not a good thing. (key[0]+key[1]MOD 256) = 0
causes the first plain text byte to leak. If the passphrase is normal
ASCII that you can type, this condition will never be met unless you put
the IV in front, then key[0] and key[1] will be random, and 1 in 256
messages will leak a byte.
This is the reason that using MD5 or SHA-1 to hash the key with the salt
before use can leak a byte. RC4 is strong enough as it is, with just the
salt and 10 byte IV appended to the key. But for those who insist on
using MD5 or SHA-1, generate a discard byte before you encrypt. Using MD5
or SHA-1 adds minimal extra security, it just requires an extra step by
the attacker to check pass phrases.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: how to introduce hs students to cryptography
Date: Thu, 16 Mar 2000 19:11:36 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Doug Stell) wrote:
> On 15 Mar 2000 10:31:09 -0800, Andru Luvisi <[EMAIL PROTECTED]>
> wrote:
<snip>
> >That all depends on the "youngster". Although this is fine for most
> >students, *requiring* that all students follow your
> >works-for-most-people speed and level will still frustrate the slow
> >ones and frequently bore the bright kid in the front row and turn him
> >into an underachiever.
>
> Any teacher knows that you will always frustrate the slow ones and
> bore the bright ones, especially if the class has a heterogeneous
> background. The key is to find the right balance and an approach that
> is best for the middle majority
No. They key is to segregate students by *ability* and not to place
honor students in the same class with students who struggle to
achieve a C. [Yes, I know. This is politically non-correct and
elitist. But one of the reasons U.S. education is doing a lousy job
(IMO) is that it is trying to be too egalitarian. Stop trying to teach
everything to everyone. ]
Another key is to *enforce* pre-requisites. A pre-requisite for
teaching crypto to high school students should be that they are
all honors math students with at least two years of high school
algebra (or even 1 year for the best students). Teaching the elementary
number theory needed for crypto should not be difficult for this set
of students.
>and not too bad for the students at
> either extreme. This is true for almost every subject and crypto is
> worse than most in this respect.
>
> I do know for certain that if you teach lots of number theory to even
> professional level people after lunch, all but one in the class will
> sound asleep.
This sounds like an attitude problem. Professionals who have degrees
in C.S. or other technical field are (or should be) capable of
learning the material. If they "fall asleep" it is because of bad
attitudes. The teacher should be saying
" Guess what? Part of becoming a mature adult is recognizing that
not everything is fun to all people. Nevertheless, mature adults should
be capable of learning material which doesn't really interest them,
especially if it relates directly to their job. This is part of what
being a professional is all about. "
If the material really is important to their work then the incentive
to learn it should come from their management. A true professional
would derive the incentive from his/her own work ethic, but I've
given up hope that most people have this ethic.
>(I'm only the course facilitator for this module.) After
> talking that presenter into reorganizing his material to a) always
> make the number theory applicable to a purpose and algorithym and b)
> feed them the math in small chunks, only half the class was asleep.
My personal opinion is that these people need a kick from management.
Those that still fall asleep should perhaps be encouraged to seek
employment elsewhere.
> BTW, I get written critiques from each student on each module of a
> 40-hour course and the public key module typically has 34 people who
> hate the presentation and slept versus 1 person who loved it and
> wanted more.
Perhaps we should question why computer people hate this material?
And if they truly hate it, then why are they taking the course? If it
is because the knowledge is needed for their job, then they truly do
have a bad attitude.
>
> Another major point has to do with teaching style. Some teachers and
> students want a high information transfer efficiency. Others want to
> have fun and do lots of exercises. Although I am in the first
> category, I find that most students, even professionals, now want the
> fun & games, touchie-feelie type of course. I suspect that this is
> even more true for kids. Material must be hightly interesting and
> captivating.
Not all material is going to be fun. Expecting it to be is wishful
thinking. Sometimes one has to suck in the gut and learn stuff
that isn't fun or iteresting simply because the job or a professional
work ethic requires it. Sometimes one must get self-motivated to
learn stuff that is *difficult*. This is part of being an adult and
a professional.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Stephen Houchen <[EMAIL PROTECTED]>
Subject: Re: Q: Coding of music notes
Date: Thu, 16 Mar 2000 13:19:14 -0600
> > How do you distinguish a C# from a Db?
>
> Find the best match for the key
That applies fine (maybe) if you already know what the
key is. But how do you assign the key in the first place?
It would very hard (if not impossible) for the machine to
pick 5 flats vs. 7 sharps. And they're not
interchangeable!
S
[EMAIL PROTECTED]
------------------------------
From: No Brainer <[EMAIL PROTECTED]>
Subject: Re: streaming cyphoidians
Date: Fri, 17 Mar 2000 03:12:38 +0800
David,
Thanks for the reply...I now know where I'm going :)
On Tue, 14 Mar 2000 23:36:25, David Hopwood <[EMAIL PROTECTED] wrote:
> No Brainer wrote:
> > I was wondering what is the best method to encrypt/decrypt/create a
> > message digest/sign data etc...if all you have is a small window to
> > encrypt/decrypt/digest and sign the data with?
> >
> > For example, if someone wanted to stream video to another person and the
> > receiver had to check the validity of the sender but could only receive
> > (and HAD to process in stream format) approx. 2k at a time, how would it
> > be best done? Remember that the receiver cannot receive the whole
> > message to check the sig?
>
> The standard way is to use sequence numbers: split the stream into packets,
> prepend or append a sequence number to each packet, and authenticate using
> a Message Authentication Code, e.g. HMAC, using a key independent of, but
> agreed in the same way as the encryption key. The size of a packet will
> depend on what latency is acceptable.
>
> The receiver should not act on the contents of a packet until it has been
> authenticated. If the transport preserves the order of transmissions then
> the sequence number need not actually be transmitted, but should still be
> included in the MAC'd data.
>
> > It there anything like this available?
> >
> > Is this a dumb question?
>
> No, it's not a dumb question - many people get this wrong because they
> believe that authenticating data on a per-packet basis is incompatible
> with applications that require streamed data. As a result, there are a
> lot of applications out there with inadequate authentication.
------------------------------
From: jack <[EMAIL PROTECTED]>
Subject: Re: Really Interested, Where do I look for ...
Date: Thu, 16 Mar 2000 19:41:47 GMT
Well thanks,
but it looks like i posted that message in haste.
I was looking for info on the web on specific things. I know the library
(can't check out books there) and book(money, why pay for something when
you don't have to?) stores. I'm going to go look for used Uni books. I
have 4 colleges in this county.
but his looks like a post i shouldn't have posted...
sorry for the waste of space....
I'll come back with specific questions....
-jack
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: jack <[EMAIL PROTECTED]>
Subject: Re: Really Interested, Where do I look for ...
Date: Thu, 16 Mar 2000 19:41:56 GMT
Well thanks,
but it looks like i posted that message in haste.
I was looking for info on the web on specific things. I know the library
(can't check out books there) and book(money, why pay for something when
you don't have to?) stores. I'm going to go look for used Uni books. I
have 4 colleges in this county.
but his looks like a post i shouldn't have posted...
sorry for the waste of space....
I'll come back with specific questions....
-jack
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Withheld <[EMAIL PROTECTED]>
Subject: Re: how to encrypt
Date: Wed, 15 Mar 2000 22:09:01 +0000
Reply-To: Withheld <[EMAIL PROTECTED]>
In article <[EMAIL PROTECTED]>, Runu Knips <runu.knips.NOSP
[EMAIL PROTECTED]> writes
>propersideshowbob wrote:
>> I studying C++ as my primary language. I would like to know if it is
>> possible to create a encrypting program using C++.
>> Is encrypting the main part of security software if not tell me of
>> other major factors. To get on with encrypting , how would I go about
>> designing an encryption program would I change letters to number or
>> jumble things up or confuse the commands of thre program. I ask this
>> because I want to learn more and see how well I can do but i want to
>> encrypt using the most modern goalsof encryption. Please help me.
>
>Why don't you just read a good book about cryptography first ?
>And yes, C++ is perfect for writing crypto.
Try Bruce Schneier's Book - "Applied Cryptography" which includes
algorithms in C. There is also a book you can buy (I forget the title
but you'll know it when you see it) which tells you how to implement
Blowfish in C.
Basically you can use just about any language for encryption. I once
wrote a simple cipher in Excel... (it might not keep the FBI out for
long but it served its purpose)
--
Return address removed for anti-spam purposes.
Email replies to news at maelstrom dot demon dot co dot uk
Email replies to this address may be copied to relevant newsgroups
------------------------------
From: Withheld <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security.pgp
Subject: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is
trying to silence our program? It's not working...)
Date: Wed, 15 Mar 2000 22:15:17 +0000
Reply-To: Withheld <[EMAIL PROTECTED]>
[cut]
>I fantasize that your data is stored on hard disk tracks for a long time
>before it gets wiped (esp. with new users of your still improving
>software). So the magnetic data will leak over to the surface area next
>to the track. Then you overwrite with zero's once! That leaves traces of
>the previous data next to the track. Above a certain treshold the data
>will have been 1 and below it will have been 0. Not very commercially
>intesting until your product apeared, but it doesn't sound difficult to
>recover IMO.
>
>Better would be to steal the random data collection from the source of
>pgp 6.5.1i or use Jarrow from counterpane to generate some
>cryptographically strong random data and use it to overwrite previous
>data on the harddisk. It doesn't have to be 10Gig strong for a 10Gig
>harddrive, but hashing the initial random value a few times should do
>the job. At no loss of speed (maybe 0.01% due to the hashing) you now
>overwrite the previous data more securely than just by overwritting with
>zero's only. That would be great.
>
>Maybe the area close to the written track will still get magnetized by
>the previous data, but you can't just set a treshold. You'll have to set
>at least three treshold. One for going from 0->0 (very low magnetic
>treshold), 0->1 (higher), 1->0 (still higher depending on time of last
>wipe) and 1-1 (highest).
I hope I'm not being ignorant here, but is a stream of random data
entirely necessary? Given you are trying to mask residues from previous
data, wouldn't a succession of alternating patterns 101010101010...
followed by 0101010101... do the same thing - blur any residues until it
was meaningless. Using memory blocks you could define this pattern and
then dump it into disk blocks wherever you wanted. Once this pattern had
been followed a suitable number of times it could all be overwritten
with 00000000 to clear the disk.
Unless I've misunderstood the point, this would result in so many
possible thresholds for what was there before the multiple wipe passes
that it would be impossible to get anything meaningful from it at all?
[cut]
--
Return address removed for anti-spam purposes.
Email replies to news at maelstrom dot demon dot co dot uk
Email replies to this address may be copied to relevant newsgroups
------------------------------
From: Withheld <[EMAIL PROTECTED]>
Crossposted-To: alt.computer.security
Subject: Re: [Tabloid Humor] Greatest threat ever to computer security
Date: Wed, 15 Mar 2000 22:18:52 +0000
Reply-To: Withheld <[EMAIL PROTECTED]>
[cut]
> apart from that, my computer _is_ possessed by demons---lots of them!
>and they've got really evil-sounding names, like klogd, sshd, crond,
>inetd, lpd,... clearly some 2800 year-old mesopotamian dialect! the
>only fix for a demon-free system i'm aware of is described in the
>following link, which i'd recommend for further reading:
>
> http://www.geocities.com/ResearchTriangle/Node/4081/jesux.html
[cut]
To avoid being Daemon-possessed try using Windows NT where things are
done by "services". There's no guarantee they'll work, but at least you
will have laid the daemons to rest...
--
Return address removed for anti-spam purposes.
Email replies to news at maelstrom dot demon dot co dot uk
Email replies to this address may be copied to relevant newsgroups
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
