Cryptography-Digest Digest #629, Volume #13 Sun, 4 Feb 01 19:13:01 EST
Contents:
Re: New Block Cipher ("David Finch")
Re: On combining permutations and substitutions in encryption (Mok-Kong Shen)
Re: New checksum algorithm (Mok-Kong Shen)
Re: Fake "Igor Chudov" = The "Real" Igor Chudov (HORRIFICALLY HIDEOUS HOSEHEAD
HENRIK HANSEN HIDES HIS HAIRY-PALMED HANDS)
Re: Fake SSRIHATER (HORRIFICALLY HIDEOUS HOSEHEAD HENRIK HANSEN HIDES HIS
HAIRY-PALMED HANDS)
Re: Fake "Igor Chudov" (HORRIFICALLY HIDEOUS HOSEHEAD HENRIK HANSEN HIDES HIS
HAIRY-PALMED HANDS)
Re: Tree algorithm (Mok-Kong Shen)
Re: I need some crypting components for Delphi! ("morello")
Re: New Block Cipher (David Wagner)
Re: Fake "Igor Chudov" = The "Real" Igor Chudov ("High's")
Re: A story of distrust .... my ex-mother, Eeva Nuora, Varkaus, Finland tried to
make me lose all ... and so on ... collaborated with the embassy of Finland (wtshaw)
Re: Most secure code for US Citizen. (Michael Robbins)
Re: A story of distrust .... my ex-mother, Eeva Nuora, Varkaus, Finland tried to
make me lose all ... and so on ... collaborated with the embassy of Finland (Eric Lee
Green)
RE: Base64 mapping ("Manuel Pancorbo")
----------------------------------------------------------------------------
From: "David Finch" <[EMAIL PROTECTED]>
Subject: Re: New Block Cipher
Date: Sun, 04 Feb 2001 21:23:13 GMT
> From: [EMAIL PROTECTED] (David Wagner)
> Subject: Re: New Block Cipher
> Date: 4 Feb 2001 07:08:14 GMT
> Reply-To: [EMAIL PROTECTED] (David Wagner)
>
> The cipher you proposed isn't secure.
> Differential cryptanalysis breaks it easily.
> If you want to continue designing block ciphers,
> you consider studying up on diff. cryptanalysis first.
>
> Here's the cipher:
> repeat once for each round (for a total of four rounds):
> apply 8 parallel bijective 8-bit S-boxes
> permute: move bit x of byte y to bit y of byte x
>
> 4 rounds is not enough. Consider: if you flip a single bit in
> the input to a round, with probability 8/256 only a single bit
> will be flipped in the output from that round. Iterate this
> differential characteristic over 3 rounds, and you get the following:
>
> Property. With prob. 1/2^15, flipping a single bit in the
> plaintext causes only about 4 bits to be flipped after 4 rounds.
>
> The above property can be used to distinguish your cipher from
> an ideal cipher with only about 2^15 plaintext pairs. If DAFI
> is used, you expect to see one low-weight ciphertext pair in the
> pool of 2^15 pairs, whereas for an ideal cipher the chances of
> seeing such a ciphertext pair is tiny (about 1/2^44 per text-pair).
>
> I'm pretty sure you can also build key-recovery attacks using
> more advanced concepts from differential cryptanalysis.
That's good to know.
So with enough of those they may be able to guess all 65536 bits
of the sboxes. They could quite possibly break it faster than brute force.
Would a plaintext dependant rotation before each round thrawt this attack?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On combining permutations and substitutions in encryption
Date: Sun, 04 Feb 2001 23:08:05 +0100
Terry Ritter wrote:
>
> (SCOTT19U.ZIP_GUY) wrote:
>
> >[EMAIL PROTECTED] (Terry Ritter) wrote:
> >>Known-plaintext is one of the most damaging information conditions,
> >>specifically because it can immediately expose a complete ciphering
> >>transformation.
> >>
> >>For the emulated huge simple substitutions we call conventional block
> >>ciphers, known-plaintext generally does expose one element from the
> >>emulated table.
> >>
> >>For classic simple XOR stream ciphers, known-plaintext immediately
> >>exposes the confusion or keying sequence, which then allows that
> >>sequence to be attacked.
> >>
> >>But for Dynamic Transposition, known-plaintext does *not* immediately
> >>expose any particular permutation, because many different permutations
> >>can produce that same transformation. This is an advantage. How big
> >>that advantage is, obviously depends.
> >>
> >>However, I would say that Dynamic Transposition is not "complex," but
> >>is instead far clearer in concept than any Feistel cipher.
> >>
> >
> > Terry "wrapped PCBC" also is designed to "not immediately expose"
> >any particular permutation. But it also allows data to mix through
> >the whole file not just in the forward direction.
>
> Actually, it does.
>
> We need to compare ciphers of similar type for the description to have
> a similar meaning. I see SCOTT-type ciphers as "Variable-Size Block
> Ciphers (VSBC's)," the operative words being: "Block Cipher."
>
> We assume that the known-plaintext attack provides the plaintext file
> and the ciphertext file. That defines one transformation in the
> emulated huge Simple Substitution which is the block cipher, even for
> SCOTT-type ciphers. I don't know that the information is particularly
> helpful, but the transformation *is* exposed.
It is interesting that you view whole file processing as
variable-size block ciphers (in view of the fact that
you have some patents on variable-size block ciphers,
if I remember what you wrote previously correctly).
> The issue becomes more interesting when we have a "small" block
> cipher, but not because we hope to accumulate enough transformations
> to decipher anything we see. Instead, if we have even a small number
> of such transformations, very few keys could produce that set, which
> minimizes or removes key uncertainty -- if only we could solve the
> cipher transformations. Presumably, this is the unicity distance,
> which, in "small" (which is to say, conventional) block ciphers,
> should be fairly short.
>
> The issue is just different with respect to Dynamic Transposition
> ciphers. Because many different permutations can produce the exact
> same transformation from plaintext to ciphertext, there is no one
> permutation result which might lead back to a particular sequence by
> which one could attack the RNG. And since Dynamic Transposition
> creates a new permutation for each block, known-plaintext never
> provides information to distinguish which particular permutation was
> actually used for any block. This is different from completely
> revealing a particular transformation, even if that which is revealed
> is only one from among a multitude.
>
> Now, it can reasonably be argued that knowing the different subsets of
> permutations -- as revealed by known-plaintext -- do in fact deliver
> some information about the RNG state. I argue that this is different
> in practice from a block cipher, in which the fundamental concept of
> enciphering -- an emulated huge simple substitution -- is directly
> addressed by unicity distance. In practice, since we cannot search
> the keyspace, we have to instead find some logical relationship from
> key to result. In a normal block cipher, that is the ciphering
> rounds, which are directly connected to the key. No additional levels
> of protection are involved. In a Dynamic Transposition block cipher,
> the relation is from the linear RNG, through sequence nonlinearity,
> through shuffling itself (which discards information) and the
> double-shuffle (which hides the RNG sequence), and only then to the
> ultimate permutation which affects the data. That is the sense in
> which I meant that the attack computation should be more complex with
> Dynamic Transposition, even though I see the ciphering process itself
> as being much clearer.
As far as I have seen, nobody has argued against any claim
of the sort 'attacking DT is very complex'. So the many
disputes about DT in a number of threads hitherto had
constituted 'much ado for nothing' or have there been some
real causes that render disputes unavoidable?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: New checksum algorithm
Date: Sun, 04 Feb 2001 23:07:57 +0100
Benjamin Goldberg wrote:
>
> Mok-Kong Shen wrote:
> >
> > Benjamin Goldberg wrote:
> > >
> > > Mok-Kong Shen wrote:
> > > >
> > > > Benjamin Goldberg wrote:
> > > > >
> > > > > Mok-Kong Shen wrote:
> > > > > >
> > > > > > Benjamin Goldberg wrote:
> > > > > > >
> > > > > > > Terry Ritter wrote:
> > > > > > > >
> > > > > > > > Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
> > > > > > > >
> > > > > > > > > I like to take this opportunity to ask a question of
> > > > > > > > > ignorance:
> > > > > > > > > Why does e.g. CRC-16 use a polynomial of degree 16? (I
> > > > > > > > > had expected one of degree 15, since that can be
> > > > > > > > > represented with 16 bits, while one of degree 16 can't.)
> > > > > > > > > Thanks in advance.
> > > > > > > >
> > > > > > > > The remainder from a degree 16 poly is a degree 15 poly,
> > > > > > > > and a mod 2 deg 15 poly has 16 bits: 15, 14, ... 1, 0.
> > > > > > >
> > > > > > > Plus, since the x^16 coefficient is always 1, it never needs
> > > > > > > to be stored in the variable holding the taps.
> > > > > >
> > > > > > However, CRC-16 is geared to 16 bit word size, I suppose.
> > > > > > So it is clumsy to operate with a 16 degree polynomial,
> > > > > > isn't it? (How do you do subtraction without considering
> > > > > > the one bit that you do not have in storage representation
> > > > > > of the polynomial?)
> > > > >
> > > > > Think about how CRC works:
> > > > > crcvalue = ((crcvalue<<1)+newbit) % polynomial;
> > > > > Since the max crcvalue is just less than the polynomial, % is
> > > > > never more than a single subtraction -- and since we are working
> > > > > with polynomials, not integers, we only subtract when the top
> > > > > bit of crcvalue was 1. This means, we can change it to the
> > > > > following:
> > > > >
> > > > > crcvalue = ((crcvalue<<1) & 0x10000) ?
> > > > > ((crcvalue<<1)+newbit-polynomial) :
> > > > > ((crcvalue<<1)+newbit);
> > > > >
> > > > > Or, better yet,
> > > > > crcvalue = (crcvalue & 0x8000) ?
> > > > > ((crcvalue<<1)+newbit-polynomial) :
> > > > > ((crcvalue<<1)+newbit);
> > > > >
> > > > > Or better yet still:
> > > > > crcvalue = ((crcvalue<<1)+newbit) -
> > > > > ((crcvalue&0x8000) ? polynomial : 0);
> > > > >
> > > > > I think you can see that on any occasion where we shift a 1 bit
> > > > > out of crcvalue, we are subtracting polynomial from crcvalue --
> > > > > and the x^16 coefficient of the poly is 1, too -- thus these
> > > > > cancel out, and no data is lost.
> > > >
> > > > I was not saying that one can't manage to calculate correctly
> > > > but that it may be easier with a degree 15 polynomial. For
> > > > one could then work wordwise (16 bits) instead of taking in
> > > > each new bit at a time, I guess.
> > >
> > > Even if we changed to a degree 15 polynomial, we could not work more
> > > than one bit at a time. We can precompute tables, true, and work a
> > > byte at a time, but this is doable regardless of the size of the
> > > poly.
> >
> > Maybe I misunderstood. If we work with words and the 'full'
> > polynomial can be represented in a word, we could compare
> > a word with polynomial and subtract if it is not less isn't
> > it? (If not less, we shouldn't subtract. Compare also below.)
> >
> > > > BTW, in your first version 0x10000 doesn't work with hardware
> > > > with word size of 16 bits, I suppose.
> > >
> > > True. It was done to demonstrate, theoretically, what happens when
> > > a crc is calculated.
> >
> > > > In the second version, what happens when (crcvalue<<1)+newbit with
> > > > the 17th bit (the one omitted) added in is less 'polynomial' with
> > > > the 17th bit added in?
> > >
> > > Let's pretend that we are working with 17 bit words.
> > > I only subtract 'polynomial' when the 17th bit is set, not
> > > otherwise. Since the 17th bit of the poly is also set, this means
> > > that no matter what, the 17th bit of crcvalue after the update is 0.
> > > Do you see why?
> >
> > Let's imagine the 17th bit were there (both in the polynomial
> > and in the accumulated bits). You want to subtract only when
> > the accumulated bits gives a value that is not less than
> > polynomial. That means that in this situation, when we omit
> > the 17th bit in both cases, we have to check that for the
> > remaining 16 bits, the accumulated value is no less
> > than the 'polynomial' (without the 17th bit) before a
> > subtraction is performed. I repeat: with the 17th bits
> > the first value may happen to be smaller than the second.
> > Subtraction would result in an inappropriate negative value.
>
> When we "subtract" the polynomial, we are actually doing an XOR, not an
> integer subtraction. Thus, there is no negative value.
>
> > Chopping the 17th bits, which are on in both cases, the
> > situation remains the same. You code doesn't do that check
> > which I suppose is not o.k. Am I right?
>
> My code doesn't do a check for "greater than" or "less than," on the
> values, only on the orders of the polynomials (ie, is the order of
> (crcvalue<<1|newbit) less than or equal to 16). However, since
> subtraction is XOR, this is perfectly o.k., so you are wrong.
You are right, I am mistaken.
> > > > (I understand here 'polynomial' is without the highest 17th bit.
> > >
> > > If we are working with 16 bit words, the poly is without the 17th
> > > If we are working with words >16 bits, the 17th bit is set.
> > >
> > > > I mean one should only subtract when the
> > > > former quantity is not less than the latter.)
> > >
> > > All versions are equivilant.
> > >
> > > > Sorry, I can't understand your third version at all. For it says
> > > > that crcvalue is either 'polynomial' or 0, if I don't err.
> > >
> > > No, it says that you either subtract polynomial or 0. Here's the
> > > original 3rd version:
> > >
> > > > > crcvalue = ((crcvalue<<1)+newbit) -
> > > > > ((crcvalue&0x8000) ? polynomial : 0);
> >
> > Evidently you had printing errors. This was what I found
> > in your (original) post of 3rd Feb:
> >
> > Or better yet still:
> > crcvalue = ((crcvalue<<1)+newbit) - (crcvalue&0x8000) ?
> > polynomial : 0;
> >
> > (I made a guess that requires supplying the least number
> > of missing parentheses, in accordance with common practice
> > of automatic syntax error correction.)
>
> I confess, I did change it when I quoted it, to add the parens. Does it
> matter? If we use the order of operations precedence of C and C++, the
> two things should be equivilant, right? I mean, isn't (a-b?c:d) the
> same as (a-(b?c:d))?
This time you are wrong. The operator '-' has higher precedence
than '?' and ':'. Therefore a-b?c:d is interpreted as (a-b)?c:d.
M. K. Shen
------------------------------
From: HORRIFICALLY HIDEOUS HOSEHEAD HENRIK HANSEN HIDES HIS HAIRY-PALMED HANDS
<[EMAIL PROTECTED]>
Crossposted-To:
alt.support.depression.medication,soc.culture.russian,soc.org.kkk,dk.snak.mudderkastning,soc.culture.ukrainian
Subject: Re: Fake "Igor Chudov" = The "Real" Igor Chudov
Date: 4 Feb 2001 16:11:08 -0600
SOVOK DORK Igor wrote:
> I have been informed that there is a fake "Igor Chudov" "posting"
> to alt.support.depression.medication, with the address ending in
> @sovok-dork.org or some such.
>
> That fake "Igor Chudov" is not me.
Liar.
> If you have doubts about authenticity of my usenet posts, email me
> to my real address.
I received your reply from [EMAIL PROTECTED], sovok d0rk!
------------------------------
From: HORRIFICALLY HIDEOUS HOSEHEAD HENRIK HANSEN HIDES HIS HAIRY-PALMED HANDS
<[EMAIL PROTECTED]>
Crossposted-To:
alt.support.depression.medication,soc.culture.russian,soc.org.kkk,dk.snak.mudderkastning,soc.culture.ukrainian
Subject: Re: Fake SSRIHATER
Date: 4 Feb 2001 16:16:36 -0600
SSRI Hater wrote:
> I have seen many posts posted under the name SSRIHATER, not penned by me, but
> seemingly some irrational delusional crazed nut desirous of being anyone but
> himself.
My guess is the sovok dork Igor Chudov is to blame.
------------------------------
From: HORRIFICALLY HIDEOUS HOSEHEAD HENRIK HANSEN HIDES HIS HAIRY-PALMED HANDS
<[EMAIL PROTECTED]>
Crossposted-To:
alt.support.depression.medication,soc.culture.russian,soc.org.kkk,dk.snak.mudderkastning,soc.culture.ukrainian
Subject: Re: Fake "Igor Chudov"
Date: 4 Feb 2001 16:18:02 -0600
Pablo wrote:
> Igor wrote in message ...
> >I have been informed that there is a fake "Igor Chudov" "posting"
> >to alt.support.depression.medication, with the address ending in
> >@sovok-dork.org or some such.
> >
> >That fake "Igor Chudov" is not me.
>
> The person who has been impersonating you is Andrew Chmilewsky.
>
> >If you have doubts about authenticity of my usenet posts, email me
> >to my real address.
>
> Thank you for the clarification.
You would hve to be on drugs to believe that twaddle.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Tree algorithm
Date: Sun, 04 Feb 2001 23:29:35 +0100
Paul Crowley wrote:
>
> If you're interested in cryptographic algorithms based on trees, look
> at the stream cipher LEVIATHAN.
>
> http://www.cluefactory.org.uk/paul/crypto/leviathan.html
I got Error 400 when accessing the above URL.
M. K. Shen
------------------------------
From: "morello" <[EMAIL PROTECTED]>
Subject: Re: I need some crypting components for Delphi!
Date: Sun, 4 Feb 2001 22:26:16 -0000
I've picked up this thread a bit late. StrongBox is a COM component (rather
than VCL) but it is certainly compatible with Delphi, and includes a sample
Delphi program. See our website.
--
===========================================================
Morello Publishing Ltd
http://www.morello.co.uk
Manage your passwords with Morello KeyRing
Daniel <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Delphi crypto components
>
> You can try these :
>
> www.crypto-central.com (both commercial as freeware)
> www.scramdisk.clara.net/d_crypto.html (freeware by Dave Barton)
>
> best regards,
>
> Daniel
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: New Block Cipher
Date: 4 Feb 2001 22:47:40 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
David Finch wrote:
>Would a plaintext dependant rotation before each round thwart this attack?
No.
------------------------------
From: "High's" <[EMAIL PROTECTED]>
Crossposted-To:
alt.support.depression.medication,soc.culture.russian,soc.org.kkk,soc.culture.ukrainian
Subject: Re: Fake "Igor Chudov" = The "Real" Igor Chudov
Date: Sun, 04 Feb 2001 23:05:37 GMT
would an idiot spammer be using Linux? I don't think so.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.2600,alt.security,comp.security
Subject: Re: A story of distrust .... my ex-mother, Eeva Nuora, Varkaus, Finland tried
to make me lose all ... and so on ... collaborated with the embassy of Finland
Date: Sun, 04 Feb 2001 17:06:43 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> "Markku J. Saarelainen" wrote:
> >
> > Basically, this the story of distrust.
> >
> <snip>
>
>
> This is relavent to any of the groups you posted this too??
>
> Fascinating story, should I care?
>
> StanMann
Perhaps this is a sufficient example of text that anyone could write and
hash to a key; just pontificate on a theme to your heart's content.
--
Sugar coated arsenic is bad for your health.
------------------------------
From: Michael Robbins <[EMAIL PROTECTED]>
Subject: Re: Most secure code for US Citizen.
Date: Sun, 04 Feb 2001 23:34:00 GMT
I purchased two of the three books recommended in this thread. I'm sure
I'll never be an expert on crypt but I always found it interesting.
More to the point, I now carry my source on a CD, which removes the
possibility of theft while I'm away from my workstation. I guess
someone could tap into my CD while I'm there.
I see several threats and counters. Please comment.
I should encrypt my CD so it will be less useful if lost. Can I use
some program for that so I can use it as a regular CD at my workstation
but it will be encrypted if lost? I read something about scramdisk.
How can I prevent someone surfing my workstation and tapping into my CD
while I'm using it?
I use win-NT. What vulnerabilities exist? If I delete a file and
remove it from the Recycle Bin, is it still easily recovered. Must I
fill the drive with data to clean it?
What else have I missed? What first-pass measures can I institute to
protect my source code while I come up to speed?
--
Michael Robbins, CFA
Director, Debt Capital Markets
Canadian Imperial Bank of Commerce, World Markets
New York
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Crossposted-To: alt.2600,alt.security,comp.security
Subject: Re: A story of distrust .... my ex-mother, Eeva Nuora, Varkaus, Finland tried
to make me lose all ... and so on ... collaborated with the embassy of Finland
Reply-To: [EMAIL PROTECTED]
Date: 4 Feb 2001 15:41:49 -0600
On Sun, 04 Feb 2001 17:06:43 -0600, wtshaw <[EMAIL PROTECTED]> wrote:
>Perhaps this is a sufficient example of text that anyone could write and
>hash to a key; just pontificate on a theme to your heart's content.
No no, it's steganography. There's actually a secret message hidden in there
to the aliens who control his brain. (grin).
--
Eric Lee Green Linux Subversives
[EMAIL PROTECTED] http://www.badtux.org
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: "Manuel Pancorbo" <[EMAIL PROTECTED]>
Subject: RE: Base64 mapping
Date: Mon, 5 Feb 2001 00:27:29 +0100
"Manuel Pancorbo"
> Where can I find this information?
>
Well, now it's ok. Thanks to the contributors.
One more thing. Is this alfabet the one used in random password generator?
--
____________________________________________________________________
Manuel Pancorbo
[EMAIL PROTECTED] (Apply ROT13)
____________________________________________________________________
------------------------------
** 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
******************************
