Cryptography-Digest Digest #301, Volume #9 Tue, 30 Mar 99 07:13:03 EST
Contents:
Re: Tripple DES key length. (Christopher)
DIGIMARC Algo ? ("Mariette")
---- Two very easy secret key Cryptosystems (kctang8)
Re: newbie question ("Kryspin Ziemski")
Re: Encryption and the Linux password files ("Douglas A. Gwyn")
Re: newbie question ("Kryspin Ziemski")
Re: What is fast enough? (Thomas Pornin)
Re: Is initial permutation in DES necessary? ("Douglas A. Gwyn")
Re: How to avoid double random numbers? ("Douglas A. Gwyn")
Re: Tripple DES key length. (Dennis Ritchie)
Re: What is fast enough? ("Lassi Hippel�inen")
Re: Live from the Second AES Conference (Serge Vaudenay)
Re: Wanted: free small DOS Encryption program ([EMAIL PROTECTED])
Re: Live from the Second AES Conference (Fabrice Noilhan)
Re: Is initial permutation in DES necessary? ("Sam Simpson")
Re: newbie question ("Michal Brzozowski")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Christopher)
Subject: Re: Tripple DES key length.
Date: Mon, 29 Mar 1999 23:37:04 -0500
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
|:| 1999-03-29 21:49:04 EDT
|:| In article <7dongn$gto$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
|:|
|:| >I think it's a bit of an overstatement to refer to a meet-in-the-middle
|:| >attack as if it is practical. The storage of 2**56 trial runs, and/or
|:| >searching through 2**56 trials to compare against makes
|:| >it highly impractical to actually do a meet-in-the-middle attack.
|:|
|:| Today.
|:|
|:| Who could have foretold where we would be today 30 years ago? Who can
|:| say where we will be, say, 90 or so years from now?
|:|
|:| And that's the sort of time frame required.
|:|
|:| For example, what sort of "practicality" requirements would you place on
|:| an algorithm charged with protecting the entrance to an high-grade nuclear
|:| waste dump for the next 14,000 years or so of recorded civilisation?
|:|
|:| outer
For that specific example, personally I would require regular audits and
the ability to change the algorithm as deemed necessary. And I probably
would have other hardware to handle the security, not rely exclusively on
some group of people remembering pass-phrases, and so on...
------------------------------
From: "Mariette" <[EMAIL PROTECTED]>
Subject: DIGIMARC Algo ?
Date: Mon, 29 Mar 1999 17:15:07 +0200
Where could i find the source code of the digimarc algorithm ??
------------------------------
From: kctang8 <[EMAIL PROTECTED]>
Crossposted-To: sci.math.symbolic
Subject: ---- Two very easy secret key Cryptosystems
Date: Tue, 30 Mar 1999 15:24:37 +0800
Dear all,
========Two very easy secret key Cryptosystems=================
a,b,c and e denote positive integers.
Please crack the following systems:
(Q1)
plaintext: [a,b,c]
encryption: choose a secret number e,
cyphertext = [A,B,C] = [e*a, e*b, e*c]
decryption: the partner know e,
get plaintext [a,b,c]= [A/e, B/e, C/e]
(Q2)
Now n denote a positive integer of around 310 digits.
a,b,c and e denote positive integers less than n.
e and n are relatively prime.
plaintext: [a,b,c] and n
encryption: choose a secret number e,
cyphertext =
[A,B,C] = [e*a mod n , e*b mod n , e*c mod n]
decryption: the partner know e, he compute inv = e^(-1) mod n
get plaintext
[a,b,c]= [A*inv mod n, B*inv mod n, C*inv mod n]
Thanks, kctang8
P.S. Forgive me if these questions are trivial, but this is my
best efforts at the moment.
------------------------------
From: "Kryspin Ziemski" <[EMAIL PROTECTED]>
Subject: Re: newbie question
Date: Tue, 30 Mar 1999 04:22:54 -0500
so the encryption process is such that if you so that if you used the
recipient's public key on the message
once it would not output the original message if you used the public key on
it again. So all the recipient has to do is check somehow if this message
was encrypted just for him and then decrypt it using his private key. Do we
know anything about the mathematical relation between the two numbers? Is
the general formula given out or is that all secret?
Michal Brzozowski <[EMAIL PROTECTED]> wrote in message
news:mm0M2.33591$[EMAIL PROTECTED]...
>
> Kryspin Ziemski wrote in message <[EMAIL PROTECTED]>...
> >fine still does not change the fact that ..
> >hey you're polish, cool.. just noticed the pl in the ip address
>
>
> yep! i am :)
>
> >well fine assuming that you have the recipient's public key, you can find
> >his private key
> >by simply debugging the code and looking for the part that actually
> >manipulates that public key
> >to find the private key. how do you prevent this dilema which should
occur
> >because there is no way to hide the actual function from being observed
on
> >the byte level.
> >
>
>
> you can't easily find recipient's private key, because there is no
> conversion
> from public key to private key during decryption.
> there are (afaik) algorithms to find the private key, but it takes a LONG
> time,
> to find one (you have to find prime factors of huge number, or something).
> and there's no need to do byte-level debugging, because source code
> for both encrypting and decrypting programs are publicly available. :-)
>
> Michal Brzozowski
> [EMAIL PROTECTED]
>
>
>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Encryption and the Linux password files
Date: Tue, 30 Mar 1999 09:24:03 GMT
Lincoln Yeoh wrote:
> ... IMO the standard passwd file thingy is only a problem when you have
> users of different security privileges with access to the same system.
> So I don't think it's really a problem if the box only has very few users
> and all the users are already the administrators (e.g. a firewall).
> Coz if someone can get a shell on the system remotely even with the telnetd
> and most other local access services disabled I doubt a shadowed passfile
> will help that much.
History shows otherwise. One of the standard hacker attacks
is to snarf /etc/passwd via a security hole in some service,
e.g. FTP or SMTP server, then run a "crack" tool against it
to recover several passwrods for user accounts. Since a
shadow password file can be accessed only via a process
that has already attained "root" (UID 0) privilege, it is
secure against such attacks unless the attacker has managed
already to completely circumvent the system's security -- UID
0 can do anything, including replacing the whole system!
------------------------------
From: "Kryspin Ziemski" <[EMAIL PROTECTED]>
Subject: Re: newbie question
Date: Tue, 30 Mar 1999 04:27:48 -0500
i'd try to coverse with you in polish but i never could write that well in
polish and my grammar has gone to hell. I can read (but i have to sound out
the words ) and speak it though and can understand reasonably complex
conversation. Are you a student in katowice? I actually have relatives in
katowice. the area is really nice though from what i remember when i visited
a couple of years ago.
Kryspin Ziemski <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> so the encryption process is such that if you so that if you used the
> recipient's public key on the message
> once it would not output the original message if you used the public key
on
> it again. So all the recipient has to do is check somehow if this message
> was encrypted just for him and then decrypt it using his private key. Do
we
> know anything about the mathematical relation between the two numbers? Is
> the general formula given out or is that all secret?
> Michal Brzozowski <[EMAIL PROTECTED]> wrote in message
> news:mm0M2.33591$[EMAIL PROTECTED]...
> >
> > Kryspin Ziemski wrote in message <[EMAIL PROTECTED]>...
> > >fine still does not change the fact that ..
> > >hey you're polish, cool.. just noticed the pl in the ip address
> >
> >
> > yep! i am :)
> >
> > >well fine assuming that you have the recipient's public key, you can
find
> > >his private key
> > >by simply debugging the code and looking for the part that actually
> > >manipulates that public key
> > >to find the private key. how do you prevent this dilema which should
> occur
> > >because there is no way to hide the actual function from being observed
> on
> > >the byte level.
> > >
> >
> >
> > you can't easily find recipient's private key, because there is no
> > conversion
> > from public key to private key during decryption.
> > there are (afaik) algorithms to find the private key, but it takes a
LONG
> > time,
> > to find one (you have to find prime factors of huge number, or
something).
> > and there's no need to do byte-level debugging, because source code
> > for both encrypting and decrypting programs are publicly available. :-)
> >
> > Michal Brzozowski
> > [EMAIL PROTECTED]
> >
> >
> >
>
>
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: What is fast enough?
Date: 30 Mar 1999 09:27:02 GMT
According to <[EMAIL PROTECTED]>:
> Jack Lloyd and I are currently working on a cipher together. I was
> just wondering (from the communities point of view) what is acceptable
> speeds?
The acceptable speed depends much on what you intend to make with your
cipher, on what system. A low-cost smart card is not a high-end Alpha
station scaled down.
The AES candidates are in the range of 10 to 20 Mbytes/s on a ev56
Alpha, which means that you may de/encipher all in/outgoing network
traffic on a 100baseT interface and yet get some cycles to do some real
job (playing solitaire, reading usenet). If you want to an enciphered
harddisk, you need high speed also (Windows users tend to forget the
fact that, on real systems, you may use the cpu while things are read
from/written to the harddisk, so you do not want to use more than 10% of
your cpu for this task).
You might also accept to lower security if your keys are often changed
or if confidentialiy becomes irrelevant one week later. You may gain
much speed by using a stripped down algorithm (but beware, this is a
subtle task and should not be done carelessly).
As a rule of thumb: 10 Kbytes/s is really slow. 200 Mbytes/s is really
fast. Between these two values, it depends heavily on many things, not
the least of which is the author's ability to convince people that his
cipher is the greatest invention since the discovery of the wheel.
--Thomas Pornin
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Is initial permutation in DES necessary?
Date: Tue, 30 Mar 1999 09:47:05 GMT
John Savard wrote:
> Even though the _other_ charges levelled against DES have not been borne
> out (except the one about the key being too short), that the NSA would not
> have wished to comment on the security of an algorithm to be made public
> doesn't seem like too fantastical a notion, and there is some anecdotal
> evidence to that effect.
The key wasn't too short; it outlasted its design lifetime!
I didn't understand your point about commenting. Everyone
knows that at the time (mid-1970s) NSA was still keeping a
low profile, Not Saying Anything that they didn't have to.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How to avoid double random numbers?
Date: Tue, 30 Mar 1999 09:55:40 GMT
Henrik Zawischa wrote:
> "Each message also contains a randomly generated identification number,
> large enough to avoid duplicates with other voters"
> What is large enogh? Isn't the meaning of randomness that you can't
> predict the numbers, i.e. you can't predict that you won't get doubles?
Two possibilities: If the numbers are *really* large, you can
estimate the chance of a collision via standard probability
formulas, and it may be that the chance of even a single collision
is sufficiently low that you'd feel comfortable ignoring it.
The other approach is to keep track of every generated number,
and make sure the new number isn't in the database of already-
generated numbers; if it is, discard it and pick anoother.
------------------------------
From: Dennis Ritchie <[EMAIL PROTECTED]>
Subject: Re: Tripple DES key length.
Date: Tue, 30 Mar 1999 04:33:24 +0100
Reply-To: [EMAIL PROTECTED]
Richard Outerbridge wrote:
> [compiling 2^56-size tables for M-I-M impractical] Today.
>
> Who could have foretold where we would be today 30 years ago? Who can
> say where we will be, say, 90 or so years from now?
>
> And that's the sort of time frame required.
>
> For example, what sort of "practicality" requirements would you place on
> an algorithm charged with protecting the entrance to an high-grade nuclear
> waste dump for the next 14,000 years or so of recorded civilisation?
I would suggest that 90 years from now just about any encrypted
material that now exists has probably rotted away from physical causes
and is of possible interest only to historians who are limited mainly by
their ability to get a grant to study it. Just about no one
will care whether you stored or distributed child-porn,
ran a terrorist or resistance operation, or were about to attack
at dawn. Even if you were a Big Government, your own descendants
would be (on the whole) more interested in unearthing history
than in concealing it except out of bureaucratic sloth.
Crypto has a value to the encrypter that decreases in time
and the value eventually becomes negative. (Well, about 0
in the case of most individual users.)
Dennis
------------------------------
From: "Lassi Hippel�inen" <[EMAIL PROTECTED]>
Subject: Re: What is fast enough?
Date: Tue, 30 Mar 1999 09:41:18 +0300
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] writes:
> >Jack Lloyd and I are currently working on a cipher together. I was just
> >wondering (from the communities point of view) what is acceptable speeds?
> >
> >Right now, in the unoptimized C code, on a 233mhz Cyrix MII, I get between
> >1.4MB/sec and 2.9MB/sec (32 rounds and 16 rounds respectively).
> >
> >Isn't anything above 1MB/sec considered fast enough? I mean my hd controller
> >only works at 4.5MB/sec anyways!
>
> 100baseT is 12.5MB/sec.
>
> --
> Lamont Granquist ([EMAIL PROTECTED])
> ICBM: 47 39'23"N 122 18'19"W
That is the raw bit rate, right? Reserve something for framing, protocol
overhead(s), an occasional retransmission, etc., and you're guite a bit slower. I
still haven't seem too many systems, whose sustained payload rate is more than
half of the raw rate.
But then, the 1 Gb/s Ethernet is just around the corner, even though not yet on
every desktop. It all depends on the application.
-- Lassi
------------------------------
From: [EMAIL PROTECTED] (Serge Vaudenay)
Subject: Re: Live from the Second AES Conference
Date: 30 Mar 1999 11:30:17 GMT
In article <7das7k$42p$[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
|>
|> Finally, as a nod to Asia, I think NIST will pick E2 too. It is
|> certainly a very fine cipher considering its analysis, its
|> theoretical underpinning and its speed. The Japanese presenters
|> are probably the most sympathetic and choosing E2 would include
|> some ladies in the finalist makeup. Also nobody wants to miss
|> the nice accents.
|>
Choosing a cipher because some ladies are in?
I wish we have paid more attention to this interesting criterion during
the workshop.
Of course, you should include DFC in your list (because of Helena).
Serge
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.security.misc
Subject: Re: Wanted: free small DOS Encryption program
Date: Tue, 30 Mar 1999 11:30:31 GMT
In article <7dpqev$ovj$[EMAIL PROTECTED]>,
Milton Pomeroy <[EMAIL PROTECTED]> wrote:
> Wanted - a free DOS-based encryption program which is small, fast,
> strong and friendly
Try
http://members.tripod.com/~tomstdenis/rc4e.zip
The password scheduler is sorta bad, but other than that it goods. Requires a
mouse (for random input). It includes source code. Runs on an 8086, requires
about 32kb of ram.
If you don't feel like changing the source, use passwords that are at least 16
chars long.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Fabrice Noilhan)
Subject: Re: Live from the Second AES Conference
Date: 30 Mar 1999 07:43:59 GMT
According to John Savard <[EMAIL PROTECTED]>:
> >>If you compare all the ciphers on the same compiler ... and I remember at
> >>a computer chess competition, someone suggested that it wouldn't be a bad
> >>idea to require the entrants all to use C, so that it wouldn't be a
> >>competition of assembly-language coding skills.
>
> >Then you're comparing compiler efficiency. What we did in our
> >comparison is assume best possible ASM. We didn't implement
> >everything, but we gave all algorithms the benefits of the doubt.
>
> If everybody's C code is compiled on the same compiler, one may be
> comparing optimizations or something, but one isn't comparing compilers.
One is also comparing portability. In the AES process, there were
significant flaws in portability of several C codes. Casts were not
always done The Right Way, so that they were efficient on PPro... but
produced a wrong result on the other endianess or on 64 bit processors.
Some codes supposed that ints were 32 bits and so on. And there are
instructions which are not available on all compilers; a C code is
often dedicated to one compiler, because optimizations are specific to
compilers. ASM is subject only to processors...
In fact, if you guess a low limit on the number of cycles, it is often
enought and does not take too much time. For instance, Almquist's estimates
on Alpha are relevant... There is not much difference between his estimates
and the real program; and it does not imply ASM coding competition.
Fabrice
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Is initial permutation in DES necessary?
Date: Mon, 29 Mar 1999 16:31:11 +0100
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
You may like to have a look at the paper "Cryptanalysis of the
CFB mode of the DES with a reduced number of rounds" by B.
Preneel, M. Nuttin, V. Rijmen, J. Buelens.
It shows that the final permutation has some cryptographic
purpose when DES is used in CFB mode.
- --
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive
encryption & Delphi Crypto Components. PGP Keys available at the
same site.
If you're wondering why I don't reply to Sternlight, it's because
he's kill filed. See http://www.openpgp.net/FUD for why!
Casey Sybrandy wrote in message
<[EMAIL PROTECTED]>...
>The purpose of the initial and final permutations was to make it
more efficient in
>hardware. It does nothing for security at all. You can look in
Applied
>Cryptography on page 271 for a more detailed description
>
>Casey
>
>Christoph Haenle wrote:
>
>> [EMAIL PROTECTED] wrote:
>> : Hello cryptographers,
>>
>> : It seems to me that initial permutation in DES is
unnecessary since everyone
>> : knows exactly what the permutation is. Does anybody know
the reason why DES
>> : specify a known permutation? Is the initial permutation
there to permute a
>> : certain bit pattern that can cause DES to reveal the key?
>>
>> : Thanks a lot,
>>
>> : -galaknight.
>>
>> The permutation is not done for security reasons. Rather, it
is
>> supposed to make DES implementation slower in software.
However, when
>> using 3DES, it could make a difference (in security) whether
EDE or
>> EEE is used, even when using three different keys (when using
EDE, the
>> permutations between E and D and between D and E won't
disappear as
>> opposed to the EEE scheme). As far as I know, nobody has ever
proven
>> whether of not the permutations strenghens 3DES.
=====BEGIN PGP SIGNATURE=====
Version: 6.0.2ckt http://members.tripod.com/IRFaiad/
iQA/AwUBNv+cu+0ty8FDP9tPEQKaqACeIuBE/ZNdnAu4ivt8AIsBtU6NSrUAoIjR
6j0wV7GVgoiO3Dw3AoUcjM8h
=4I+n
=====END PGP SIGNATURE=====
------------------------------
From: "Michal Brzozowski" <[EMAIL PROTECTED]>
Subject: Re: newbie question
Date: Tue, 30 Mar 1999 08:00:02 GMT
Kryspin Ziemski wrote in message <[EMAIL PROTECTED]>...
>My understanding of public key cryptography is that each person is assigned
>to keys one private and one public. the sender encrypts the message with
>his private key and then sends the message to the reader.
>the reader gets the sender's public key from a directory and then converts
>the public key to the private key using some mathematical relation and
>decrypts the message using the private key. If this is how public key
>cryptography works what stops me obtaining the sender's public key and
>debugging the program to find the code that works on the public key to
>convert it to the private key which i'm assuming is done locally on the
>computer.
Wrong. Sender encrypts message with receipient's public key,
and receipient decrypts it using his (receipient's) private key,
Nobody (except owner) has access to private key.
Michal Brzozowski
[EMAIL PROTECTED]
------------------------------
** 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
******************************
