Cryptography-Digest Digest #278, Volume #12 Mon, 24 Jul 00 05:13:01 EDT
Contents:
Re: New stream cipher ([EMAIL PROTECTED])
Re: New stream cipher ([EMAIL PROTECTED])
Re: Practical application of Ciphersaber (Was: RC4-- repetition length?) (Guy Macon)
Re: Random Appearance (Tim Tyler)
Re: Practical application of Ciphersaber (Guy Macon)
Re: Practical application of Ciphersaber (Guy Macon)
Re: Re: PGP US Versions Broken,no good?? (Chirag Patnaik)
Re: Practical application of Ciphersaber (Was: RC4-- repetition length?) (Guy Macon)
Re: RC4-- repetition length? (Guy Macon)
Re: New stream cipher ([EMAIL PROTECTED])
Re: New stream cipher ([EMAIL PROTECTED])
Re: Random Appearance (Guy Macon)
Re: PGP US Versions Broken,no good?? (Dave Howe)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New stream cipher
Date: Mon, 24 Jul 2000 08:02:48 GMT
Yes. You are right.
In article <[EMAIL PROTECTED]>,
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > The key is used to generate infinite byte sequence of key stream
using
> > finite group of the order 65536.
>
> How is it that you generate an infinite sequence from a finite
resource?
> Think the sequence will ever repeat? If it repeats does that make it
a
> repeating pad instead of a One Time pad?
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New stream cipher
Date: Mon, 24 Jul 2000 08:01:18 GMT
<[EMAIL PROTECTED]> wrote in message
news:8l6v3n$je5$[EMAIL PROTECTED]...
> AOTP-Alex One Time Pad stream cipher.
>
> Performance of this implementation is 190 Mb/sec.
> It was measured sending 256 byte in loop 777215 times.
> Some random comments:
> - Unless you want to be labeled as a Klewless Newbie(tm), I recommend
that
> you don't call it a "One Time Pad stream cipher". It's not a One
Time Pad,
> and at least here on this newsgroup, calling something a "One Time
Pad" when
> it's not is a definite sign of snake oil.
I choose 'One Time Pad' only for the sake of joke:-)
Right call may be 'Quasi One Time Pad'.
> - You should be applauded by releasing your files in something other
than
> Word format.
Done.
> - Your performance measurement "190 Mb/sec" is approximately
completely
> meaningless. Is this MBytes/second or MBits/second?
This is 190 Mbyte/sec.
> What hardware platform
> was this on? If it's 190MBytes/second on an 6 MHz IBM AT, well, I'm
quite
> impressed. If it's 190MBits/second running on a 2000MHz Itanium, I'm
not.
> One idea would be to normalize your measurements into cycles per byte
>encrypted. This number isn't the be all and end all of performance
> measurements, but at least it cancels out some of the variances due
to CPU
>clock speed
My platform is Intel Pentium II 267 Mhz.
Key schedule takes a lot of resources. Encryption or decryption of one
byte takes apr.
10-12 calls like 'mov'.
> - Again, I think you'll get more exposure to your ideas if 1) you
write
> them out mathematically (and just saying "how we do a group
operation" is
> not a specification) and 2) implement them in C -- hardly anyone in
the
> crypto community has a Delpha implementation available.
You are right. As long as algorithms design is still my hobby
I do not have time and money to develop some kind
of project documentation.
> - There's a serious problem in your Delphi code. Your
Alex.NextEffkey
> function updates the first 128 entries in the EffectiveKey array.
Please take into account that this 128 entries are words (2 byte).
This words are used as operands in multiplication of the group
of the order 65536 in a chained encryption algorithm.
> Your
> Alex.AOTP_encryption and Alex.AOTP_decryption routines use all 256
entries.
> The result of this is that every other 128 byte block is hardly
encrypted at
> all -- not at all if the EffectiveKey array happens to be zero there,
and
> with a fixed permutation if the EffectiveKey array happens to have a
nonzero
> value there. In either case, that's not what you want to do.
Not at all.
EffectiveKey is quasi infinite (OK! With cycles) sequence of bytes,
which in 256 bytes blocks goes to encryption procedure.
Each generated block depends on all previous blocks due to chaind
encryption
in the word architecture.
> I haven't done much serious analysis on the cipher itself -- but the
above
> should give you some thoughts...
--
poncho
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Practical application of Ciphersaber (Was: RC4-- repetition length?)
Date: 24 Jul 2000 04:10:11 EDT
Scott Fluhrer wrote:
>
>Guy Macon <[EMAIL PROTECTED]> wrote in message
>I also hope you are not going to design a real-life system based on what a
>couple of guys on sci.crypt said, but you will check it out, right?
No. Consider two childs dolls talking to each other through an
infrared link. I want to make it more difficult for a hacker to
be able to control the doll anmd make it say something that would
be out of character. Not a big deal if it's cracked, but even a
little security will weed out some attackers.
>> I am an embedded
>> systems programmer specializing in systems with a processor
>> that costs less $1 and a list price in the $20 to $50 range.
>> I like ciphersaber because it's easy to program, easy to
>> explain during a code review, and I don't have to pay for it.
>> I bury my passphrase in an internal layer of a masked IC; a
>> surface probe can't find it, but a dedicated attacker with a
>> lot of resources can - My crypto strength should be strong
>> enough so that digging for that passphrase is cheaper than
>> breaking the cipher, but not much better than that.
>
>Ummm, I hope that what's built into silicon is only part of the key you
>present to the underlying RC4 cipher -- that the rest of the key is supplied
>by the user or a public-key system and is transmitted to the receiver
>through some out-of-band mechanism. If the entire RC4 key is embedded into
>the chip, then it will always generate the same keystream, and that's easy
>to break. If you generate the rest of the key randomly on chip, and
>transmit it as salt, then all an attacker needs to break your systems is one
>of your chips.
Consider again the two dolls. No user to supply a key. No serious
attacker. Not much bad happens if an attacker suceeds. My only
choices are to keep the key on the chip. It's weak, but I don't know
of a userless system that isn't.
Then again, I am making a general purpose tool. Another project in the
works allows a little girl can store a secret in a toy with a secret
passphrase needed to read it. Now I have a situation where being able
to figure out what is in the chip will not help an attacker. I think
it would be seriously cool for a cheap toy to have strong cryptography
in it. And with recent changes to the export laws, I think that I can
do it.
>I'm personally ignorant of Ciphersaber, and so it may address this...
>
>>
>> Joseph Ashwood wrote:
>> >
>> >Well to make a potentially long summary quite short:
>> >
>> >1) RC4 is good for a few megabytes of data, but starts
>> >getting fairly bad around a gigabyte, very bad around 2
>> >gigabytes, probably breakable around 16 gigabytes.
>>
>> I have one system with a hardware RNG and a dedicated
>> communication channel and processor. I set it up so
>> that the sender is always encrypting random data (except
>> in the case where the random data contains a special 64
>> byte code - that get's discarded) and the reciever is
>> always decrypting and discarding the random data. Every
>> so often, the sender sends a fixed length message which
>> starts with the special 64 byte code. At 9600 bps and
>> 10 bits to form a byte, those limits above look like a
>> problem. Are they a problem in this application?
>
>Shouldn't be. If you sent zero data rather than random data, then an
>attacker could use the known weaknesses to determine if, in a multigigabyte
>span, if you sent a large number of messages or not, and do some traffic
>analysis based on that. With random data, that really isn't a problem,
>unless you might send a huge number of messages (gigabytes worth), and they
>have extremely low entropy.
>
>Oh, and how do you handle the case where one side goes down (loses power,
>say)?
Between the encrypting and decrypting software is handshaking and error
detection/correction software. If one side goes down the other side waits.
>If you use 10 bit bytes, you may want to consider 10 bit RC4 -- that is, a
>version with 1024 permutation elements, and all arithmetic done modulo 1024.
>Every analysis of RC4 that I've seen that addresses this indicates that the
>security gets better as the number of bits increase.
The extra two bits are just the normal serial overhead. I use 8 bit
processors, 4 bit processors, and hardware state machines, so 8 bits is
a good size for me.
>> >2) The average-case repetition length of RC4 is extremely
>> >long, the worst-case repetition length is still quite large,
>> >the best-case repetition length is nearly astronomical
>>
>> The 1-16 GB range mentioned above, is that best, average,
>> or worst case? Is there a way that I can avoid it by avoiding
>> certain week passphrases?
>
>The weaknesses I mentioned appear to be independent of passphrase. Certain
>passphrases (such as ones where the first two bytes sum to zero mod 256)
>cause artifacts to occur in the beginning of the keystream (which is why
>recommendation 3 is given). Other than that, there is no known reason to
>prefer one passphrase over another (except, of course, for guessability
>reasons).
>>
>> >3) If you're going to use RC4 make sure you throw away the
>> >first several outputs
>>
>> Is this a proplem with ciphersaber as well? I often do a
>> preprocessing stage where I add a random number of random
>> bytes to the beginning and end of my plaintext before I
>> encrypt it. For humans, that's enough, as they can plainly
>> see wher the garbaf=ge stops and the message starts. For
>> applications where a microprocessor needs the plaintext,
>> I use a special 64 byte start of message code that is never
>> found in the random data (I strip it out if it shows up).
>>
>> >4) Designing your own stream cipher is probably a fool's
>> >pursuit
>>
>> Alas, I have to do my own implementation, and on hardware
>> with a really strange instruction set. I am using someone
>> elses design (ciphersaber-1).
>
>You're fine. He said "designing your own stream cipher". You're not doing
>that, you're implementing a stream cipher -- one that has already been
>designed, and have been analyzed somewhat already, without any serious
>weakness being published yet.
Thanks for the advice! Much appreciated.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random Appearance
Reply-To: [EMAIL PROTECTED]
Date: Mon, 24 Jul 2000 07:58:23 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Joseph Ashwood wrote:
:> OTP's are subject to known-plaintext attacks, ...
: No, they are not, since the only plaintext that is "recovered"
: is exactly the plaintext that was already known. [...]
It depends on how you look at it. Recovering the plaintext is not the
only possible aim of a known-plaintext attack. Another goal is recovering
the key.
With an OTP, known plaintext attacks may be used very effectively to
recover the key (in the form of the corresponding section of the pad).
This attack could be employed if you wanted to try to spot regularities
in the keystream due to imperfections in the random number generation
technique, or if you subsequently wanted to attempt to forge a message
that used that section of the keystream.
>From this POV, a "naked" OTP is very weak. Few block cyphers will let
you get at any keybits if you only have a word or two of known plaintext.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Destroy Microsoft.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Practical application of Ciphersaber
Date: 24 Jul 2000 04:14:52 EDT
Trevor L. Jackson, III wrote:
>
>
>Your special code may be a problem. I'd recommend using each only once.
>For example, use a 128-bit prefix for each real message rather than a
>64-bit prefix.
>
>The first half of the prefix should distinguish the message from the
>surrounding noise, and the second half of the prefix will be the new
>prefix >value for the next message.
>
>This approach is quite simplistic and it has really bad problems (is
>worthless) in the presence of uncorrected channel errors. However,
>if the channel's transport mechanism supports error correction this
>approach will eliminate the anomalously high frequency of the special
>prefix code that will appear when the true data is a appreciable
>fraction of the channel capacity.
Makes sense to me. I have really good error detection and correction
with robust retry and resync capabilities, so your idea will work fine.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Practical application of Ciphersaber
Date: 24 Jul 2000 04:20:14 EDT
Scott Fluhrer wrote:
>Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>[Re: Guy Macon's method of marking messages within a long random stream by
>using a fixed 64 bit marker symbol]
>> Your special code may be a problem. I'd recommend using each only once.
>Question: why? What potential weaknesses are you worried about?
I was worried about the special code showing up as the output of the
RNG. I should have asked this before assuming that my first idea was
a good one, so let me ask now:
In the context of using cyphersaber (ARC4) to be constantly encrypting
either plaintext or the output of a hardware RNG, what is the best way
to insure that the reciever can tell plaintext from random data?
------------------------------
From: Chirag Patnaik <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Re: PGP US Versions Broken,no good??
Date: Mon, 24 Jul 2000 14:04:07 +0530
On 24 Jul 2000 00:46:54 GMT, Edward A. Falk thought that we should
read this:
:> -rw-rw-r-- 1 falk 927363 Apr 7 1999 pgp50i-unix-src.tar.gz
I compiled the same file and it worked without a hitch.
Chirag
--
http://india.4mg.com/ The very best of Indian Links.
http://www.chiragpatnaik.com/ A little about Me.
http://www.thehungersite.com/ Click and feed the Hungry.
____________________________________________________________________________
Crib, Because it is your right to do so.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Practical application of Ciphersaber (Was: RC4-- repetition length?)
Date: 24 Jul 2000 04:36:29 EDT
Joseph Ashwood wrote:
>>I also hope you are not going to design a real-life system
>>based on what a couple of guys on sci.crypt said, but you
>>will check it out, right?
>
>I second that. With computer security, there are no
>absolutes, everything that has been said should be thought
>of as certainly no more than a guideline, to truly determine
>if a protocol/algorithm fits your use, requires an in depth
>analysis of the system, and the creation of an accurate
>threat model.
Here is where I am in good shape. These are toys. The current
state of the art is:
[1] Do nothing. This has resulted in an occasional hacker being
able to make a doll spit out phrases from it's ROM at will.
The more granularity we put in (words or phonemes instead of
phrases) the more I dislike this.
[2] Use a simple PRNG (usually stolen from an Aplle 2, Commodore
64, or from GW-BASIC) that anyone here could bust in their
sleep. So far nobody has cracked this method. That's because
making IR boxes that cause toys to say embarassing things isn't
a high priority for any crypto expert.
Not much of a threat. I will be reusing this code, though, and I want
to design it so that a child with a shared secret passphrase can hide
secret information in a toys memory.
>> I bury my passphrase in an internal layer of a masked IC
>
>almost always a bad idea (dependant on the threat model), it
>is almost always necesarry to have some exclusive shared
>secret.
Sure wish I knew how to dfo that in systems without user input.
>> > I have one system with a hardware RNG and a dedicated
>> > communication channel and processor. I set it up so
>> > that the sender is always encrypting random data (except
>> > in the case where the random data contains a special 64
>> > byte code - that get's discarded) and the reciever is
>> > always decrypting and discarding the random data. Every
>> > so often, the sender sends a fixed length message which
>> > starts with the special 64 byte code. At 9600 bps and
>> > 10 bits to form a byte, those limits above look like a
>> > problem. Are they a problem in this application?
>It may be a problem, it all depends on the ability of an
>attacker to determine the timing of the real data, and the
>determinism of the random data (is it trivially
>distinguishable from random?). What you may want to do, is
>transfer data in triples of (command, distance, length),
>where the commands would be restricted to basically a bit
>designating real/offset&ignore, distance is the number of
>discarded RC4 operations befire the information(which will
>not even be sent), and length of the actual command or the
>data to be ignored. If the distance is chosen even semi
>randomly you will leave holes in an attacker's knowledge
>(unless they can determine the triples from the beginning).
I am not getting what you are saying. Maybe I am just tired,
but it isn't making sense to me. Could you elaborate a bit?
I sure do appreciate the advice so for.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: RC4-- repetition length?
Date: 24 Jul 2000 04:45:39 EDT
Jim Gillogly wrote:
>It's been said that it's
>possible to tell Cuban number-station transmissions from
>random because the typists generating one-time-pads did
>it out of their heads rather than according to some random
>hardware. However, it wasn't non-random enough to break.
I can tell you from personal experience how they generate
keys for DVD encryption at Cinram (worlds largest CD/DVD
replicator). During a staff meeting we would go around the
table and each pick a digit until we had enough. Being the
only one there with a clue about randomness, I used a ten
sided die for my digits. I suggested that all of the digits
be done with the die, but the pointy haired boss disagreed.
I like my present job much better.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New stream cipher
Date: Mon, 24 Jul 2000 08:21:21 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> [EMAIL PROTECTED] wrote:
>
> > Description.
> >
> > Idea of this algorithm goes up to Vigenere cipher.
> > Plain text stream is a sequence of bytes.
> > Key has length 256 byte. The key is used to generate
> > infinite byte sequence of key stream using finite group
> > of the order 65536.
> > Vigenere Tableau is implemented as multiplication table
> > of finite group of the order 256.
> >
> > Encryption.
> >
> > Byte of input plain stream and byte of key stream are
> > operands of group law of composition.
> > This gives one byte of output cipher stream.
> >
> > Decryption.
> >
> > Byte of input cipher stream and inverse to byte of
> > key stream are operands of group law of composition.
> > This gives one byte of output plain stream.
>
> Do I understand correctly that you build up a substitution table of
> 256*256 to transform the plaintext bytes according to group
> multiplication (the entries are product of row and column entries).
> So a plaintext character is used as the row entry and a key character
> is used as the column entry and the ciphertext character is the
> matrix entry. Questions:
>
Right.
> (1) Which group of order 256 do you use? Would it be better/worse
> to have in the table instead columns that are random
permutations?
This is the cyclic group of the order 256.
Its isomorph table of relates to a permutation.
Rendom colums do not give me solution for a*x=b as
group feature.
Certainly another finite groups may be used instead
of cyclic one.
>
> (2) Which group of order 65536 do you use? How do you generate
> the key stream? Does this key stream depend on its turn on a
> specific secret key agreed upon by the communication partners?
> How? This key stream must have a finite period. How large is
that?
>
In this case we use cyclic group of the order 65536.
But this may be any other group of the same order.
1. Both groups are transformed due to
key.
2. Key is used as input of chain encryption using
group of the order 65536 and word architecure.
Word output stream of key generator is used as
byte stream for encryption using group of the
order 256.
3. Finite period of key stream may be anys from the
set of cycles of the group of the order 65536.
So the period is not known if key is secret.
> Could you say something about the
predictability/unpredictability
> of the key stream? (You are having a particular PRNG here,
right?)
If key is known then generated group of the
order 65536 may be investigated for all
possible cycles. Then one can get know
to which cycle belongs the key.
If key is secret then this may be a hard
computational problem.
Thank you Shen.
Regards.
Alex.
>
> M. K. Shen
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New stream cipher
Date: Mon, 24 Jul 2000 08:23:36 GMT
Paul,
Thank you very much for your kindly
advise.
I will change the name asap.
Regards.
Alex.
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > AOTP-Alex One Time Pad stream cipher.
>
> You would be wise to rename it "Alex's Stream Cipher" since
> that is what it is. The name you've picked will only set
> off the snake oil alarms.
>
> I don't know if your cipher is strong. If it is, that's
> a reason to have it stand on its merits. It will never
> stand on its merits if you give it the wrong name, because
> people who understand crypto will never treat it as having
> any value so long as you do that.
>
> paul
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Random Appearance
Date: 24 Jul 2000 04:55:54 EDT
Mack wrote:
>
>>"THE PAD MAY BE REUSED????"
>>
>>Which part on "One Time" are you having trouble understanding?
>
>In any scheme it is possible for mistakes to happen.
>If a OTP is reused by accident or design it is subject
>to a known-plaintext attack.
In any scheme it is possible for mistakes to happen. If DES
is used with the key appended to the cyphertext by accident or
design it is subject to a very trivial cryptanalysis attack.
So?
>This thread started out as an inquiry about a cryto system that produced
>output that looked 'normal'. I gave an example of such a system
>that proved useful in practice.
Maybe you did, but you also made a claim that an OTP is vulnerable
to a known plaintext attack. Now you are waving your hands rather
than admit your error.
A Riddle: Who is more ignorant than a clueless newbie like me?
The Answer: Someone who refuses to learn from the clueful.
------------------------------
From: Dave Howe <DHowe@hawkswing>
Crossposted-To: alt.security.pgp
Subject: Re: PGP US Versions Broken,no good??
Date: Mon, 24 Jul 2000 09:59:52 +0100
Reply-To: DHowe@get_email_from_sig
In our last episode (<alt.security.pgp>[Sat, 22 Jul 2000 21:14:24
-0700]), Sundial Services <[EMAIL PROTECTED]> said :
>Frankly, I doubt that there is very much in the way of commercial (i.e.
>non-classified) encryption that the NSA cannot break. If it were
>otherwise, I'd be having some serious questions about what all that tax
>money is being spent for.
Interesting point of view - so, only the US military can develop a
secure encryption method? all the rest of the world, and indeed all
the academics, commercial companies and other interested parties in
the US are incapable?
>But let's face it -- is an agency like that going to be decrypting
>everything out there that is encrypted, just for their jollies or just
>because they can? Not bloody likely.
Largely a cost issue. Assume that their entire budget could break one
2048 bit private key every day (not actually possible in most people's
opinion). They now have to pick 365 keys for this year. I will *not*
be on that list - I have never even sent a PGP encrypted message to
the US, and if I did, I wouldn't rank alongside the valuable
commercial transmissions that would give US companies a head start in
international negotiations.
>And even so, does that really
>alter the effectiveness of PGP for -your- applications that require the
>use of crypto? Just how stringent ARE your cryptographic requirements?
indeed.
>There are millions of encrypted messages sent each day, just like there
>are tens of millions of doorknobs.
Not quite so many (unless you include SSL) but with a decent
integration (like PGP bundled with Outlook for example) it *could* be
millions.
------------------------------
** 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
******************************
