Cryptography-Digest Digest #772, Volume #10 Mon, 20 Dec 99 10:13:01 EST
Contents:
Re: An attack on the WTLS SHA_XOR_40 MAC algorithm (David Hopwood)
Re: compression & encryption (SCOTT19U.ZIP_GUY)
Re: First Bijective Arithmetic Compression (SCOTT19U.ZIP_GUY)
Re: First Bijective Arithmetic Compression (SCOTT19U.ZIP_GUY)
Q: transcendental pad crypto ("dls2")
Re: Analogue encryption ("dls2")
Re: Are thermal diodes as RNG's secure (Bo D�mstedt)
Re: Q: transcendental pad crypto (John Savard)
Re: First Bijective Arithmetic Compression ("Gary")
Re: Casio's Multi Dimensional Space Rotation encryption (Hideo Shimizu)
Re: discrete logorithm reduction to factoring (Henning Makholm)
Re: Analogue encryption (SCOTT19U.ZIP_GUY)
Re: Cryptanalysis (SCOTT19U.ZIP_GUY)
Re: Casio's Multi Dimensional Space Rotation encryption (CLSV)
Re: S-Box evolution (Glenn Larsson)
Re: S-Box evolution (SCOTT19U.ZIP_GUY)
Re: Analogue encryption (CombatXeroxRepairman)
----------------------------------------------------------------------------
Date: Mon, 20 Dec 1999 05:24:11 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: An attack on the WTLS SHA_XOR_40 MAC algorithm
=====BEGIN PGP SIGNED MESSAGE=====
David Wagner wrote:
>
> Good catch. Yeah, I agree: the so-called WTLS 'XOR MAC' is seriously
> flawed, and definitely should be eliminated with all possible haste.
>
> Submitting your result to WAP might be useful, to keep them honest.
I have done; I'll also point them to Saarinen's paper and outline your
repeated ciphertext attack.
> Last I heard, they were a semi-secret design committee, and one always
> has to wonder about the effects of secrecy & politics on the resulting
> standards.
Yes, the telecoms industry doesn't exactly have a sterling record in that
respect :-(. It could be much worse, though; unlike GSM, the flaws seem
to due to cluelessness, rather than deliberate attempts to weaken the
protocols.
> You might also be interested in the following paper:
> Markku-Juhani Saarinen, ''Attacks against the WAP WTLS protocol.''
> 1999 Communications and Multimedia Security conference.
Thanks, that's useful (I got a copy from the author).
Has anyone checked whether the elliptic curves that do not have seeds given
for them are of any special form, BTW?
> This paper shows some different attacks on the 'XOR MAC', and also
> describes several other security misfeatures of WTLS.
[...]
> If you repeat a ciphertext block that corresponds to some known plaintext
> block (perhaps because it is part of a predictable TLS header or guessable
> HTTP request or somesuch), you can even control the inserted plaintext
> block to some extent.
Note that it's quite easy to get known plaintext for the WAP protocols;
because they are datagram-based, any headers automatically line up with
the WTLS packets.
> You can also apply similar tricks to any sequence of consecutive
> ciphertext blocks, if you like.
>
> You can use this trick to do cut-and-splice attacks, a la Bellovin's
> IPSEC work. For instance, suppose we have the ciphertext U V W that we
> want to get decrypted for us. We wait until we get ahold of the channel,
> perhaps using an echo feature in some application like suggested in
> M.-J. Saarinen's paper. Then, when we see ciphertext X Y Z, we modify
> it to become X (10 copies of U V W X) Y Z.
At first I didn't see how this could be applied in practice, but in fact
there's a echo feature in HTTP (and whatever the WAP equivalent is).
Suppose you have an <a href="http://..."> in a page delivered over WTLS.
If the user clicks on the link, the URL will be revealed as plaintext
in a new request. If the attacker inserts the ciphertext blocks in the
page at the right place, the corresponding plaintext will be included
in the URL.
(Note that this doesn't necessarily require much guesswork; often the
attacker can access the same pages, apart from any user-specific secret
information, as the legitimate user. He/she might be able to tell which
page is being viewed by length or timing information.)
> This attack will not be detected by the XOR MAC, and it lets us read any
> traffic we like.
Very neat (and an excellent demonstration of why it's so important to
have strong integrity protection as well as confidentiality). This also
applies to the null MAC, of course.
You don't even need to actually do an active attack that modifies the
packet contents, I think; just sending extra packets with a forged source
address at approximately the right time will work, because the receiving
WTLS stack will discard the packets with the same sequence numbers from
the real sender.
> At this point I would claim it should be clear that the 'XOR MAC' is
> fatally and fundamentally flawed.
Yes, although it appears that the best I'll be able to get is a "SHOULD NOT"
use, rather than "MUST NOT" (a bit wishy-washy if you ask me, but better
than nothing).
Also, in order to change anything, I have to submit a formal Change Request
via an employee of one of the WAP forum member companies. Someone has
volunteered, but it seems to be a rather heavyweight process. (The more
standards bodies I see, the more the IETF seems like a breath of fresh air.)
So, does anyone reading this know of any other problems with WTLS that
can be fixed at the same time? I already know about the ones in Saarinen's
paper, which were:
- A chosen plaintext attack against low-entropy blocks, using the fact
that the IVs are known or predictable.
- SHA_XOR_40 with a stream cipher (already fixed).
- Exportable DES keys had only 35 effective key bits (already fixed).
- Bleichenbacher's attack against PKCS #1 (already fixed by replacing
the master secret with random bytes when the PKCS padding is invalid).
- Unauthenticated alert messages; this also allows blocks to be deleted
without detection.
- For exportable keys, the IV of any block is known exactly.
- record_type is not encrypted.
- PKCS #5 padding provides guaranteed known plaintext.
The spec is at http://www.wapforum.com/what/technical.htm#Proposed
- --
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
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOF29HDkCAxeYt5gVAQEbYgf/c3cfgP91kmqAzkHqjkHUQ3DiOm6RxjpE
L52OSxSJFo60YwiDwmNhJlmuQ36Mrq6Mt2PyFSjyrlNpV5AcHi1/9kDOdU5LwCkO
AAiusCRLuuwdQoA20HWBK9WvxIYGloVmA/os4nxWvw4VfLTK4lM8dPWzkP/Pp1Dj
UUJYcFp5lQNb47PxD/MRjnQY/Q2kvsdV24huiNaTNZ3DjqhiMsAnuVmWWDTbYSry
huEdLETDdRl6G+DrgyL2lQnZSp/j5TrrQ1tub/yuuJ536itEzfUjuEwJYuX39iTg
hCr4GvjRf9LQRbkjAePgb2wBI/U2M4aUCYq/tPG6G1zS7n+6kFKSGg==
=iz5G
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: compression & encryption
Date: Mon, 20 Dec 1999 07:20:12 GMT
In article <[EMAIL PROTECTED]>, lordcow77
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
>> lordcow77 <[EMAIL PROTECTED]> wrote:
>> : Pray tell, but how would one decrypt just the first two bytes
>> from a
>> : single block encrypted with a block cipher? You can't, and
>> that's why
>> : your "mechanically reject" comment is just wrong.
>> Simple: pick a key to be tested and decrypt the first block.
>> Depending on
>> the size of the block, that will /probably/ give you the first two
>> bytes
>> of the message when decrypted with that key.
>> Placing mathematical constraints on the keys that can be valid by
>> using this technique is likely to be more useful to an analyst than
>> *actually* decrypting and rejecting individual keys.
>> --
>
>Exactly. You still have to decrypt the entire first block. The time
>complexity of breaking the cipher by brute force remains asymtopically
>the same. The analyst does have to "*actually*" decrypt the test block
>using individual keys.
Depending on the encryption algorithm one may be able to eliminate
whole classes of keys. It doesn't follow that one has to do a full blind
search. The human mind gets very inventive finding short cuts. Especailly if
one is dumb enough to make it easy by using something like fixed headers.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: First Bijective Arithmetic Compression
Date: Mon, 20 Dec 1999 07:25:59 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Gary <[EMAIL PROTECTED]> wrote:
>
>: As I've replied to David PLEASE, PLEASE, ...PLEASE show me a compression of
>: any file X that invokes rule 4 when it is decompressed!
>
>You want David to post a hex dump?
>
>I'm not sure what good you think that will do you.
What would you do with it. It is not that hard to do your self.
I don't see what your driving at.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: First Bijective Arithmetic Compression
Date: Mon, 20 Dec 1999 07:28:50 GMT
In article <83j65q$69b$[EMAIL PROTECTED]>, "Gary" <[EMAIL PROTECTED]>
wrote:
>Tim Tyler wrote in message ...
>>Gary <[EMAIL PROTECTED]> wrote:
>>
>>: As I've replied to David PLEASE, PLEASE, ...PLEASE show me a compression
>of
>>: any file X that invokes rule 4 when it is decompressed!
>>
>>You want David to post a hex dump?
>
>Email me a file which I can compress with David's compressor and when I
>decompress it invokes rule 4!
>
>>
>>I'm not sure what good you think that will do you.
>
>
>I think you both realise what good it'll do!
>
No I don't have the foggest idea of what your drivng at?
if you just generate the set of all binary files 4 bytes in lenght and comress
and decompress everyone of these you will get several candidates. You
pick the one of your choice.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: "dls2" <[EMAIL PROTECTED]>
Subject: Q: transcendental pad crypto
Date: Mon, 20 Dec 1999 01:19:39 -0500
"Also, a computer-based pseudo-random number generator
does _not_ qualify as a true one-time pad because of its
deterministic properties. See `pseudo-random number
generators as key stream'." -Cryptography FAQ, 4.4.
Do transcendental numbers qualify as pseudo-random, or
as truely-random, for purposes of one-time pads?
Or does the answer depend on which transcendental number
is chosen, and how it is applied?
Derrick Shearer
[EMAIL PROTECTED]
------------------------------
From: "dls2" <[EMAIL PROTECTED]>
Subject: Re: Analogue encryption
Date: Mon, 20 Dec 1999 02:11:12 -0500
<amadeus @DELETE_THIS.netcomuk.co.uk (Jim)> wrote:
> <[EMAIL PROTECTED]> wrote:
> > If a pseudo one time pad is used to generate a waveform
> > that overlays a voice could this ever be as percievably
> > secure as digital encryption?
>
> No. Which is why all serious ciphony systems are digital or
> at worst digitally-coded and encrypted vocoders. (And if
> you've ever used a secure 'phone incorporating a vocoder,
> you'll know why I said 'at worst' !!!)
I've never used a secure phone incorporating a vocoder,
so why did you say "at worst"?
Derrick Shearer
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Bo D�mstedt)
Subject: Re: Are thermal diodes as RNG's secure
Reply-To: [EMAIL PROTECTED]
Date: Mon, 20 Dec 1999 10:53:48 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>"Better to remain silent and be thought a fool than to speak and
>remove all doubt."
HeHe !
Picture of a noisy Zeener diode:
http://www.protego.se/schematics_a.htm
Bo Domstedt
Protego Information AB
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Q: transcendental pad crypto
Date: Mon, 20 Dec 1999 11:07:29 GMT
On Mon, 20 Dec 1999 01:19:39 -0500, "dls2" <[EMAIL PROTECTED]> wrote:
>Do transcendental numbers qualify as pseudo-random, or
>as truely-random, for purposes of one-time pads?
Pseudo-random, since calculating the value of a transcendental number
is a deterministic process. And an inefficient one, for the level of
security provided.
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: First Bijective Arithmetic Compression
Date: Mon, 20 Dec 1999 12:11:40 -0000
Sorry David,
You're right and I'm wrong.
>From what I can see there is no way I can gain any information from your 1-1
compression.
I finally understand now what you're trying to do.
I have only noted that all files with the same header have the same
compressed header, allowing a compressed text attack. However you have
always stated that the compressor doesn't add to the security of encryption
it just doesn't allow an attacker to gain any information.
My apologies again.
(An RLE version would have been easier to analyse :))
------------------------------
From: Hideo Shimizu <[EMAIL PROTECTED]>
Subject: Re: Casio's Multi Dimensional Space Rotation encryption
Date: Mon, 20 Dec 1999 21:36:12 +0900
CASIO don't disclose any detail. Only outline.
I feel it's not enough for attack.
> Has anyone tried to analyze the algorithm?
> (I'm still busy trying to understand it.)
>
> Regards,
>
> CLSV
--
Hideo Shimizu
------------------------------
From: Henning Makholm <[EMAIL PROTECTED]>
Crossposted-To: comp.theory
Subject: Re: discrete logorithm reduction to factoring
Date: 20 Dec 1999 14:27:00 +0100
[EMAIL PROTECTED] (Bodo Moeller) writes:
> The Shor quantum algorithm for discrete logs works in groups (Z/nZ)*
> with n composite or prime.
Does that mean "... with n > 1"? I could live with that restriction...
--
Henning Makholm "Det ville v�re s� let at skabe et
paradis. En fredfyldt, harmonisk verden."
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Analogue encryption
Date: Mon, 20 Dec 1999 14:55:37 GMT
In article <83kkt8$[EMAIL PROTECTED]>, "dls2" <[EMAIL PROTECTED]> wrote:
><amadeus @DELETE_THIS.netcomuk.co.uk (Jim)> wrote:
>> <[EMAIL PROTECTED]> wrote:
>> > If a pseudo one time pad is used to generate a waveform
>> > that overlays a voice could this ever be as percievably
>> > secure as digital encryption?
>>
>> No. Which is why all serious ciphony systems are digital or
>> at worst digitally-coded and encrypted vocoders. (And if
>> you've ever used a secure 'phone incorporating a vocoder,
>> you'll know why I said 'at worst' !!!)
>
>I've never used a secure phone incorporating a vocoder,
>so why did you say "at worst"?
>
>
H said "at worset" to give the impression that he is an expert
in the field and that you should kiss his ass becasue of his great
knowledge. I guess its a politically correct way to say "I'm fucking
smarter than you asshole". But I tend to be more direct it helps
to read old issue of MAD magazine to find out what the pompous
ones really mean when they write.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Cryptanalysis
Date: Mon, 20 Dec 1999 15:04:21 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>[EMAIL PROTECTED] wrote:
>>
>> I'm doing a paper on Cryptography and It's Affect On The Information
> ^^^^ should be Its
>> Age. It's mostly about crypto in regards to current US law,
>
>Now is not a particularly good time to do that, bearing in mind that the
>law appears to be going to change quite radically in January (although
>we don't have the full details yet).
>
>> however, I have a brief primer on crypto in the first few pages.
>> I need to source everything that is not an opinion. I remember reading
>> something a few weeks ago about how cryptosystems are often created to
>> meet a purpose and you wouldn't use a difficult cryptosystem to apply
>> to a message to send info that will expire in one week.
>
>You may have read that, but you should also be aware that many practicing
>cryptographers strongly disagree with it. Here are five reasons why:
>
>1. The length of time to break an algorithm (if it is feasible to break)
> depends on how much processing power the attacker has, which in
> general you don't know. It's not possible to create a cryptosystem
> that is 'only just strong enough' to last a particular length of time.
> We (that is, the public cryptographic community, and probably the
> private one as well) don't even know how to create a system that is
> 'only just strong enough' to require a given amount of work to break.
> In that situation, the only sensible strategy is over-engineering.
Gee this does not seem in line with the crap the AES types
or PGP lovers spout "the only sensible strategy is over-engineering"
that would never fly here.
>
>2. Historically, algorithms that were not designed from the start to have
> conservative security goals have fared very poorly. If they are broken,
> they tend to be broken catastrophically.
Where would you place current PGP in the scheme of things.
>
>3. For symmetric crypto, in particular, it costs very little if anything
> to use a very strong algorithm as opposed to a weak algorithm, or as
> opposed to one that seems to be on the edge of being breakable. For
> public key algorithms, longer keys do require more processing time,
> but you can choose *very* conservative key lengths and well-respected
> algorithms, and still have the encryption (or signature verification,
> or whatever) taking only a small fraction of a second per message on
> a low-end PC.
>
>4. Often parts of cryptosystems are re-used for a different purpose to the
> one the designer or specifiers originally intended, or the value of the
> messages that are sent increases, or their value was underestimated in the
> first place. It is more productive to design general purpose protocols,
> algorithms, key management systems, etc., and to apply the limited amount
> of available time and expertise of cryptanalysts on those relatively
> few systems, than for every application writer to "roll their own" - and
> it is a demonstrable fact that the results are usually more secure. (This
> approach also has other advantages such as promoting interoperability
> between applications.)
> A general-purpose system must be capable of protecting data of very high
> value and long lifespan, but it seems to be much easier to do this than
> to design and analyse lots of application-specific systems independently.
>
>5. Part of the value of crypto is determined by the trust that its user
> base places in it. It's not sufficient for a system to be 'secure enough'
> in the designer's opinion; it has to be *demonstrably* secure to the
> satisfaction of its users (who, unless there is only one user, will have
> different levels of paranoia or security awareness).
> If you design a cryptosystem that is less secure than you could have
> made it, you are asking for someone to point out, often loudly and
> publically, that it is not secure enough for them - or even worse, to
> claim that you deliberately weakened it.
>
This is a good write up no wonder it did not originate in the US.
>
>For providers of cryptography who are:
> - based in the U.S., and
> - want to export their product, and
> - are not prepared to jump through the hoop of printing out source and
> getting it scanned overseas, or who have a closed-source product, and
> - accept that their export market is going to be limited by the fact
> that us foreigners are well aware that crypto that goes through the
> current U.S. export process is weak,
I get lots of hate mail from the current crop of PGP lovers that
PGP is exportable and totally safe since they claim the governemnt
is giving up on strong crypto. And comments from you on this one
I would enjoy hearing.
>
>there was possibly an argument for using crypto that is "not difficult".
>But it looks as though even that argument might go away soon.
>
>> My line is "The basic theory is to make a cryptosystem which can be
>> applied with the least amount of effort but is impractical to break
>> before the information becomes irrelevant using the currently available
>> equipment."
>
>As a general strategy this is a fundamentally bad idea. To summarise the
>most important (IMHO) of the reasons above:
>
> - You may overestimate how impractical the cryptosystem is to break. It
> is very easy to do this unless you apply a generous safety margin,
> paying particular attention to possible weak links.
> - The amount of effort needed to make it impractical to *ever* break
> the cryptosystem (at least by a cryptanalytic or brute-force attack)
> is probably not much greater than the "least amount of effort" as
> defined above.
>
>> I need to source that, anyone know a web page, book, magazine article,
>> etc which covers the above? I can't remember for anything where I saw
>> that info.
>
>I've noticed that there are far too many papers recently that decide
>what the conclusion should be before doing any research. :-(
You just noticed this recently. Its a very common practive
here in the US.
>
>- --
>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
>
>"Attempts to control the use of encryption technology are wrong in principle,
>unworkable in practice, and damaging to the long-term economic value of the
>information networks." -- UK Labour Party pre-election policy document
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: Casio's Multi Dimensional Space Rotation encryption
Date: Mon, 20 Dec 1999 14:18:42 +0000
Hideo Shimizu wrote:
> CASIO don't disclose any detail. Only outline.
I really can not understand why they would disclose
a part of the algorithm but not the details.
It just does not make any sense.
> I feel it's not enough for attack.
I don't think so either. Given the information on
the website any analysis would be useless.
However I have the uneasy feeling that the algorithm
is based on the weak principle that if something looks
complex it will be difficult to decipher.
Regards,
CLSV
------------------------------
From: Glenn Larsson <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: S-Box evolution
Date: Mon, 20 Dec 1999 15:21:14 +0100
Pelle Evensen wrote:
>Define "extracted" in step 1.2?
As in generated by another value in some manner.
Suppose you have a 128 bit key; expand it in some manner
or add some constants to it, then run it through, say,
SHA-1 and you have a 160 bit value = 128 bit key + 32
bits of data you can use for various things. This is a
thing i've not decided yet.
Once again; This is just an idea, there are several other
ideas one can use - be creative.
>This sounds remarkably much like a some kind of stream cipher
>with a wide block and possibly a feedback loop.
It's not implemented in any crypto function yet, The block
size in the cipher i've thought of is of variable size.
> Describe the "S-box" of the first paragraph?
Sure:
1. The array A() is load with values from 0 to 255
For Z = 0 To 255
A(Z) = (154 + Z) Mod 256
2. Then the SBoxes are pregenerated in this way:
(Pregenerated can mean; by me and distributed with
the executable file, or the first time when started)
For P = 0 To SBoxSeed
For x = (67 + P) To 3 Step -1
For Z = 0 To 255 Step (4 + x)
s = Z + x
If s > 255 Then s = s Mod 256
C = A(s)
B = A(Z)
A(s) = B
A(Z) = C
Note:
- SBoxSeed = Value from 0 to 255
- The values 154 and 67 are not choosen at random
Remember; my queston was about S-Boxes in general.
Disclaimer: I'm a beginner, and as such, i have the right
to make mistakes =o)
Regards,
Glenn
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: S-Box evolution
Date: Mon, 20 Dec 1999 15:26:13 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Glenn Larsson <[EMAIL PROTECTED]> wrote:
>
>: I was playing around with an S-Box i designed earlier and started
>: thinking about the concept of having an evolving function in it.
>
>: 1. Generation
>: - The (key dependent?) SBox is generated in some manner.
>
>Key-dependent S-Boxes are your friend.
>
>: 2. "Evolution"
>: - For each cryptoblock (or round perhaps), there is a function
>: (Controlled by the IV) that "evolve" the SBox in some way;
>: Rotations, Addition, Hashing - just some ideas.
>
>You seem to be talking about "evolution" in the sense of "change over
>time".
>
>Doing things dynamically with your s-boxes /may/ mean too much work
>at runtime - given the set of constraints s-boxes usually have to
>operate under.
>
>/Perhaps/ cycling through a predetermined list would be enough for
>whatever security benefits you're trying to obtain.
>
>: 3. Flaw detection
>: - Perhaps another function that checks for "undesirable
>: things" - if encountered; go back to step 2.
>
>: Any direct ideas? Is the "Flaw detection" feasible? Does it
>: already exist somewhere? if so, where can i find some info
>: on that?
>
>There's a significant (and complex) literature on the constraints which
>apply to s-box design - and to "bent" boolean functions in general.
>
>A few such pages:
>
>http://www.iicm.edu/jucs_1_2/the_relationship_between_propagation/html/paper.ht
>ml
>
>http://www.cs.uow.edu.au/people/grc01/jennie/lifework.html
>
>AFAICS, most such constraints apply to individual s-boxes. I believe it
>/should/ be possible to lift some of the constraints on the s-boxes
>themselves if other constraints on their arrangement were employed.
>
>I don't know if people have tried doing this - so this is just idle
>speculation on my part - but I would welcome any information about this.
I am sure you may have looked scott16u it may be easier to look at
than the scott19u version which is just much much bigger but
the whole security is based on the building of a single cycle keydependent
S-box of 16 by 16 bits. The key is such that any possible single cycle S-box
of that size can be used with the "password phrase of your choice"
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: CombatXeroxRepairman <[EMAIL PROTECTED]>
Subject: Re: Analogue encryption
Date: Mon, 20 Dec 1999 00:18:34 -0800
Gary wrote:
> In old B&W films telephone conversations were scrambled.
> Since digital modems weren't around then what did they do?
> Did they overlay waveforms over the voice?
> How did they synchronise? Did they have a tracking control on the phone?
> If a pseudo one time pad is used to generate a wave form that overlays a
> voice could this ever be as percievably secure as digital encryption?
> Gary :)
There was a NSA device that scrambled voice in a way that could be
transmitted over a normal 0-3khz line. The
output sounded like very strange inverted speech. This was very useful for
HF voice long distance links. Rumor was that it was broken by the USSR
because we stopped using the system in the early 80's.
KY-75 Old generation (PARKHILL) of Secure Voice CRYPTO being replaced
by
KYV-5 (ANDVT).
KYV-5 New Secure Voice (ANDVT) CRYPTO that replaces KY-75 (PARKHILL).
I believe it was only cleared to SECRET level traffic.
------------------------------
** 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
******************************
