Cryptography-Digest Digest #159, Volume #12 Tue, 4 Jul 00 15:13:01 EDT
Contents:
Re: Crypto Contest: CHUTZPAH... (Boris Kazak)
Re: cray and time needed to attack (Jerry Coffin)
Re: Java implementation of DES and 3DES (Boris Kazak)
Re: Use of EPR "paradox" in cryptography (David Hopwood)
Will PegwitW be useful for Mixmaster 3? (Was: Digital Signatures) (Roadkill)
Re: An encryption protocol, version 2 (Ichinin)
Help programming ([EMAIL PROTECTED])
Re: A thought on OTPs (Guy Macon)
Re: RC4 question (Guy Macon)
Re: DES Analytic Crack (Mok-Kong Shen)
Re: Help programming ("Jeff Moser")
Re: Crypto Contest: CHUTZPAH... (David A. Wagner)
Re: cray and time needed to attack (Jpeschel2)
Re: cray and time needed to attack (Jerry Coffin)
----------------------------------------------------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Crypto Contest: CHUTZPAH...
Date: Tue, 04 Jul 2000 16:25:33 GMT
Paul Pires wrote:
***************
> First off, let's make sure that I understand your comment. I am not sure
> that I follow your meaning when you say that the key material itself can be
> re-constructed.
====================
If the next block is encrypted based on the previous key and the
previous
block, then the *decryption* chain of events should flow like following:
# Read the first block of the ciphertext (IV = initial key
status)
# Compute the first 256-bit array for XOR-ing
# Decrypt the first block of real ciphertext (in case this block
consists of all 0-s, read the XOR-ing array)
To make this into an attack, one must have access to decryption engine
for
a brief moment to decrypt 2 blocks - IV and all 0-s.
=================
>
> One meaning would be that you feel that this would allow the reading of any
> message encrypted with that key and by implication, same key-different IV
> messages.
>
> A second meaning is that you feel that this would allow you to read the rest
> of the message from the targeted block on, in that particular message but
> not same key-different IV messages.
==========================
If my understanding is correct, this is what should be accomplished -
you will
read the rest of the message from the first block on, in that particular
message from which the IV was intercepted.
Probably I should reread the description once again and look, what kind
of
internal state are you dragging along.
===============================
>
> A third meaning is that the result of this process allows you to read that
> one plaintext block associated with the one block of chosen ciphertext that
> you inserted.
==========================
In general I have great reservations about the "chosen ciphertext"
attack, as
our crypto-gurus in the group present it. While I understand the
practicality
of "known-plaintext" and even "chosen-plaintext" attack, the very
concept of
"chosen-ciphertext" strikes me as devoid of reason.
Really, if you have access to the decryption engine loaded with the
proper key,
you can just choose your ciphertext to be the message under
investigation,
get the decrypted plaintext and go away without 2^64 effort and/or 2^56
memory requirements!! So I regard all this attack descriptions as kind
of an
academic game, where we are trying to convince our partners that we are
very
konowledgeable, intelligent, and play according to the rules...
=======================
>
> I don't see how you could accomplish one or two above and I have addressed
> these later in this message.
> Three is more of a problem for me. Yes, if you
> could obtain a decryption (processed with the correct key) of a chosen
> ciphertext as you described above you could use the resultant "Mask" to read
> that one plaintext block.
>
> When I wrote this up, I tried to keep it simple and yet clearly explain the
> idea. If you look at the long note at the front of the source code about
> proper use, you will see that I only envisioned this being used in
> conjunction with an ending "verification check" to make sure that an altered
> ciphertext decrypting is detected and that the program would then "Bomb out"
> with the same probability as the key strength supported, 2^64 in this case.
======================
In order to detect the wrong ciphertext decryption you must provide the
verification block after the ciphertext, increasing thus the ciphertext
size at least by a 2^64 block at the end.
This will not prevent anybody from *decrypting* the altered ciphetext,
if this
copy of the program will "bomb out", it is sufficient just to start a
next
copy and go ahead with the next ciphertext.
================================
>
> I understand now that this is a feeble argument, trying to justify this
> as a block cipher when, as David Wagner pointed out, it clearly is something
> else.
**************
> My reason for posting this was
> that I believe that I have vaccinated this thing from revealing key
> information from the 256-bit block (the Mask) that is XOR'd with the
> plaintext. Let's say that the attacker has known plaintexts and the
> associated ciphertexts. This being the case, let's grant that an attacker
> has all of the masks (that info that is XOR'd to encrypt) his goal in this
> case must be finding the key as he already knows the plaintext.
>
> Ok, finding the "key material" is trivial but I'd quibble and say that it is
> a bank of "ranked material" generated from the "key material". It seems that
> an attack would be finding true information about key values from these
> masks. Am I missing your intent?
>*********************
> Each of these masks or rankings is the result of two, independent, "many to
> one" mappings of their respective tables. I believe that these mappings are:
>
> 1, Dynamically changing with the internal state.
>
> 2, Individually lossy and indeterminate in the reverse direction.
> *********************
> Your focus (If I understand it correctly) has merit. If any key information
> can be found from the result of (Plaintext XOR Ciphertext) this method has
> no value. I have focused here not on hiding the "key material" but in hiding
> information about where it came from and it's reason for being represented
> in a particular location.
============================
As I said already, I must reread the description again and then come
back to
our academic games...
Best wishes BNK
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: cray and time needed to attack
Date: Tue, 4 Jul 2000 10:40:53 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> Not even NSA can afford to waste resources like that.
> They need to maintain a certain minimum rate of intelligence
> production or lose their funding (Congressional support).
I doubt that congress would think in terms of pulling funding --
instead they'd just see to it that the director got replaced with
somebody willing to actually do the job instead of getting caught up
in wild goose chases.
Then again, it would be hard to imagine anybody becoming the director
to start with unless they were a lot more practical about things than
attempting an attack like this.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Java implementation of DES and 3DES
Date: Tue, 04 Jul 2000 16:43:39 GMT
dexMilano wrote:
>
> The algortith seems to work perfectly.
> I've verified some cases that put the error.
>
> For example, if the resulting bit sequence is 143 the character
> corresponding (ASCII (143)) is "\uFFFD" as a single char!
> If try do decript the sequende where I have this char I have a wrong
> decription.
> I don't receive any error but the algorith doesn't work.
>
> That's why I think the problem could be in the way Java manages
> characters.
>
> dex
===========================
ASCII 143 can be interpreted by the system as "unsigned char", in which
case its value will be really 143, or as "signed char", in which case
its value will be 256-143= -113.
There must be some way in Java to treat and concatenate bytes as
"unsigned chars", otherwise no cipher implementation will work
correctly.
Probably you will be better off handling your plaintext and ciphertext
as arrays of "unsigned shorts" (16-bit) and using hex notation to read
and write these. Chars are very tricky, system always wants to assign
them a bunch of special meanings, escapes, formatters, etc.
Best wishes BNK
------------------------------
Date: Tue, 04 Jul 2000 01:32:12 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: sci.physics
Subject: Re: Use of EPR "paradox" in cryptography
=====BEGIN PGP SIGNED MESSAGE=====
John Savard wrote:
>
> On Mon, 3 Jul 2000 18:30:10 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
> wrote, in part:
> >John Savard wrote:
>
> >> However, the fact that one measurement affects the other,
> >> yet at a speed faster than light, ...
>
> >Not really, at witnessed by the fact that one cannot exploit
> >EPR to send controlled information faster than light.
>
> Yes, one cannot do that. However, the one measurement still does
> affect the other measurement, since if both measurements are of the
> same polarity component, the results always match.
No. The results of the measurements are always consistent, but there is
not enough evidence to support the conclusion that this is because
measuring one result affects the other.
Actually I think the main usefulness of quantum computation will be in
basic physics research, i.e. casting more light on what explanations
of quantum physics are consistent with experimental evidence, rather
than in cryptography or cryptanalysis. Note that it isn't necessary to
be able to handle large numbers of qubits to do that.
- --
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
iQEVAwUBOWEwXDkCAxeYt5gVAQGFBQgAzreyAmzwZ6f7wNdXpbElw+2PON/z7Wlw
ofQA0dkiqCFZ6SJOxknKfNCeRIKXSAIogpucxopVPQpOzyqLlGDt4KxJ8KcVC6n8
gdLHa59eN1u/lfKSGKfrddVs5pHjFsaoIBwOLY6ITcwMacqJzc90xifl/uVpnKVN
XgTWNdXgOYKngNK8gLLNQ8hFqvQ+FLr5NWeDObAC2+TcgVXfTuAVNBqr4iVwixu3
QhUqM4Zhy/8vX+yfTB+mTSiYOM1m8hKTj4Ot9Iq2EKNWcDk0ODSawE8sp62B6GPj
L1Aa6Hd1OrgBdsODiwHDKhFYCgCfpQAMKXV4tqbWakQSBpGBZjd3bw==
=0q2o
=====END PGP SIGNATURE=====
------------------------------
From: Roadkill <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp.discuss,alt.privacy.anon-server
Subject: Will PegwitW be useful for Mixmaster 3? (Was: Digital Signatures)
Date: 4 Jul 2000 16:50:49 -0000
First, I see this discussion about using DH vs RSA for Mixmaster 3.
Why not use the Pegwit source code as a base for Mixmaster 3. And
generate big random phrases to use as a secret remailer keys? Great
thing about Pegwit is that it doesn't 'leak' it's KeyID to the
receiving user (and/or spying agency). Maybe this could also be
called Cpunk 2 remailer, with Pegwit instead of the every
clumpsifying PGP 6.5.3+ (with Picture ID, Web of Trust and more
nonsence stuff you don't need as a remailer client/server).
You could still use PGP to encrypt to the reciepent (or PegwitW 1.0
if it ever comes to that). Good luck!
Disastry wrote:
>
> Roadkill wrote:
>
> > Pegwit: <http://ds.dial.pipex.com/george.barwood/v8/pegwit.htm>
>
> there is also windows GUI for Pegwit at http://disastry.dhs.org/pegwit
> works with clipbord/files/etc
Nice (very small) program! When I wanted to decrypt however from the
text window with the wrong key; it deleted my cyphertext :-( Does this
qualify as a bug?
> > I suggest you use PGP 6.5.3 with RSA 1024 encryption. It has the largest
>
> or better 2048 bit
Why is your RSA key only 599 bits? Do you want the NSA to break it
(RSA-155 (515 bits) was broken by the CWI in Holland recently, sure the
NSA can break 599 bits in a few weeks now! They don't have to break in
to your computer at all [And you look like a nice target IMHO]).
Happy regards,
Roadkill
--
"If you're so special, why aren't you dead" - Kim Deal
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: An encryption protocol, version 2
Date: Tue, 04 Jul 2000 19:23:24 +0200
Ops, you're in .PH - Nevermind :o)
------------------------------
From: [EMAIL PROTECTED]
Subject: Help programming
Date: Tue, 04 Jul 2000 17:29:16 GMT
I have an idea for an encryption that takes one file to encrypt
another. So the key is the would be 3 pic files and each byte of the
pics would change the file to be encrypted. I have work out an
algorithm. And could use a lot of help to turn it into code. Is
their any other programs like this or am I wasting my time?
Duey
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: A thought on OTPs
Date: 04 Jul 2000 13:41:05 EDT
David A Molnar wrote:
>
>
>Guy Macon <[EMAIL PROTECTED]> wrote:
>
>> I don't like the phrase "provably secure" Both "provable" and "secure"
>> mean something different to the layperson. I like "the code is impossible
>> to break". It speaks to the nontechnical reader. in my opinion.
>
>what is the difference between "provably secure" and "the code is
>impossible to break" to a layperson? They both sound really impressive,
>and they both overlook the kind of caveat emptors which take up so much
>argumentation in this newsgroup, like the assumption that the key is truly
>random.
Of couse I can't give provable <smile> answers about what impression
wordings will make, but to me, it seems like "secure" implies resistance
to attacks other than codebreaking. As far as the assumption that the
key is truly random goes, that seems to me to be an issue for those who
have strong opinions about whether true randomness exists, not for a
lay person who is recieving an explaination about why an OTP cannot
be broken through cryptanalysis. I would skim by such important
concepts as "random", "XOR", "one time" etc. when explaining it to
the lay person. Too much detail.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: RC4 question
Date: 04 Jul 2000 14:03:00 EDT
dexMilano wrote:
>I know that the strength level of RC4 is considered very good because
>of the key preparation.
>
>I've thought to enforce it using a variant of CFB (Cipher feedback).
>I mean that the Nth character is shifted of M position depending on the
>n-1 ciphered character.
>
>With this shifting the code-resulting of the character depends on the
>previous sequences. SO its more difficult an attack based on frequency.
>
>What do you think of this idea?
I think that there is a better way to strengthen RC4 (with the usual
comment that attempting to improve on known good systems is a hobbyist
undertaking, and is about as necessary as building a hot rod is.)
Start with the ciphersaber implementation of RC4
[ http://www.ciphersaber.gurus.com ].
Add a random number of random printable ASCII characters at the start
and at the end of your plaintext. Depend on the human brain of your
recipient to figure out where the real message starts and ends.
Optional things to consider for even more overkill: compression and
pretreating the plaintext with some other cipher before running it
through ciphersaber.
Hint: make each "improvement" a separate program, run them at different
times, and have them only communicate through a text file on your disk.
Otherwise, the chances of you making a mistake and ruining your own
security will be many orders of magnitude more likely than the small
amount of extra resistance to attackers your "improvements" may make.
If you have serious encryption needs, forget all the hobbyist stuff I
just wrote about and just use a known to be strong method that is coded
by someone else. I suggest PGP.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DES Analytic Crack
Date: Tue, 04 Jul 2000 20:17:27 +0200
"Douglas A. Gwyn" wrote:
> Mok-Kong Shen wrote:
> > DES through solving a set of mathematical equations. However, it
> > was found that that would require, among others, a practically
> > impossible large amount of memory space.
>
> If so, that was a miscalculation.
Do you know any literature about obtaining and solving the set of
equations for DES? Could you give any reference or are you merely
postulating on a miscalculation? Thanks.
M. K. Shen
------------------------------
From: "Jeff Moser" <[EMAIL PROTECTED]>
Subject: Re: Help programming
Date: Tue, 4 Jul 2000 13:26:38 -0500
<[EMAIL PROTECTED]> wrote in message news:8jt6ss$mlg$[EMAIL PROTECTED]...
> I have an idea for an encryption that takes one file to encrypt
> another. So the key is the would be 3 pic files and each byte of the
> pics would change the file to be encrypted. I have work out an
> algorithm. And could use a lot of help to turn it into code. Is
> their any other programs like this or am I wasting my time?
Basically, it's a One Time Pad if you only use the pictures once and only
once and therefore have new ones for each encryption. Also, only the sender
and the receiver can know the pictures.
If any of the above is not followed.. it'll be terribly insecure.
Cheers,
Jeff
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Crypto Contest: CHUTZPAH...
Date: 4 Jul 2000 10:49:21 -0700
In article <[EMAIL PROTECTED]>,
Boris Kazak <[EMAIL PROTECTED]> wrote:
> While I understand the practicality
> of "known-plaintext" and even "chosen-plaintext" attack, the very
> concept of "chosen-ciphertext" strikes me as devoid of reason.
>
> Really, if you have access to the decryption engine loaded with the
> proper key, you can just choose your ciphertext to be the message under
> investigation, get the decrypted plaintext and go away [...]
But the same argument `shows' that chosen-plaintext attacks are also
just as devoid of reason! So, this should be a giant hint that you've
made a mistake in your reasoning.
What you're missing is that the threat model may be more complicated
than you described. More likely is a `lunchtime' attack:
An insider gains temporary access to the encryption or decryption
engine, but only over lunchtime (say), and he'd like to be able to
exploit this to recover encrypted traffic that may be sent in the
future (after his lunch break is over, i.e., after he loses access
to the device).
If he has access to the encryption engine, a chosen-plaintext attack
allows the adversary to learn the key using his lunchtime access and
then decrypt all future traffic; if he has access to the decryption
engine, it's chosen-ciphertext attacks which are dangerous.
Personally, my experience is that chosen ciphertexts are often _easier_
to obtain than chosen plaintexts, so chosen-ciphertext attacks should
be even more of a concern (in practice) than chosen-plaintext attacks.
------------------------------
From: [EMAIL PROTECTED] (Jpeschel2)
Subject: Re: cray and time needed to attack
Date: 04 Jul 2000 18:45:53 GMT
[EMAIL PROTECTED] (Mark Wooding) writes:
>What are you planning on factoring to break a Diffie-Hellman key?
>
>[Oh, the rest of your article was fine. I'm just nit-picking.]
>
Sorry, I don't know how the original poster is going to attempt
to crack a 1024-bit DH key. I should have said, however,
that solving a DL problem (with a key of that size) is going to be
as fruitless as attempting to factor such a number.
Joe
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: cray and time needed to attack
Date: Tue, 4 Jul 2000 13:02:23 -0600
In article <8jsif9$8br$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> > > 2� 1024 bit key with blowfish
> >
> > A Cray would NOT be the weapon of choice in either of these attacks.
> > Instead, you'd want to use specialized custom hardware.
>
> Yep. We are still talking about times in the BILLIONS of years for
> (1) and (2) will never be done. [Do the arithmetic]
...at least by key exhaustion, it won't. If there's ever any
possibility of exhausting the space of a 1024-bit key (or even the
448-bit maximum key for Blowfish) I'm confident it'll be long after
I've died.
There's no real need to go over the physics to assure me there isn't
enough energy in the universe and such -- I'm not sure I believe we
know everthing there is to be found about physics yet either, so a
few thousand years hence, the limitations we currently see seem
roughly similar to ancient ideas about the earth sitting on the backs
of turtles and such.
> > If you intended to say 128 decimal digits instead of 128 bits, then
> > at least you've got something secure enough that you might consider
> > sing it. Somebody with plenty of talent and money could still break
> > it, but the best people and computers available would still take a
> > few months to do the job.
>
> No. Try 1-2 weeks at worst.
Okay -- I'll buy that.
> > > 4� 1024 bit key with DH
> >
> > This borders on being theoretically possible with present technology,
>
> No, it is not. it is not even CLOSE. This is NOT doable within
> current technology.
I think this is mostly a difference in how we're using the
terminology.
I strongly suspect you're thinking in terms of what parts (e.g. CPUs,
memory chips, etc.) are presently available.
When I said current technology, I meant exactly that: technology.
Not necessarily what's currently being produced, but what could be
produced using what we currently know. Likewise, it assumes that
essentially _all_ the world's production of semiconductors and
associated equipment is used for this project, NOT building cell
phones, Gigapets, etc.
IOW, when I said "theoretically", I meant it very literally: I was
not talking about what's currently being produced or what somebody
could buy off-the-shelf right now. I was talking very specifically
about what could theoretically be dedicating all currently-known
technology to the task.
Just to get an idea of the general sort of thing I'm talking about,
consider that Micron Technology is currently building and selling
memory at a rate of roughly $1.5 billion/quarter (according to their
most recent quarterly statement). Given current RAM prices and
Micron's market share, that means that if all the world's production
of RAM were dedicated to producing memory for this project, it
appears that it would be possible to do so within a somewhat
reasonable period of time (i.e. a matter of months to years, not
decades or centuries).
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
** 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
******************************
