Cryptography-Digest Digest #473, Volume #9 Tue, 27 Apr 99 17:13:03 EDT
Contents:
Re: Thought question: why do public ciphers use only simple ops like (Anthony
Stephen Szopa)
128 bit DES ("dino")
Re: break this code (Mike Andrews)
break this code (Travis Hoover)
Cryptography FAQ (10/10: References) ([EMAIL PROTECTED])
Re: True Randomness & The Law Of Large Numbers (Jim Gillogly)
Re: Algorithms where encryption=decryption? (Piso Mojado)
Re: Paper on (in)security of passwords (mok-kong shen)
Re: Papers on RC4 key size (Paul Koning)
Re: How good is /dev/random... (Paul Koning)
Re: encrypted and AUTHENTICATED tunnels (Paul Koning)
Re: Question on exponent size for DH ("Michael Scott")
Re: choosing g in DH (Michael J. Fromberger)
Re: break this code (Jim Gillogly)
Re: Algorithms where encryption=decryption? ([EMAIL PROTECTED])
DES3 padding ([EMAIL PROTECTED])
Re: True Randomness & The Law Of Large Numbers (R. Knauer)
OAEP, CBC, patents, and improving PGP (John Savard)
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Thought question: why do public ciphers use only simple ops like
Date: Tue, 27 Apr 1999 08:15:02 -0700
Reply-To: [EMAIL PROTECTED]
wtshaw wrote:
> In article <7fnujg$2tj$[EMAIL PROTECTED]>, SCOTT19U.ZIP_GUY
> <[EMAIL PROTECTED]> wrote:
> >
> > Your feelings are correct except for one small point. The AES contest
> > is not about having secure encryption. The NSA would never allow a good
> > common method to be blessed by the government for general use.
> > So that is why you will never see a blessed super cipher method made
> > of completely different methods. Unless each method added information
> > at each pass so that they could be broken independitly.
> >
> We can expect that there are tactics and strategies on file for finding a
> way for the government to get itself out of the corner that it has painted
> itself into. Whether any of them will work or is going to be acceptable
> is up for grabs.
>
> As seen in many cases before, our government is adept at doing
> inconsistent things, even, alas, contradicting itself in statements of
> mission and policy. As in any level of organization, individual to
> government, the devil is in the details, that is which values are given
> more weight at the time. In time of war....well, we will see...rather not
> have to have any war that might be abused for ulterior motives aside from
> those well recognized.
> --
> Life's battles do not always go to the stronger of faster man...
> But, sooner or later always go to the fellow who thinks he can.
On the original topic: simplest is best.
If the original encryption method was secure to begin with what need is there
to combine it with anything?
I always opt for the simplest encryption method that provides excellent
security.
If I have to combine it with something else it isn't good enough for me to
begin with.
------------------------------
From: "dino" <[EMAIL PROTECTED]>
Subject: 128 bit DES
Date: 27 Apr 1999 14:46:09 GMT
Hi everyone.
Do you know some products implementing 128 bit DES?
Thank you
------------------------------
From: [EMAIL PROTECTED] (Mike Andrews)
Subject: Re: break this code
Date: 27 Apr 1999 15:48:47 GMT
Reply-To: [EMAIL PROTECTED]
Travis Hoover ([EMAIL PROTECTED]) wrote in article
<[EMAIL PROTECTED]>:
: I am a student at Purdue University, and as a course project, I
: created my own encryption/decryption program. I was wondering
: if anyone would be willing to help me out with a little research.
: The above passage is encrypted to the following:
: S&i{,q$}z}rq~x*g|.\'vn{m.a~m"kz#u&}6&i|p0e}&i.o!y|ym.|$stkk$80M*
: izsm&in&u),!{x&m|o$}zzq}z?hoiz)|&myt(~~!k|gu<,Y$#g{.%!rnkzwzw
: mp&i|'!ro&!}#|h*hm.%ypvovu,&s*nmz|0qo&w%"0{szp.m0psz|zq0voymo~sl8
: I would like any of you out there to try and break the following
: encrypted passage.
[snip snap snorum, high cockalorum]
: If you can break this passage, please let me know by 8:00 tonite
: (Tuesday), and tell me how you did it, how long it took, and what
: plaintext you got(because you might be wrong!) Thanks for your
: help. Please either respond to this newgroup or to
: [EMAIL PROTECTED]
That's not the way it's done here. If you're willing to post your
entire system (but not the keys) _and_ some ciphertext, then one
or more of us may have a go at it -- but generally not with a
deadline of one or two days.
One basic idea behind secure ciphers is that the attacker needs
both the system _and_ the keys to break the cipher. A measure of
the security of your system is how closely it approaches that
ideal.
You might want to look up the difference between "code" and
"cipher" .
--
Mike Andrews
[EMAIL PROTECTED] (when it works)
------------------------------
From: Travis Hoover <[EMAIL PROTECTED]>
Subject: break this code
Date: Tue, 27 Apr 1999 10:21:46 -0500
I am a student at Purdue University, and as a course project, I
created my own encryption/decryption program. I was wondering
if anyone would be willing to help me out with a little research.
The above passage is encrypted to the following:
S&i{,q$}z}rq~x*g|.\'vn{m.a~m"kz#u&}6&i|p0e}&i.o!y|ym.|$stkk$80M*
izsm&in&u),!{x&m|o$}zzq}z?hoiz)|&myt(~~!k|gu<,Y$#g{.%!rnkzwzw
mp&i|'!ro&!}#|h*hm.%ypvovu,&s*nmz|0qo&w%"0{szp.m0psz|zq0voymo~sl8
I would like any of you out there to try and break the following
encrypted passage.
Shq{kponwd^t`zhhpfa``x_nlkypb^zdp\`_lzmmnp_]zllyiswkcdd__w`lmm
pbZp{wjqxka`cdr_]z25)/}w$tfd_bwep|A{yx{|}z%xhj{rcax_ek_gz_q]j,
Od_w_i_noxZrbp\c_wkk|od_wbfl\hx^t^kys[lz46)1}x{{|Nkxrkr|bknwptm
bn[]a{j`r_eo{``hipzqf`z]e]pqy]p^n^e`zigzqf`z@bj^j)zx?korpj[maiw'
uinze__zbbce|`jince|n_ika{gizimdbpy]l^]p*yoiwulsyah]aa|pl
qbpe|\zl^]pmi]\eu{p`oj^_q_]h_wl^qneh`zdp\`_w$@''zcgoqc\`xhb
A|jnx?*{|DzbZ`{p`l_ZpbbguxZjkmpj]^`{giznaa{ag]mlzqf\pxfu{n\on
^tmcme_g_b|ndipo{rc]nwsecizCwi^b`z_ZniwyclZ`b|knica`rdkhlz^l_z
ma]ocypb^i{udpbwpecyonn`bloo&wpeciznaa{qoq^^jqqysbhzdcozzaedf`n
ak]acnzna]k|od_rzqfdjewpectz[ka{a\l[[hb|jbxbj{_y_bZhiciccgc{
ajqlla)~yd[oa{_yp_g`bl^uxmk{qgkqw`luiz[g`{aji_w`luiznhzqf`z
f^rbjypb^u{rcehdzqf`uxZnb|^]jZ^icyk`w)*|\zmhnq|jbxlaid(boebfjgeh`z
mpjlb^_v,
If you can break this passage, please let me know by 8:00 tonite
(Tuesday), and tell me how you did it, how long it took, and what
plaintext you got(because you might be wrong!) Thanks for your
help. Please either respond to this newgroup or to
[EMAIL PROTECTED]
travis
------------------------------
Subject: Cryptography FAQ (10/10: References)
From: [EMAIL PROTECTED]
Crossposted-To:
alt.gothic,uk.people.gothic,boulder.general,at.test,talk.politics.crypto,sci.answers,news.answers,talk.answers
Date: 27 Apr 1999 00:27:20 GMT
Reply-To: [EMAIL PROTECTED] (Henrietta K. Thomas)
Fuck You If You Aint Goth!!!
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Tue, 27 Apr 1999 09:05:50 -0700
R. Knauer wrote:
> On Tue, 27 Apr 1999 05:38:23 -0700, Jim Gillogly <[EMAIL PROTECTED]> wrote:
> >If I see extended plaintext (for some definition of
> >extended), I'll expect that it's either real plaintext or fake cover
> >traffic.
>
> OK, but which is it?
Depends on my traffic analysis. Every time I see plaintext on that
link I busily check to see whether it can be tested. The more things
that check out and that are valuable (i.e. costly to the enemy), the
more credibility I give the information that's apparently leaked. If
it's all either unverifiable or chicken feed, then I would give it
less credibility. But whichever it is, it's not going to be what you
suggested: an encrypted message that reads like plaintext but isn't
because you sneakily prepared a key that would make it read like
plaintext, knowing what you were going to send in advance, and sending
that key separately by a secure channel. That scenario simply doesn't
make sense.
--
Jim Gillogly
Sterday, 6 Thrimidge S.R. 1999, 16:01
12.19.6.2.11, 7 Chuen 19 Pop, Sixth Lord of Night
------------------------------
From: Piso Mojado <[EMAIL PROTECTED]>
Subject: Re: Algorithms where encryption=decryption?
Date: Tue, 27 Apr 1999 08:25:31 -1000
Anne Veling wrote:
>
> Hi everyone,
>
> I am looking for any algorithms that can be used in encryption in which
> the encryption algorithm is the same as the decryption algorithm.
>
> For instance:
>
> the well-known ROT-13 (a unary encryption algorithm (uses only one
> parameter))
>
> Or f(x)=-x
> Or f(x)=1/x (not so useful for encryption)
>
> Or binary:
>
> f(x,y)=x XOR y
>
> Do you know of any other?
>
> Thanks, bye,
>
> Anne.
Feistel cipher can be used this way when the round key is the same
in every round. For example, DES, the old Data Encryption
Standard can be modified so each 48 bit subkey in every round
is the same 48 bit key. Then encryption is done exactly like decryption.
There are many Feistel ciphers than can be set up this way. The main
advantage for a Feistel cipher is that the same hardware (or software)
can be used for decryption, which was used for encryption. DES
would normally reverse the key schedule for decryption.
------------------------------
From: mok-kong shen <[EMAIL PROTECTED]>
Subject: Re: Paper on (in)security of passwords
Date: Tue, 27 Apr 1999 13:27:04 +0200
Florian Erhard wrote:
>
> I'm looking for a evaluation of the security of password
> used in universities or companies. I rember I once read
I don't think you can get useful, universally valid, yet not fuzzy
results from publications. The staffs of one company may behave
quite differently from another, depending on diverse factors.
If you are a system administrator, the best is to run a so-called
password evaluator on your system and study the actual result.
M. K. Shen
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Papers on RC4 key size
Date: Tue, 27 Apr 1999 13:21:13 -0400
[EMAIL PROTECTED] wrote:
>
> Does anyone know of any papers that discuss the RC4 key-size? Any scientific
> account of relative strengths would be extremely usefull. Primary interest is
> the relative strengths of 40-bit and 128-bit keys, for SSL of course.
No deep analysis is needed here. A 40 bit key takes, worst case, 2^40
operations
in a brute force search. That's not a particularly big number.
Therefore,
ALL cryptosystems with 40 bits keys are useless.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: How good is /dev/random...
Date: Mon, 26 Apr 1999 11:14:55 -0400
xstpvmi wrote:
>
> On 23 Apr 1999 23:22:15 GMT, Stephen Robert Norris <[EMAIL PROTECTED]> wrote:
> > Has anyone done any analysis on how "good" the randomness from /dev/random
> > is in Linux?
Just saw this pointer:
http://www.openpgp.net/random/index.html
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: encrypted and AUTHENTICATED tunnels
Date: Mon, 26 Apr 1999 11:18:30 -0400
> Phil Howard wrote in message ...
> >Is there any free and unencumbered software that implements encrypted
> >and AUTHENTICATED tunnels? This would require an unshared authentication
> >key pair in each direction. Otherwise, a cracker with the tunnel code
> >and the opportunity to hijack the routing of one end of a VPN, could get
> >into a VPN easily and penetrate all those insecure applications that
> >assume they are running on a secured LAN.
> >
> >Unfortunately, it is rather pointless for me to try to implement such a
> >thing myself, given the country I live in.
> >
> >* strong encryption
> >* strong unshared authentication
> >* no patent encumberances
> >* GPL or similar licensing
Look here:
http://www.xs4all.nl/~freeswan/
By the way, living in the USA doesn't keep you from doing yourself
what you described. It does, of course, severely limit your ability
to ship your work out of the country.
paul
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: Question on exponent size for DH
Date: Tue, 27 Apr 1999 20:40:50 +0100
Ray <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I understand that you need to have a large prime for security in
> Diffie-Hellman. RSA recommends at least 768 bits.
>
> But what about the size of the exponent (i.e., the "secret private"
> value)? From what I read it must be shorter than the prime, but is there
> any reason for it to have a particular number of bits? Does making it
> significantly smaller than the prime have any security implication?
>
> In some timing test I ran with a 768 bit prime, an exponent of 568 bits
> was much faster than an exponent of 760 bits.
>
> Thanks.
Interesting question, and one that is not well answered by the available
text books.
When trying to keep the discrete logarithm attack infeasible, one must
protect against "attacks on the modulus" and "attacks on the exponent". To
simplify what follows assume that the modulus p is a safe prime.
The best "attacks on the modulus" are index calculus methods, if applicable
to the group. Famously index calculus methods do not apply to groups of
points on elliptic curves. Alternatively a "square root" attack
(Pollard-Rho/Pohlig-Hellman) is always possible, whose complexity is the
square root of the modulus.
The best "attack on the exponent" is the Pollard Lambda ("kangaroo")
algorithm. This is also a "square root" attack - its complexity is the
square root of the exponent.
Computationally "square root" attacks can be avoided by using numbers of 160
bits. It is currrently felt that 2^80 steps of the associated algorithm
would just take too long. However to avoid the far superior index calculus
methods, a modulus of 1024 bits would be required.
This explains the 1024/160 modulus/exponent size recomended for use by the
Digital Signature Algorithm. Using elliptic curves a much smaller 160/160
implementation is possible, as the index calculus method doesn't apply.
Anyway coming to Diffie-Hellman the same thing applies, and a 160-bit
exponent is fine for use with a 1024-bit modulus. Clearly its the same
discrete logarithm problem that lies at the heart of DH and the DSA.
For a detailed analysis see Oorschot & Wiener "On Diffie-Hellman key
agreement with short exponents" Eurocrypt '96.
But pity the implementor, for whom this is an important efficiency issue.
The text books are most unhelpful on the matter (the Pollard Lambda
algotithm is rarely mentioned). The otherwise excellent Handbook of Applied
Cryptography is quite misleading. It states (p. 537) that "..Oorschot and
Wiener note that use of "short" private exponents in conjunction with a
random prime modulus p (e.g. 256 bit exponents with 1024 bit p) makes
computation of discrete logarithms easy", which would make you think that
short exponents were a very bad idea. But the important word there is
"random". The main thrust of the paper is that short exponents are perfectly
safe if the parameters are chosen with care (and van Oorschot is himself one
of the authors of HAC!!).
Mike Scott
------------------------------
From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: choosing g in DH
Date: 27 Apr 1999 18:14:39 GMT
In <[EMAIL PROTECTED]> Medical Electronics Lab
<[EMAIL PROTECTED]> writes:
>
>I strongly advise a trip to the library. Number theory is a ton of
>fun!
>
I will definitely second that. There are some wonderful, beautiful
truths lurking quietly beneath the arithmetic we use every day.
Number theory takes some patience, but it will well reward your
efforts to learn it!
Cheers,
-M
--
Michael J. Fromberger Software Engineer, Thayer School of Engineering
sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
M4txC+TccxcnDXXeP9H3bAsgg9uJHjD7omOwTuo8Fa241tAF9uZ7vHZvenUXHkxRJ/BZzx6j
Remove clothing if you wish to reply to this message via e-mail.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: break this code
Date: Tue, 27 Apr 1999 12:47:23 -0700
Travis Hoover wrote:
> I am a student at Purdue University, and as a course project, I
> created my own encryption/decryption program. I was wondering
> if anyone would be willing to help me out with a little research.
Now, that's a naughty thing to say, under the circumstances.
> I would like any of you out there to try and break the following
> encrypted passage.
>
> Shq{kponwd^t`zhhpfa``x_nlkypb^zdp\`_lzmmnp_]zllyiswkcdd__w`lmm
> pbZp{wjqxka`cdr_]z25)/}w$tfd_bwep|A{yx{|}z%xhj{rcax_ek_gz_q]j,
...
> If you can break this passage, please let me know by 8:00 tonite
> (Tuesday), and tell me how you did it, how long it took, and what
> plaintext you got(because you might be wrong!)
It didn't take long. It's a polyalphabetic, and I broke it by
detecting the period using the index of coincidence on each
assumed column, then finding the most frequent characters in each
column, which are almost always spaces in a problem like this.
After that it was fill-in-the-blanks and symmetry of position,
using the pt and ct alphabet derived from the first passage.
However, I won't tell you the exact plaintext. I assume you got
a copy of the program used to encipher it, since the first passage
was enciphered with the same general system but a different key.
The message is specifically directed to you from your professor.
Sorry to hear you did poorly on your final (it's posted on the
professor's office door), but it's nice that your other grades
made up for it to some extent.
--
Jim Gillogly
Sterday, 6 Thrimidge S.R. 1999, 19:36
12.19.6.2.11, 7 Chuen 19 Pop, Sixth Lord of Night
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Algorithms where encryption=decryption?
Date: Tue, 27 Apr 1999 19:36:24 GMT
> >I am looking for any algorithms that can be used in encryption in which
> >the encryption algorithm is the same as the decryption algorithm.
Um, RC4 anyone?
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: DES3 padding
Date: Tue, 27 Apr 1999 16:44:23 GMT
HI,
I'm a newbie using DES and have integrated DES3
into my program. The program basically reads
a 16 byte block then encrypt it. The problem
is at the end when there are less than 16 bytes
of data. I've read abite on padding but can not
get the last block to encrypt/decrypt correctly?
eg: last block of data contains 8 bytes
the end.
How do I pad the last block? with '0'?? If padded
what about when I try to decrypt it? do I need
to pad it with '0' too on decrypt?
please reply to [EMAIL PROTECTED]
thanks
Danny
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Tue, 27 Apr 1999 20:03:13 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 27 Apr 1999 12:15:20 -0500, Medical Electronics Lab
<[EMAIL PROTECTED]> wrote:
>Autocorrelation and frequency distribution as well as uniformity.
Can you offer formal reasons for those choices.
>If autocorrelation gets above .1 it's a flag,
How come?
>if uniformity is unbalanced by more than 200 it's a flag
Please define "uniformity". I do not want to make any incorrect
assumptions.
>and if the frequency distribution on 8 bit patterns has more than 32 bins missing it's
>a flag.
Please elaborate on that - it is not clear what you are driving at.
>20,000 bits ain't a whole lot to work with to get 10^-6. I'd
>prefer 10^6 bits :-)
So would I, but what is the reason for choosing that number.
BTW, I notice that all three of your tests are on single samples,
which to my way of thinking means that you must have specific modes of
malfunction in mind.
What specific kinds of malfunction are you targetting with those
tests?
Bob Knauer
Guns don't cause violence - violence causes violence. Gratuitous violence
in the media/entertainment industry causes violence. Government sponsored
violence like at the Waco Massacre causes violence. Quit blaming law abiding
citizens for the violence in America, and blame the real sources of violence:
the federal government and the media/entertainment industry.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: OAEP, CBC, patents, and improving PGP
Date: Tue, 27 Apr 1999 16:27:48 GMT
A while back - on September 11, 1996 for the first time, which is after
Mihir Bellare invented the similar techniques that are the topic of this
post in 1995 - I proposed the following scheme for improving PGP:
Instead of enciphering a session key plus random padding with RSA, why not
replace the random padding with the first part of the message?
I went further, and suggested the following scheme:
divide the message into two pieces, the first 160 bits and the remainder.
Take the SHA-1 hash of the remainder of the plaintext message.
XOR that to the first piece of the message.
Use as much of the 160 bit result of the previous step as required as the
session key, and encipher the rest of the message with it.
Using RSA, encipher the start of the message XOR the hash, and as much of
the enciphered message as possible.
A recent post in talk.politics.crypto pointed me to an IBM patent
(5,673,319). This patent used DES in CBC mode to illustrate the principle,
All but the first block of a message is used to produce a hash code using
CBC-MAC. The hash code is XORed to the first block, then that block is used
as an IV for the encryption of the rest of the message, using the same
block cipher in CBC mode. (Keys are prearranged for both the CBC-MAC step
and the CBC step.)
An E-mail identified another technique, also invented by Mihir Bellare,
OAEP (Optimal Asymmetric Encryption Protocol) as being more similar to "my"
technique.
The basic technique illustrated in the paper on the subject is
superficially similar, since here SHA-1 and RSA are used in the
illustration. But something different is going on.
A random number is generated to serve as the key. In the paper, it is
assumed that a stream cipher (like RC4) is used as the symmetric-key
cipher. RSA is used to encrypt a block consisting of the
symmetrically-enciphered plaintext, followed by the key, which has been
scrambled by being XORed with the hash of the _encrypted_ plaintext.
In "my" scheme, decryption involves first taking the key, which is plainly
visible after the RSA layer is decrypted, and decrypting the rest of the
message. Then one generates a hash of the decrypted rest-of-message, and
XORs it with the first block to get the first block as plaintext. The
intent is to use the message itself to generate an effectively random
session key, so as to obtain total length preservation: this is what the
CBC-MAC scheme does, even though it is envisaged as eliminating the
overhead of an initialization vector instead of that of a session key.
In this scheme, one begins by generating a hash of the encrypted message,
and then XORing that with the key block to get the actual key. Then one
uses that key to decrypt the message. The purpose of this is to make the
encrypted message sufficiently dependent on the whole plaintext as to
eliminate certain attacks on RSA.
It sort of looks like "my" scheme done backwards, but I think the other
patent (I couldn't find a patent on OAEP, but that doesn't mean there isn't
one, perhaps pending) is conceptually closer. The distinction between an
IV, and a session key to be also encrypted by RSA, seems to me to be
essentially trivial.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
** 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
******************************
