Cryptography-Digest Digest #84, Volume #9 Tue, 16 Feb 99 23:13:02 EST
Contents:
Re: 640-bit Modulus Factored. (Ted Kaliszewski)
Re: encryption debate (Michael Sierchio)
Re: Block ciphers vs Stream Ciphers (Terry Ritter)
Re: Privacy, Traps and Frozen Hell ([EMAIL PROTECTED])
Re: Tell-Tale DES Byte-Length Encoding ([EMAIL PROTECTED])
Re: New high-security 56-bit DES: Less-DES ([EMAIL PROTECTED])
Familiar with RIPEMD? (CHARLIE BROWN)
Barcodes ("Vicky")
Re: encryption debate (wtshaw)
Re: Block ciphers vs Stream Ciphers (wtshaw)
Re: Algorithm help (wtshaw)
Re: Privacy, Traps and Frozen Hell ([EMAIL PROTECTED])
Re: Privacy, Traps and Frozen Hell ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Ted Kaliszewski <[EMAIL PROTECTED]>
Subject: Re: 640-bit Modulus Factored.
Date: Tue, 16 Feb 99 19:18:24 -0500
Thank you for your comments. The modulus in question, besides being a pseudo-
prime, is also a product of two primes that are simply relates as follows:
p = 2*q -1, according to the proposition made by G. Jaeschke ( Math.Comp.
61(1993), pp.915-926. Thus, it can also be factored by solving the corres-
ponding quadratic equation. However, I stick to my ufm routine since it is
effective for a more general case of pseudoprime moduli, of which I have
tried quite a few and in fact, have the results posted in this forum for
253 and 513 bit moduli. The fact is, of course, that non-pseudoprime
moduli do not, as yet, yield to this procedure and so my results do not
in any way outperform the NFS algorithm. I am quite impressed with the
results recently announced by the Dutch group.
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: encryption debate
Date: Tue, 16 Feb 1999 15:09:02 -0800
Reply-To: [EMAIL PROTECTED]
On Tue, 16 Feb 1999 16:43:24 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>> Amendment X grants unenumerated rights to the STATES. I believe
>> you mean to refer to Amendment IX.
>This is an error. The phrase is the states or the people. Note that
>this is one of the keys to the proper interpretation of some of the
>enumerated rights in which the term "the people" appears.
Amendment IX refers to RIGHTS of the people. Amendment X says that POWERS
not delegated to the United States are reserved to the respective
states or the people. Amendment IX is the relevant one when discussing
"enumerated" vs. implicit rights.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Block ciphers vs Stream Ciphers
Date: Wed, 17 Feb 1999 00:44:24 GMT
On Tue, 16 Feb 1999 23:39:21 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>
>>I suppose the real advantage is pedantic:
>
>I hope you mean pedagogical.
I did. Thank you.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Privacy, Traps and Frozen Hell
Date: Tue, 16 Feb 1999 23:08:51 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Given that the protocol that A+ B use is known to C and that they have 56
> bits of shared secret, and C has resources to break the base encryption
> protocol being used with blinding speed they are frankly screwed. Anything
> they can do to secure this protocol is still limited by the 56-bit key.
James:
No. And, this is the basic idea I was trying to communicate. The Alice + Bob
Less-DES protocol has only 56-bits of shared-secret key -- but it has the
look-and-feel of 70-bits (for example, could be more) to any attacker.
Now, if 56-bits DES costs 40 hours to a modest attacker (EFF DES Cracker),
then 70-bits takes 75 years for that attacker. And, over one year of expected
delay to a "blinding speed" attacker that could crack DES in 40 minutes...
BTW, that is why the Wassenaar Arrangement forbids +64-bits even under
license.
> This makes an exhaustive search for the key quite practical. So long as C
> can search the available space that quickly they have big trouble.
This does NOT apply to 70-bit M-DES or the derived Less-DES. Note that M-DES
or Less-DES can be +70-bit also, so an attack becomes increasingly
impractical even if the attacker is willing to wait for an average of some
years in order to decrypt *one* message...
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Tell-Tale DES Byte-Length Encoding
Date: Tue, 16 Feb 1999 22:39:54 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> All,
>
> There is a subtlety to DES message-length encoding that reduces
> uncertainty in even a decrypt of a random message by 5-bits,
> (that is, a factor of 1/32).
Tony and all:
IMO, this is NOT a small problem. It is a covert channel providing
user-unaware information -- openning up a host of problems, as partially
discussed below.
First, one must be careful with the kind of "garbage" that is outputted
before that last byte (when its value is 0 to 6, so that "garbage" must
exist), after the end of the plaintext. Is it really garbage? Can it be
distinguished from the plaintext?
Second, can the length-encoding allow the plaintext length to be self-checked
with the length-byte -- in the very same way that the publicly known DES
software uses it -- for each trial-key? Of course ... it must, for which the
attacker only needs to decrypt the last block -- since it depends on mod 8
math. Thus, defining a reliable self-check that the attacker can use
irrespective of plaintext analysis -- or, together with it.
Second, as example for DES re-keying, 56-bit of random data (eg, a new DES
key) will have at most 48-bits of randomness -- not 51-bits as you suggest:
>These kinds of implementations reduce ambiguity of output,
>even for "random" clear-text, by 5-bits, or a factor of 32.
>So, on a brute-force attack, at most 2^51 decryptions need
>any further analysis (not 2^56).
In other words, the factor in this case is 256, not 32. Why? Because even
though there are 2^56 numbers with 8-bytes that have a random 56-bit "head"
and a "tail" byte of 0, there are on average 2^48 wrong DES decryptions which
may lead to such a number (hence, 2^48 wrong DES key) since DES is a random
cipher only over 56-bits -- see http://www.mcg.org.br/nrdes.htm
Further, I note that the first 32 ASCII characters are non-printable --hence,
the presence of a last non-printable byte in an otherwise printable message
may be very conspicuous.
[large snip]
> These kinds of implementations reduce ambiguity of output,
> even for "random" clear-text, by 5-bits, or a factor of 32.
more than that -- because they self-check with the message`s length they can
collapse the whole 2^56 space into much fewer cases. See above -- for 2^48
cases. And, correspondlingly less for English-plaintext. As above, if this
"feature" allows the DES software to automatically define the message's
length, then it must also allow an attacker to use it to self-check a message
when trying out a key.
> So, on a brute-force attack, at most 2^51 decryptions need
> any further analysis (not 2^56).
>
> (In an exchange with Ed Gerck on the MCG discussion list,
> Ed pointed out that if a "useful", statistically random
> 1000-bit string is DES encrypted, and an attacker decided
> to keep ALL of the 2^56 decryptions around to see which one
> would be useful in a future, tell-tale context, they would
> need to keep about 100,000 Terabytes on hand.
It was 100,000 Terabits, but I guess the difference is very slight ;-)
> Or, simply drop that output block entirely.
Yes.
>
> Also, one can trivially alter DES code, so that it does not
> encode length at all. The caveat: The DES routine must be
> "told" ahead of time how many blocks to process.
>
That can be safely done by the higher-layer -- which works with plaintext and
encodes/decodes that information in the message`s headers. The message's
headers can be compressed and pre-encoded as in text-hardening, which would
no longer place that critical information as a fixed target, a sitting duck
as that last byte may be called.
Your message exemplifies the fact that a protocol can be easily made (more)
unsafe by the underlying data encoding. Where we can also turn the table and
make it safer than secret-key bit-length limitations would suggest, as in the
M-DES thread for +70-bits security with only 56-bits of secret-key.
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New high-security 56-bit DES: Less-DES
Date: Tue, 16 Feb 1999 23:27:28 GMT
In article <7a2hpk$cih$[EMAIL PROTECTED]>,
"lyal collins" <[EMAIL PROTECTED]> wrote:
> >For M=14, Alice should take approximately one minute to solve the
> >14-bit problem, while EFF's DES Cracker (a powerful DES cracker in
> >hardware) would take approximately 75 years to solve the 70-bit
> >problem. To compare, the EFF DES Cracker would take approximately 40
> >hours for the usual 56-bit DES key.
>
> These would seem to impose an upper limit of around 60 decrypted received
> messages per hour - provided that machine isn't used for anything else.
This is true. Note however that the expected Pentium run-time is perhaps
one-tenth of that (8,000 DES one-block decryptions). Further, as I wrote in
the message, Less-DES is a special case of the M-DES protocol -- which allows
the definition of an "unknown-key" for those 14-bits and does not impose a
new "key-discovery" task for every message. Please, see the M-DES protocol
definition and key-reusage discussion in
http://www.mcg.org.br/unicity.htm#5.2
An important point is that (56+M)-bit key-lifetime in M-DES does not depend
on usage (ie, number or length of messages sent) but on time, so that Bob and
Alice can leverage Alice's discovery burden over many messages (not just
one).
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: CHARLIE BROWN <[EMAIL PROTECTED]>
Subject: Familiar with RIPEMD?
Date: Tue, 16 Feb 1999 20:50:15 -0500
Hi,
I have a simple question. In the RIPEMD driver function "RMDbinary",
there is a quantity called "length[1]". I'm wondering what the
significance of this value is and under what circumstances is it "not"
equal to zero?
Any help is appreciated, and thanks in advance.
LessThanZero
[EMAIL PROTECTED]
=====================
RIPEMD-128, 160
http://ftp/funet.fi/pub/crypt
http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html
------------------------------
From: "Vicky" <[EMAIL PROTECTED]>
Subject: Barcodes
Date: Wed, 17 Feb 1999 01:36:49 -0000
Hi,
I'm not sure if this is entirely on-topic, so apologies if it isn't, but I
have trawled the net for info (and failed), and this newsgroup seems to
fit best.
Anyway, I had a lecture this week which got me thinking about barcodes.
The lecturer explained how ISBN numbers like A-BCD-EFGHI-J are coded
so
A*1 + B*2 + C*3 + ... + J*10 is congruent to 0 (mod 11)
I knew this already, but what I want to know is how barcodes are coded.
There seem to be two flavours, 8 digit and 13 digit, and I'm intrigued to
find out what the algorithm is. I'm sure I used to know, but I've
forgotten. Hopefully it's not quite as complicated as the lovely
VideoPlus+ algorithm.
So, can anybody help me out or point me in the right direction? I need to
know!
Thanks
Ian
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: encryption debate
Date: Tue, 16 Feb 1999 20:17:59 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> We all realize that the Constitution can never be properly restored.
> That is why the only solution to this nightmare is secession.
>
What makes you think that our local gaggle of political geese have more
sense than those somewhere else? At least, when most of them are in a
highly decorated place, inside the beltway, they are easier to keep an eye
on, and have difficulty in directing enforcing wild notions in the
hinterlands.
Consider the encryption issues, if you don't like Bubba there, and you
don't have one every term, you sure as would not like all the local yokels
getting a feeling of increased power to abuse people's rights anyway they
saw fit; we have enough of this already.
Even though not in the realistic cards, we here in Texas do reserve the
treaty right to divide into six different states and get ten more
senators.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Block ciphers vs Stream Ciphers
Date: Tue, 16 Feb 1999 19:53:22 -0600
In article <7abu0j$fke$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Patrick Juola) wrote:
> In article <7abaol$mtf$[EMAIL PROTECTED]>,
> Gustavo <[EMAIL PROTECTED]> wrote:
> >Hi.
> >It seems that the cryptographic community is
> >interested almost only in block ciphers and not
> >in stream ciphers.
> >What are the advantages of the first ones?
>
> Diffusion.
>
> Suppose I were to send a message to my broker :
> please sell $100,000 worth of IBM
>
> A sufficiently cunning adversary could change a few bytes
> and produce
>
> please sell $900,000 worth of ATT
>
> In fact, he could change the order by simply changing these bytes
> please sell $100,000 worth of IBM
....
> A good block cypher would require him to unbutton the entire message;
> it's more or less immune to this sort of byte-by-byte attack.
Selecting a type of cipher does not remove the need to use good sense. An
important message should be redundant so that any changes, intentional,
unintentional, or due to some technical error do not change the meaning.
I know, there are those that think that communication errors are no real
factor, but they can be.
Consider that like writing a check with information in different forms
that much tally correctly, important message should also. If the
underlying crypto system cannot handle redundancies without repeating
ciphertext chunks accordingly, it is not sufficiently sophistocated.
There is a hugh gulf, could be well populated, between simple block
ciphers and simple stream ciphers. It is not and either/or choice between
block ciphers and stream ciphers. Individual algorithms are all important
in meeting your needs.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Algorithm help
Date: Tue, 16 Feb 1999 20:04:25 -0600
In article <[EMAIL PROTECTED]>, Swartz <[EMAIL PROTECTED]> wrote:
> I was just wondering if anyone had any info on how to make a algorithm
> that was based on time (you had to decrypt it during a certian time).
> If anyone has any info, I would appreciate it.
>
You need to define time in the sense of sequence, availability, or
something else. Supposedly you could build a vital chip that would
deteriorate into non-function, which is similiar to building weapons that
will fail to fire after a while.
You could write a program that would decrypt on or before a certain date
and if other dates in the directories were not beyond it; this would make
it a pain to have a computer just for solving the message.
If the absolute failure is not local to the user, it must be somewhere
else, like availability of a necessary complementary key to complete the
process, which could be removed from the web.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Privacy, Traps and Frozen Hell
Date: Wed, 17 Feb 1999 03:11:24 GMT
In article <[EMAIL PROTECTED]>,
Terje Mathisen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> [snipped message about extending a secret key with N unknown bits]
> > equivalent -- say, the attacker is 15,000,000,000,000 times faster?
> >
> > Can we still favor that "one" in lieu of that very powerful attacker,
> > which has even defined the very contrived privacy limits we have for
> > maneuver? Can we escape the trap and outsmart the attacker? How long
> > can we hold off the attacker from that secret? Can we hold off the
> > attacker until Hell freezes over?
>
> The simple answer to this problem seems to be that as long as the
> attacker needs significantly more time to break the 56-bit key than the
> recipient needs to decode the message (message block), then you can use
> this to keep the message secret as long as you want.
>
> If however the attacker can exhaustively search the 56-bit key space in
> the same time as the recipient needs to decode using the the key, then
> they would seem to be equal?
>
Under simple assumptions for M-DES, the attacker`s workload is C*2^(56+M-1)
while Alice's workload is A*2^(M-1). Their ratio is (C/A)*2^56 -- which means
that unless the attacker is 2^56 times *more* powerful than Alice (ie, C is
2^56 smaller than A) .. Alice will win. This can be further improved by
plaintext compression, plaintext hardening, etc. and may further increase the
time difference in favor of Alice.
But, "...until Hell freezes over" (ie, never) is more strict and will be
discussed in next msgs.
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Privacy, Traps and Frozen Hell
Date: Wed, 17 Feb 1999 03:22:02 GMT
In article <[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
> > The example defines a hypotetical protocol called M-DES, which
> > achieves an "effective" secret-key bit-length of 70-bits when viewed
> > by Carol, even though the initial shared-secret between Bob and Alice
> > was only one DES key with 56-bits. With +25% safety margin, the
> > M-DES protocol forces Carol to cope with 70-bits of ignorance, which
> > would force Carol to spend an expected number of
> > (2^(69))*40/((60*24*30*12)*2^55) = 1.26 years to decode Bob's
> > communication to Alice. While Alice faces 70 - 56 = 14 bits of
> > ignorance and that takes her only (2^13)/(60*150) = 1 minute to
> > solve.
>
> What advantage does this offer over Schneier's "key stretching"
> technique? I know that's primarily aimed at passphrases but the paper
> mentions its applicability to 56-bit keys, and it seems to me to offer
> better predictability (as well as better control over opponent's
> resource needs) than your technique.
I fail to see any connection. Perhaps, can you provide that? Also, please tell
me what you thought was similar, as well as what you mean by "better
predictability/control".
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** 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
******************************
