Cryptography-Digest Digest #977, Volume #11 Thu, 8 Jun 00 15:13:01 EDT
Contents:
Re: Thoughts on an encryption protocol? (Mike Rosing)
Re: 3DES performance ([EMAIL PROTECTED])
Re: Some dumb questions (Mok-Kong Shen)
Re: Cipher design a fading field? (Mok-Kong Shen)
Re: Arithmetic Coding (Mok-Kong Shen)
Re: Comfort csybrandy ! (Was: Attack on SC6a (sci.crypt cipher)) (Simon Johnson)
Re: equation involving xor and mod 2^32 operations (Mike Rosing)
Re: Arithmetic Coding (tomstd)
Re: Random IV Generation (tomstd)
Re: testing non linearity of arithmetic-logic combinations (tomstd)
Re: Some dumb questions ([EMAIL PROTECTED])
Re: 3DES performance (Paul Rubin)
Re: DES question (Mike Rosing)
Re: Enigma Variations (Jim)
Re: Enigma Variations (Jim)
Extending the size of polyalphabetic substitution tables (Mok-Kong Shen)
Re: DES question (Mok-Kong Shen)
Re: Digital Certificates (Paul Rubin)
Re: PK analogue for passwords ([EMAIL PROTECTED])
Re: Cryptographic voting (Dennis Paul Himes)
----------------------------------------------------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Thoughts on an encryption protocol?
Date: Thu, 08 Jun 2000 12:17:06 -0500
Dido Sevilla wrote:
> Frankly, I don't think all the effort to implement a PK system is worth
> it in this case. There will only be 34 client terminals, one per
> building, and given the financial constraints of my employer, it will be
> a very long time before any more will be necessary. These are also not
> so widely distributed, so going to every terminal should not take more
> than a day.
Sounds like a reasonable choice of parameters then.
> Any websites or other online docs I can look at for stream ciphers and
> cryptographically secure PRNG's?
You'll like this one:
http://www.cacr.math.uwaterloo.ca/hac/
Chapters 5 and 6 look like what you want.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 3DES performance
Date: Thu, 08 Jun 2000 17:22:54 GMT
Panu, Wei Dai's Crypto++ library has 3des timings available on his
webpage. (His .sig suggests cryptopp.{com,org} -- I forget which. I got
there fastest by a google search, at eskimo.com/~weidai I *think*. :)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Thu, 08 Jun 2000 19:41:47 +0200
Volker Hetzer wrote:
> Mok-Kong Shen wrote:
> > Yes. But one should note that, after picking a pair, it is yet fairly 'difficult'
> > to determine whether they belong to the same segment of OTP. Thus
> > the resource required in the whole undertaking is going to be extremely
> > huge in my view.
> Depends on how you define "fairly". If I had to try it I would write
> a program that takes a pair, tries to break it and checks success by
> examining the character distribution of the decrypted messages.
> There may be many different possible decryptions.
> Then I'd try to compute a number indicating the degree of conformance
> to the character distribution.
> Given n messages (i.e. (n(n-1))/2 pairs) I'd rank the decryption results
> according to that value. Then I'd do a manual inspection of the top
> messages.
> The shorter the messages the harder this gets.
Of course your point of 'relativity' of my word 'fairly' is justified. An
encryption scheme may be crackable in one environment though not
in another because of resources. If I understand correctly, you would
write a program to try to break the xor of an arbitrary pair and, if
you can break it, then you have identified that the originals belong the
same segment of OTP. Is that right? (But then you have succeded
in fact to read the messages.) Now could you give some sketch of
ideas that underly such a program? (Please note my assumption
that you have the frequency distribution of single characters, but
nothing else. You have the xor of a pair. But from the start you have
no idea at all of whether they belong to the same pair. If they don't,
then you have the xor of two messages xored with two OTP segments.
Note now that xor of two OTP segments can be 'anything', according
to the definition of OTP.) Could you give some tiny hypothetical but
concrete examples to clearly illustrate (roughly) these ideas?
(It was implicitly my point that the invention of these ideas are very
hard.) Thanks in advance.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Thu, 08 Jun 2000 19:42:07 +0200
wtshaw wrote:
[snip]
> Thereafter, it is merely like a subset of my 3-way cipher with a simple
> alternation of modes. With Slidefair, there are only 3 basic
[snip]
Could you give a pointer to your 3-way? Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Arithmetic Coding
Date: Thu, 08 Jun 2000 19:41:54 +0200
steffen markert wrote:
> Does anybody know about an implementation in C
> or a book or a paper with informations about adaptiv
> arithmetic coding?
D. Solomon, Data Compression. Springer, 1998.
M. K. Shen
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Comfort csybrandy ! (Was: Attack on SC6a (sci.crypt cipher))
Date: Thu, 08 Jun 2000 17:34:27 GMT
> You can't just throw sboxes at a cipher and make it secure...
eh?
I agree that 'throwing sboxes' at the cipher isn't the ideal way to
create a cipher. But in this case, its almost certainly going to
improve the security of the cipher.
If i'm correct, your attack depends souly on the fact his cipher is
just too linear, an s-box is a good non-linear step to include.
Is there any reason it wouldn't be more secure?
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: equation involving xor and mod 2^32 operations
Date: Thu, 08 Jun 2000 12:38:33 -0500
Scott Contini wrote:
> Interesting problem...
I'll agree with that :-)
> which is of the form
>
> y xor (y + 1) = c
This is a good way to generalize it. Take
> for y = (a + x) .
and instead of 1 put d where d = b-a.
Then we have y xor (y + d) = c.
Since y+d is mod 2^32 (or let's generalize that so we can start small
to 2^n) we can write out each bit of the sum as a coefficient. i.e.
y + d = (y0 + d0) + 2*(y1+d1+ca0) + 4*(y2+d2+ca2) + ...
where cai is the carry from the ith addition and results are taken mod 2
now perform the xor in bit by bit fasion: y0 xor (y0+d0) = c0,
y1 xor (y1+d1+ca0) = c1 and so on.
There are n equations and 2n-1 unknowns, so as previously stated there
is no unique solution. However, you can solve the system of equations
to get a vector solution, and depending on which bits of c are set
you can pick and choose the coefficients of the vectors to come up with
all the possible solutions.
> Ok, I have not solved the problem but I think there is value to this
> approach? I'd be interested in knowing the answer once you have
> it figured out.
Gave me a good idea :-)
Patience, persistence, truth,
Dr. mike
------------------------------
Subject: Re: Arithmetic Coding
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 08 Jun 2000 10:36:28 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>[EMAIL PROTECTED] (steffen markert) wrote in
><8hnjhv$oq6$[EMAIL PROTECTED]>:
>
>>Does anybody know about an implementation in C
>>or a book or a paper with informations about adaptiv
>>arithmetic coding?
>>
>>Thanx
>>
>>[EMAIL PROTECTED]
>>
>>
>>
>
> This isn't the best group for info on adaptive compression
>but my site has some of the best adaptive compression routines
>with the C source code. Mine are tuned for use with enryption
>since they don't add information to the compressed product that
>allows ones encrypted messages to be weakened. There is a
pointer
>to matt's site that has the best info on useful with source code
>adaptive unadulterated arithmetic coding. But it is in C++
To the best of my knowledge no arithmetic coder adds anything
that doesn't need to be there. So your logic is flawed my
friend. Programs like PKZIP may add headers to the overall file,
but that's to identify the file from random crap, not the
contents.
Adaptive arithmetic coding just processes input symbols and
outputs a fraction that represents the message, no hidden booby-
traps there. And if you count message CRC's as hidden booby-
traps then you are sadly in a world of your own.
In other words stop trying to fling mud and sell your self when
you don't know what you are talking about.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Random IV Generation
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 08 Jun 2000 10:39:26 -0700
The message IV need not be truly random, just unique for each
message. You could very well just use a 64-bit time_of_day
counter, i.e the time since 1970 in seconds or something... As
long as you don't send more then one message per second this
should work fine.
Even still you could just use a prng with a long enough period
and it will be ok.
The IV's are known anyways, so don't worry to much about them
being truly random.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: testing non linearity of arithmetic-logic combinations
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 08 Jun 2000 10:42:01 -0700
That's not true, bent functions are functions that are maximally
non linear (I don't have the specific def on me, but I will post
it when I get home)
Anyways, a balanced sbox can be bent, take matsuis sboxes for
example. Similarly CAST sboxes are bent.
Anyways,
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Some dumb questions
Date: Thu, 08 Jun 2000 17:38:44 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Thank you for the valuable informations. This confirms the
> appropriateness of the restriction in my assumptions (see follow-ups
> later than the first post in the thread) that n-gram frequency
> distributions are not exploitable by the opponent (to be rendered
> flat through appropriate measures).
MK, if you are attempting to reuse a pad to save on key-transmission
costs, would your purposes be better served by using 64 bits of what
would be your 'pad' as input to a BlumBlumShub generator to be iterated
a few times and the result[s] to be used as a key for an AES candidate,
or des-ede, or something similar? After each message, you could slide to
using a different set of bits from the 'pad' to generate a new key.
Wouldn't this solve the trouble of reusing pads, while doling out the
available entropy a bit better? [pun not intended, but I like it enough
I am leaving it in. :]
By the use of the BBS, I *think* this will stir things around s.t. reuse
of entropy bits will not cause a problem. If it will, then you could
simply use a different 64 bits from the 'pad' as your future keys..
<shrug>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: 3DES performance
Date: 8 Jun 2000 17:55:26 GMT
In article <8ho5tc$puh$[EMAIL PROTECTED]>,
=?ISO-8859-1?Q?H=E4m=E4l=E4inen?= Panu <[EMAIL PROTECTED]> wrote:
>: Some old numbers I have for software, all for Triple DES
>: in CBC mode. What is interesting is the difference between
>: the two MIPS CPUs at the same clock speed.
>: (k/sec == 1000s of bytes per second)
>
>: 1990k/sec Alpha EV5.6 (21164A) 400mhz (Jun-1997) (C code)
>: 161k/sec 486 66mhz (Jul-1996) (C code)
>: 741k/sec Pentium 100 (Sep-1997) (ASM code)
>: 1570k/sec Pentium Pro 200 (May-1997) (ASM code)
>: 1340k/sec MIPS R10000 195mhz (Dec-1996) (C code)
>: 657k/sec MIPS R4400 200mhz (Dec-1996) (C code)
>
>: 2890k/sec Pentium II 350mhz (Jun-2000) (ASM code)
>: 710k/sec StrongARM 275mhz (Jun-2000) (C code)
>
>Thanks. You wouldn't happen to have any reference on these,
>i.e. where the results are from, would you?
Presumably they're from Eric's library as tested by various people
on different machines. If you have OpenSSL, you can say
"openssl speed des-ede3" and it will measure the speed of EDE 3DES
in CBC mode on a bunch of different block sizes.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: DES question
Date: Thu, 08 Jun 2000 12:44:29 -0500
Paul Pires wrote:
>
> Has any work been done on a DES variation with a 64 bit key? It seems like
> you could change the key shifts per round and have them effect all 64 bits
> vrs the 56 presently treated and leave the compression permutation alone and
> everything else for that matter. All 64 key bits would still get used over
> the 16 rounds.
>
> It seems that the advantage would be the disadvantage. It would still be
> DES-ish. Would it be essentially DES with a key better than 56 bits?
>
> Am I missing something obvious?
>
> Anyone hear of work done on this?
Yes, I have several papers for a 64 bit key variation. I even
implemented
it about 12 to 14 years ago. If you can remind me via e-mail, I'll go
see
if I can find the references at home. The machines that code ran on are
dead
and gone now (I think, I might still have a version on the Atari....)
Anyway, if your interested, send mail to [EMAIL PROTECTED] and I'll
dig
around my stacks of paper.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: Enigma Variations
Date: Thu, 08 Jun 2000 17:06:22 GMT
Reply-To: Jim
On Thu, 08 Jun 2000 04:23:38 GMT, [EMAIL PROTECTED] (John
Savard) wrote:
>On Wed, 07 Jun 2000 17:12:19 GMT, [EMAIL PROTECTED]
>(Jim) wrote, in part:
>
>>The successes against the Japanese machine 'Magic' was an American
>>success, not British. They don't always get the credit for that, at
>>least in this newsgroup.
>
>I'm surprised to hear that.
(For 'Magic' read 'Purple').
Whilst we hear a lot about Bletchley Park and Enigma, it seems
to me we don't often hear much about 'Purple' and American
cryptanalysis in the Pacific after Pearl Harbour.
>The American success against PURPLE, because of the Pearl Harbor
>controversy, became known shortly after the War, and I would have
>thought everyone with an interest in the subject knew that.
>
>But the British may also have done some work on the Japanese stepping
>switch machines: something in the papers on Frode's site looked like a
>mention of PURPLE under another name.
--
amadeus at netcomuk.co.uk
nordland at lineone.net
g4rga at thersgb.net
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: Enigma Variations
Date: Thu, 08 Jun 2000 17:06:22 GMT
Reply-To: Jim
On Thu, 08 Jun 2000 05:30:37 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Jim wrote:
>> The successes against the Japanese machine 'Magic' ...
>
>"MAGIC" was a codeword used to limit distribution of the decrypts,
>not the name anyone used for the machines themselves. Our internal
>names for the machines were colors: ORANGE, RED, PURPLE, etc.
Quite so. That should have read 'Purple'.
--
amadeus at netcomuk.co.uk
nordland at lineone.net
g4rga at thersgb.net
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Extending the size of polyalphabetic substitution tables
Date: Thu, 08 Jun 2000 20:27:06 +0200
A classical polyalphabetical substitution table is a square
matrix with size equal to the cadinality n of the alphabet,
because an element of the key can be any of the characters
in the alphabet. It can obviously be advantageous (and easily
realizable nowadays with computers) to have larger tables,
i.e. with more columns than hithertofore, so that longer
key sequences (e.g. those generated somehow from shorter
keys input by the user) can be employed without much frequent
repeated use of the same columns of the substitution tables.
I can see three different ways of employing such larger
substitution tables.
1. Let the key sequence be divided into groups of k characters
and there be m substitution tables. The first group uses
the first table, the second group the second, etc. till one
wraps round to the first table.
2. Use some of the last bits of the previous plaintext character
to determine the substitution table to be used.
3. Number the ensemble of columns with numbers 0 to g. Use,
instead of key sequences in the traditional sense (whose
elements are characters of the alphabet), pseudo-random
numbers in the range [0, g] as the key sequences.
I should appreciate knowing other and possibly superior ways
of employing larger substitution tables.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DES question
Date: Thu, 08 Jun 2000 20:41:35 +0200
Mike Rosing wrote:
> Yes, I have several papers for a 64 bit key variation. I even
> implemented
> it about 12 to 14 years ago. If you can remind me via e-mail, I'll go
> see
> if I can find the references at home. The machines that code ran on are
> dead
> and gone now (I think, I might still have a version on the Atari....)
Could you post a sketch (the essence) of your modifications? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Digital Certificates
Date: 8 Jun 2000 18:31:08 GMT
In article <[EMAIL PROTECTED]>, IanM <[EMAIL PROTECTED]> wrote:
>This may be a stupid question but how does a pc set up with 512 bit RSA use
>a certificate with a 1024 bit public key?
The server generates temporary 512 bit RSA keys that are used for just
a few sessions. See RFC 2246 appendix D section 1.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.security.misc
Subject: Re: PK analogue for passwords
Date: Thu, 08 Jun 2000 18:54:16 GMT
In article <[EMAIL PROTECTED]>,
=?iso-8859-1?Q?Tom=E1s?= Perlines Hormann <[EMAIL PROTECTED]>
wrote:
> Hi folks!
>
> A year ago or so, somebody published here an approach for users
> of many passwords (>2) which made use of a public part which was
> supposed to contain lots of difficult letters and several private
> parts which were supposed to be easy to remember.
>
> Does anybody remember this article and can it re-post here? I
> remember to find it really attractive and now I want to study
> it a bit deeper as most passwords are being written down somewhere
> and this approach may ensure a better handling of password,
> especially when having to use lots of them for different purposes.
I have used a program `twonz' that I found on freshmeat.net for this
purpose -- the user has a 'pad' they keep secret, and another item that
is very public -- eg, if one is using twonz to keep their
financialinstitution.com password secret, they would enter their pad in
one text field, and financialinstition.com in the second text field, and
the program would run the inputs through a hash function (probably md5
since it is widely available on free unices) and then base64 encode the
result, so one could type the whole thing without too much effort. :)
HTH
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Dennis Paul Himes <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Date: Thu, 08 Jun 2000 14:54:32 -0400
Greg <[EMAIL PROTECTED]> wrote:
>
> ... the law states that you cannot force a person to present
> identificaiton at the booth-
Where is this? Your posts seem to indicate that you live in the USA,
but the above is not true in all states. You can't vote in Connecticut
without first proving you are who you say you are.
============================================================================
Dennis Paul Himes <> [EMAIL PROTECTED]
http://www.connix.com/~dennis/dennis.htm
Disclaimer: "True, I talk of dreams; which are the children of an idle
brain, begot of nothing but vain fantasy; which is as thin of substance as
the air." - Romeo & Juliet, Act I Scene iv Verse 96-99
------------------------------
** 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
******************************
