Cryptography-Digest Digest #884, Volume #13 Tue, 13 Mar 01 13:13:00 EST
Contents:
Re: Instruction based encryption (Sundial Services)
Re: => FBI easily cracks encryption ...? (Sundial Services)
Re: Encrypt then HMAC or HMAC then Encrypt? (David A Molnar)
Re: Super strong crypto (Mok-Kong Shen)
Re: One-time Pad really unbreakable? (Frank Gerlach)
Re: Potential of machine translation techniques? (Mok-Kong Shen)
Re: Really simple stream cipher (David Wagner)
Re: Really simple stream cipher (David Wagner)
Re: Super strong crypto (David Wagner)
Re: Encrypt then HMAC or HMAC then Encrypt? (David Wagner)
Re: OverWrite: best wipe software? (Anthony Stephen Szopa)
Re: GPS and cryptography (David Schwartz)
Re: GPS and cryptography (David Schwartz)
----------------------------------------------------------------------------
Date: Tue, 13 Mar 2001 10:05:40 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Instruction based encryption
The notion of data-driven scrambling is an interesting one, although it
is debatable whether it would provide the security you anticipate. For
example, a computer could test hypotheses against a particular message
(notice that your 5-bit "length" allows for a maximum length of 32
bytes), and look for the first break. From any one break, the cipher
could probably be prized open rather like a stuck zipper. A chain is
only as strong as its weakest link.
Complexity can hide weakness...
... and even Wal-Mart is selling 500mHz computers these days.
>Michael Brown wrote:
>
> Hi there,
>
> I brought up this topic a while ago, and never followed up on it much.
> Here's a description of the algorithm. I have implemented it in Delphi (just
> tell me if you want the source), but I'm converting it to FreePas so that
> most people can use it (I know you guys don't like binaries!). A C port
> might come sometime this century (I hate C, but I'll do it if I'm forced :)
>
> <=== BEGIN ALGORITHM ===>
>
> Each 128 bit key is made up of 16 "instructions", each of length 8 bits. The
> instructions go from the most significant bit down to the least significant
> bit. The first 3 bits of each instruction are the instruction, x, and the
> next 5 bits are the parameter n.
>
> Instruction table
> x
> 0 Xor with previous <n> plaintext bits
> 1 Xor with previous <n> ciphertext bits
> 2 Add previous <n> plaintext bits (under mod 256)
> 3 Add previous <n> ciphertext bits (under mod 256)
> 4 Subtract previous <n> plaintext bits (under mod 256)
> 5 Subtract previous <n> ciphertext bits (under mod 256)
> 6 Rotate left <n> bits
> 7 Rotate right <n> bits
>
> The initial "previous plaintext" and "previous ciphertext" are both just
> repetitions of the key.
>
> "Mash" key according to the following method:
> Xor key with previous 128 bits of plaintext
> Repeat 11 times: Key = Key XOR (Key ROR 11)
> (ROR = rotate right)
>
> This key mashing is done every 128 bytes.
>
> <=== BEGIN NOTES ===>
>
> The 128 byte key mashing is just a number I pulled out of the air, so quite
> possibly is not enough or too often.
>
> The instruction table is quite possibly insecure, having both rotate left
> and rotate right.
>
> No key checking is done in the program. So you can get instructions like
> "xor with 0 previous plaintext bits"
>
> Using the key as the initial data might be insecure. A known plaintext
> attack would be most effective on the first 16 bytes of the file, as you
> could easily geerate the previous plaintext and ciphertext data. This would
> still happen if you used a hash of the key though.
>
> If the key was extended to 256 bits, then the instruction table should be
> expanded to 16 instructions to avoid excessive repeats of instructions.
>
> This should implement very nicey in hardware I should think.
>
> <=== BEGIN SIGNATURE ===>
>
> ---
> Michael Brown
>
> Physics is no fun if you disregard friction.
--
==================================================================
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED] (PGP public key available.)
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R): "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/products/chimneysweep
------------------------------
Date: Tue, 13 Mar 2001 10:08:06 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
If NSA did reveal anything about its cryptographic capabilities, let
alone to the general public, then the taxpayers who pour money into the
thing would have reason to feel ill-used.
I doubt that NSA spends any effort at all in "FUDding," however, since
the best thing to do is always to merely keep one's mouth shut. It's
even a proverb that, if you listen long enough to one man's boasting,
you will soon know every secret about him.
And, "loose lips sink ships." So, let them remain a mystery. It's part
of their mission.
>Frank Gerlach wrote:
>
> Phil Zimmerman wrote:
>
> > BTW, I usually use 4096 length. Anyone have any comments on which algorithm
> > they prefer? TwoFish, AES, CAST, IDEA, TripleDES???
> Normally the KGB uses OTPs. Maybe Hansen forgot to destroy the used
> pads, or even worse, used them twice. Or the KGB still employs some
> secretaries poking on a typewriter to create the pads...
>
> Or maybe the NSA trys to do some FUDing about PGP.
> If they had broken PGP, they would *never ever* reveal it to the public.
> I guess they would not even tell the FBI, because the FBI is by no means
> as secretive as the NSA. Check the nuclear spies and VENONA. They didn't
> make it public for a very long time, because even nuclear secrets are
> worth less than a successful exploit of a critical crypto system.
==================================================================
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED] (PGP public key available.)
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R): "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/products/chimneysweep
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Encrypt then HMAC or HMAC then Encrypt?
Date: 13 Mar 2001 17:10:44 GMT
Bob Deblier <[EMAIL PROTECTED]> wrote:
> In the DHAES encryption scheme (from a paper by Abdalla, Bellare and
> Rogaway) the MAC is computed after encryption, and the decryption is only
> done after the MAC has been verified.
They are worried about chosen-ciphertext attacks. Which become much harder
if a MAC is applied to the ciphertext.
> This differs from what the previous replies said, so apparently there is no
> concencus. I guess cases can be made for each choice.
Yes.
-David
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Tue, 13 Mar 2001 18:33:57 +0100
"Joe H. Acker" wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > "Douglas A. Gwyn" wrote:
> > >
> > > Mok-Kong Shen wrote:
> > > > My point is essentially the following: If one can define and
> > > > quantify 'propagation of information' (rigorously), then
> > > > one must be able to measure the information content in
> > > > an arbitrarily given bit sequence in exact terms.
> > >
> > > But that's wrong. Information is inherently contextual (relative);
> > > it does not inhere in individual, out-of-context bit values.
> > > A given bit sequence might or might not convey information,
> > > depending on one's expectations. E.g. if you expect to receive
> > > a 0 bit and someone sends you a 0 bit, you do not receive "1 bit"
> > > of information (more nearly 0 bits, depending on how strong your
> > > a priori expectation is).
> >
> > But the original issue is to study 'propagation of
> > information', isn't it? If there is no information at the
> > start, then there can also be no propagation, right? So, if
> > there is a case where you can claim to be able to study the
> > propagation of information, there must be some information
> > at the start, at the end and in all intermediate stages
> > (the information may be of different quantity at different
> > points, being lost or augmented or whatever) and that
> > information must be exactly quantified, if your study is
> > to be formal and rigorous as you wanted. And that brings
> > back to my argument precisely.
>
> You seem to talk about informational content (as opposed to
> "information" in information theory) without taking the sign system and
> the belief states of the sign users into account. Perhaps indeed the
> latter can be abstracted from, but I don't think you can neglect the
> former.
>
> If I can *record* a random sequence, I can use it as an arbitrary sign.
> Any event that can be identified two times can be taken as a sign type.
> How many signals I can maximally encode in a given event, on the other
> hand, depends on the number of distinct states that can be identified in
> the event (number of bits of the sequence).
>
> But you point to an important distinction that has been neglected a lot
> in philosophy and semiotics. There are two different sorts of signs. One
> hand, there are representational signs: the meaning of the sign is
> mapped to the sign type (or, in case of indexicals, the sign token) by
> convention and the relation sign-significatum in some way is arbitrary.
> On the other hand, there are presentational signs: the sign token itself
> *exemplifies* or *encodes* the significatum. For example, if you draw 5
> points onto a blackboard, this sign does not only designate the number 5
> but also is an example of the number 5.
>
> It seems that in your argument, you're talking about presentational
> signs while others talk about representational signs. Indeed a random
> sequence *per se* does not convey much informational content in
> comparison to, say, a forest I'm looking at. But you can still establish
> a notion of quantified informational content for representational
> signs---relative to the sign system and a given belief state of the sign
> user. The crucial question in making this a "hard" science is wether and
> how much you can abstract from the belief states of the sign users.
> You'd want to have a methodology for determining the set of possible
> answers to questions or, in other words, the set of possible solutions
> to a given problem. I don't think this is possible in general, but in a
> given domain (certain types of problems or questions) it might be.
>
> I think Douglas A. Gwyn had something like this in mind: What is the
> minimum amount of work time to break cipher X? If you could find a
> cipher X for which you can prove that the minimum amount of time to
> break it is Y, and you could prove that any other possible answer to the
> question would be Y or >Y as well, then perhaps you could find a general
> way to compose a cipher out of X that is provably stronger than X. Then,
> of course, you can make it as strong as you like. This would work
> vaguely comparable to coding theory, when you make an unreliable channel
> reliable by chosing a good protocol and implementing error correction
> mechanisms.
I don't have enough philosophical and the like backgrounds
to argue with lots of your points. But I was basically taking
a very 'practical' user's point of view. In a given context
and for a given person, a given bit sequence has a certain
(zero or non-zero) information content. This can certainly
be (at least plausibly) accepted (otherwise the issue in
question would have had no sense). The question is whether
that notion can be paired with a practically realizable
quantitative measure for the purpose of carrying out a study
of the kind that Douglas Gwyn suggested, namely a formal
rigorous investigation of the propagation of information
through its processing done inside an encryption algorithm.
I don't exclude that certain reasonable qualitative measures
could be found under circumstances but doubt the feasibility
of finding the needed quantitative measures. In your last
paragraph you are postulating a cipher Y with a certain
property. I doubt that a (practically) reasonable and
non-trivial such Y exists. For any non-trivial Y, the time
to analyze would depend on the current state of development
of techniques that are applicable to it and that development
process could in principle be non-ending, depending among
others on the (public and secret) resources being spent. It
seems that to this day there has not been any unanimously
accepted exact quantitative and rigorous comparison of any
pair of well-known ciphers. In fact, finding a rigorous
quantitative and practically useful measure of strength of
ciphers has been an elusive goal, as has been discussed in
the group sometime back, if I don't err.
M. K. Shen
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Tue, 13 Mar 2001 18:42:34 +0100
Tim Tyler wrote:
>
> Frank Gerlach <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
> Personally I think a paper-and-pencil OTP is rather likely to be insecure,
> due to key-distribution problems. There's a good reason why OTPs are
> little used.
Except that the KGB and the BND use it. And the brits and the yanks used
it for heads-of-government communication (SIGSALY) during and after WW2.
It seems to me that OTP can be a practically strong system, if applied
with discipline.
I suspect the UKUSA alliance just hates OTP, because all their expensive
equipment is useless, if OTP is used properly. Because of that, they are
trying to undermine its credibility.
Consequently, their little 007 pawns get either an electronic device or
some kind of inferior hand cipher. If their field operatives used OTP,
third-world countries which are fixated on the english-speaking world
would start to do so too. And GCHQ and NSA would loose some of their
justification.
This is how it works properly: Use a lottery-type mechanical key
generator and write it down by hand with carbon copy. The top paper is
red, the copy is green paper. Burn the carbon paper. Red is always used
to send a message and green to decrypt. The sender must always use two
pens: one to write the ciphertext and one to mark the pad character
he/she has "consumed". I cannot see how you can accidently use a pad (or
part of it) twice.
Also, burn plaintext and used pads. This would even be a way around the
british RIP laws :-)
I strongly assume GCHQ has CD-ROM based OTP systems for voice
communications in their "poison chamber". They would be deployed in case
of extreme tensions or a major cryptanalytic success in RSA etc.
Maybe someone can point out the major mistakes of the russians which
lead to the Venona decrypts ?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Potential of machine translation techniques?
Date: Tue, 13 Mar 2001 18:42:53 +0100
"Henrick Hellstr�m" wrote:
>
> I believe that the redundancy of any natural or fictive languague is the
> biggest problem. I once wrote some code that would parse a user supplied
> document in order to create a word list, index the entries in that word
> list, and substitute each listed word in any other document for it's n bit
> index value, where n is the least number such that N < 2**n where N is the
> size of the word list. It was a fairly effective compression algorithm for
> text files.
If one considers redundancy to be a problem, one could
design the artificial language to minimize that. The
natural languages have lots of synonyms, but at least
for a restricted universe of discourse these wouldn't have
much effect on the fidelity of translations, I think.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Really simple stream cipher
Date: 13 Mar 2001 17:48:55 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Again, you're comparing PCFB to CBC+HMAC, while I'm comparing explicit
to implicit authentication. The two issues should not be conflated, as
you yourself have pointed out: PCFB can be used with either implicit or
explicit authentication. If you're going to use PCFB, the performance
of using it in an implicit mode is about the same as for an explicit mode,
I claim.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Really simple stream cipher
Date: 13 Mar 2001 17:50:47 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Henrick Hellstr�m wrote:
>If a MAC is present it must be recognized as such by the crypto software.
Why is this a risk? The crypto layer sets the crypto format.
And, if you get it wrong for some reason, the worst that happens is that
everything stops working, and then you know you need to fix something.
In other words, the system is fail-safe, rather than becoming insecure
when it fails.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Super strong crypto
Date: 13 Mar 2001 17:53:15 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Joe H. Acker wrote:
>I think Douglas A. Gwyn had something like this in mind: What is the
>minimum amount of work time to break cipher X?
Easier said than done. :-) This has been a holy grail in the field
for a long time. So far, noone knows how to prove useful lower bounds,
although it sure would be nice if someone found a way.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Encrypt then HMAC or HMAC then Encrypt?
Date: 13 Mar 2001 17:55:46 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
David A Molnar wrote:
>They are worried about chosen-ciphertext attacks. Which become much harder
>if a MAC is applied to the ciphertext.
Don't chosen-ciphertext attacks also become much harder if a MAC
is applied to the plaintext and if the decryption operation is
bijective?
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Date: Tue, 13 Mar 2001 10:00:35 -0800
Benjamin Goldberg wrote:
>
> You claim to have demonstrated a "procedure whereby the OverWrite
>
>
> ><snip>
>
>
> The difference between theory and practice is that in theory, theory and
> practice are identical, but in practice, they are not.
Let me ask you then, using OverWrite and my procedure of a dedicated
hard drive partition, etc., why will not the desired file be
thoroughly overwritten? Give us just one objection and we will
pursue it like a pack of dogs pursues the fox.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: GPS and cryptography
Date: Tue, 13 Mar 2001 09:57:51 -0800
Steve Portly wrote:
> Lets say you are using a satellite based cell phone system operating at 900
> MHZ. You agree in advance to transmit and receive from a particular terrestrial
> location at a certain time. The round trip signals from the satellite to the
> earth and back can be calculated so as to give an exact distance for any senders
> signal received. If this were a geosynchronous satellite the locus of possible
> points on earth a given distance from the satellite would be described as a
> circle. In the case of a LEO satellite that is moving in respect to the
> location on earth it becomes possible to pinpoint the transmission and reception
> point on earth.
You seem to be suggesting that the same message would be handled by
multiple satellites. If just one satellite is used, you can calculate
the correct time to send the message from any location to fake the real
time from the real location. If more satellites are used, you simply
calculate the correct sending time for each satellite and aim a separate
directional antenna at each satellite, sending separate copies of the
message, one to each, at the time calculated to create the correct
arrival time for the recipient.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: GPS and cryptography
Date: Tue, 13 Mar 2001 09:59:57 -0800
Paul Schlyter wrote:
> Then you're left with a key distribution problem: how can you make sure
> the receiver uses exactly the same bitstream as you do?
And how do you stop an interceptor from accessing that same bitstream?
DS
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
