Cryptography-Digest Digest #320, Volume #14 Wed, 9 May 01 06:13:01 EDT
Contents:
Re: Secure Digital Music Initiative cracked? (Taneli Huuskonen)
Re: Steganographic idea. (Xcott Craver)
Re: OAP-L3: "The absurd weakness." (Xcott Craver)
Re: Steganographic idea. (Xcott Craver)
Re: enumerating permutations ("Tom St Denis")
Re: keen bitsliced idea cipher ("Tom St Denis")
Re: Random and not random (Mok-Kong Shen)
Re: Best encrypting algoritme (Mok-Kong Shen)
Re: free en/decryption library (yomgui)
Re: free en/decryption library (yomgui)
Re: A Question Regarding Backdoors (Mok-Kong Shen)
Re: Random and not random (Bryan Olson)
Re: Random and not random (Mok-Kong Shen)
Re: free en/decryption library ("Tom St Denis")
Re: Random and not random (Bryan Olson)
Re: Weird Rijndael test vectors wanted (Simon Josefsson)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Taneli Huuskonen)
Crossposted-To: talk.politics.crypto
Subject: Re: Secure Digital Music Initiative cracked?
Date: 9 May 2001 09:16:00 +0300
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
In <[EMAIL PROTECTED]> David Hopwood
<[EMAIL PROTECTED]> writes:
[about an article describing weaknesses in several digital watermarking
schemes]
>Of course. It's now mirrored here:
> http://www.users.zetnet.co.uk/hopwood/crypto/sdmi/sdmi-attack.zip
Also here:
http://www.helsinki.fi/~huuskone/sdmi-attack.zip
>The RIAA and SDMI consortium don't seem to have learnt anything from
>the failure to suppress DeCSS. You'd think they were trying to set
>themselves up as the bad guys.
"We have this great protection scheme, designed by our best crypto
expert, who almost passed an introductory course to cryptology. What?
You saying it's not good? Worse still, you're telling what's wrong with
it!? Shut the #$%@ up or we'll sue your pants off!!"
That's what I call stupidity.
Taneli Huuskonen
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBOvjfHV+t0CYLfLaVEQJnMACg3yYtJNclf13I2d5DR3AwasvYcdsAoINL
NIRroDnSpQB6o5UVjsHivf1p
=YfZO
=====END PGP SIGNATURE=====
--
I don't | All messages will be PGP signed, | Fight for your right to
speak for | encrypted mail preferred. Keys: | use sealed envelopes.
the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
------------------------------
Subject: Re: Steganographic idea.
From: [EMAIL PROTECTED] (Xcott Craver)
Date: Wed, 09 May 2001 06:27:35 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>
>for each pixel in the inputted grayscale image:
> threshhold := CSPRNG.nextbyte();
> if( pixel < threshhold || pixel = 0 ) output( whitepixel )
> if( pixel > threshhold || pixel = 255 ) output( blackpixel )
> if( pixel = threshhold && pixel != 0 && pixel != 255 )
> if( datatohide.nextbit() = 0 )
> output( whitepixel )
> else
> output( blackpixel )
So, a grayscale image is converted to a black&white image,
with a varying threshold. How would you compare this to
the approach of, say, replacing the last 2 LSBs of each
pixel with two bits of the data to be hidden? The result
is still grayscale, and doesn't require an original.
A similar approach to yours is adding data to each pixel,
but not quantizing. For each pixel, pixel += (nextbit()*2*k-1),
where k is a small constant. This can also be used as an
image watermarking method, because you can test if a known
plaintext is in the message without the original: compute
the mean of all pixels corresponding to 1s, minus the mean
of all pixels corresponding to 0s. For an unmarked image
the expected value should be 0, but for a marked one, 2*k.
-S
------------------------------
Crossposted-To: alt.hacker,talk.politics.crypto
Subject: Re: OAP-L3: "The absurd weakness."
From: [EMAIL PROTECTED] (Xcott Craver)
Date: Wed, 09 May 2001 06:38:51 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
>I think the place to start in answering this question is to read the
>Help Files: Theory, Processes, Operation, etc. and the recommended
>use.
You might be under the false impression that people respond
to your posts out of interest in your cipher, when in fact
they only do so to inform 3rd parties, who may have recently
taken a peek into sci.crypt, that you are one of the regular
crackpots.
>Good luck. You'll need it if you think you have a prayer in
>breaking the OTP files.
I'd love to, but oooh, I just got an email, and in order
to display it on the screen my software requires me to
shuffle a deck of cards 10 times and do some long division
on the back of an envelope.
-S
------------------------------
Subject: Re: Steganographic idea.
From: [EMAIL PROTECTED] (Xcott Craver)
Date: Wed, 09 May 2001 06:40:46 GMT
Xcott Craver <[EMAIL PROTECTED]> wrote:
>
> A similar approach to yours is adding data to each pixel,
> but not quantizing. For each pixel, pixel += (nextbit()*2*k-1),
Sorry, I meant 2*k-k, or k*(2*nextbit()-1).
> -S
-S
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: enumerating permutations
Date: Wed, 09 May 2001 06:53:59 GMT
"wtshaw" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <Jb_J6.47269$[EMAIL PROTECTED]>, "Tom St
> Denis" <[EMAIL PROTECTED]> wrote:
>
> > "Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
> > news:9d9qj2$nnd$[EMAIL PROTECTED]...
> > > You just reinvented one of the elements of the SteakCipher key
schedule.
> > Cf
> > > http://www.stremsec.com/combutil.pas
> > >
> > > I don't know if I was the first to actually use this algorithm in this
> > way.
> > > Probably not. A similar algorithm was described by Knuth.
> >
> > Keen.
> >
> > Tom
>
> While some say that you need to solve to learn some crypto, even be the
> first to crack something, deriving information from lesser scraps is
> promising and probably means that you have a good shot at actually
> producing new and useful ideas. Keep it up in spite of how bad you get or
> deserve to be panned when you make a false start.
My plan wasn't to make a monoalphabetic cipher though...
Thanks for the encouragement :-)
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: keen bitsliced idea cipher
Date: Wed, 09 May 2001 08:18:26 GMT
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:z52K6.49218$[EMAIL PROTECTED]...
> I know I know, I should analyze my own designs but I just want a "feel"
> before I get serious on this design.
I couldn't sleep so I think I might have improved the algorithm (source at
same web address).
Essentially I looked at the xor-pair tables to see the values for single in
single out pairs. They are bounded by 2/16 and none are of the form
delta_in = delta_out.
I changed the linear transform (LT) to spread the bits a bit more evenly
around the block. The cipher still runs at 3.2 million blocks per second
(for the interested that's about 22 cycles per byte in C compiled by GCC).
> The C source for the cipher is at http://tomstdenis.home.dhs.org/tc15.c
> which is very simple to follow.
Tom
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Wed, 09 May 2001 10:16:27 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
> >
> > Bryan Olson wrote:
> [...]
> > > There is no best or worst permutation to choose; only good
> > > and bad methods by which to make the choice. Specifically,
> > > you lose perfect secrecy if the selection of the permutation
> > > is based, in whole or in part, on the content of the
> > > keystream segments that you are permuting. Matthew Skala
> > > stated this more formally as the requirement for
> > > independence. It is the point behind Paul Schlyter's
> > > byte-sorting example. It is what James Felling has been
> > > explaining.
> >
> > I continue to think that the claim 'there is no best
> > or worst permutation to choose' logically implies
> > 'any choice is equivalent to the other'
>
> You continue to be wrong, at best. Using any of the
> permutation with probability 1 is fine. That is one way to
> make the choice independent of the keystream segments.
> Again I recommend you go back and study Skala, Schlyter and
> Felling's posts in this strand. The speed of your posting
> shows you have not yet done so.
>
> > and hence the
> > choice is entirely free, much like e.g. when deciding
> > to buy a certain book in a store I can pick at my will
> > any one copy of the same book on the shelf.
>
> The books have the same content; do you expect your
> keystream segments to have the same content? What is the
> relevant security property you seek for your book? This
> analogy is not analogous.
>
> > (I might
> > habitually try to always pick the 3rd copy, if there
> > are at least three copies, because, for example, the
> > number 3 has something to do with my birthday, but
> > does it really matter?)
>
> Skala and Felling have already explained this. You can
> choose a keystream segment depending on your birthday, your
> shoe size or your favorite kind of ice cream and still have
> perfect secrecy. There is only one thing in the universe
> that you must not allow to influence the choice: the content
> of the keystream segments.
>
> In your three segment example, suppose your method of
> choosing is to use the one permutation of the six that puts
> the three segments in lexicographic order (normal sorted
> order). If any of the three segments has a first bit of 0,
> then the segment that is first in the sorted order must have
> a first bit of zero. Thus after applying the permutation,
> the first bit of the first keystream segment will be zero
> with probability 7/8. To achieve perfect secrecy all keys
> must be equally likely, so perfect secrecy is lost.
Before we argue more in details, let me challenge you to
show any flaws in the following simple purely formal
argument which plays an essential role in my recent
postings. I have modified the same in a post answering
James Felling a bit in order to render the content more
conspicous and in fact entirely trivial to be seen to
be logically universally true:
Denoting by x and y typical elements of a set whose
elements can be compared, we have
There is no max or min x (to choose) in the set <--->
Any x is equivalent to any y <--->
One is entirely free to choose an (arbitrary) x (without
obtaining a higher/lower value)
If you can show any flaws then please kindly do so.
If, on the other hand, you accept the above as true, then
please apply it to your previous claim 'there is no best
or worst permutation to choose' and see what result
you'll get. It's a rather simple task, isn't it?
M. K. Shen
=========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Best encrypting algoritme
Date: Wed, 09 May 2001 10:34:58 +0200
"John A. Malley" wrote:
>
[snip]
> An All-Or-Nothing Transformation acting on the entire message is
> probably an example of a better single algorithm. Otherwise, there's
> good reason to use a block chaining mode with a block cipher.
Given a block cipher (the decision to use such a one is
mostly 'fixed'), I believe that chaining is always a
worthwhile additional operation to be done, because it is
fairly cheap computationally in comparison to its benefit.
However, I personally would prefer non-linear chainings
to the linear ones like CBC.
M. K. Shen
------------------------------
From: yomgui <[EMAIL PROTECTED]>
Subject: Re: free en/decryption library
Date: Wed, 09 May 2001 09:44:50 +0100
Reply-To: [EMAIL PROTECTED]
as long as the last operation is a xor with a pseudo random number I
maintain it's a xor.
whatever I do before the result is at least as secure as the final xor.
I am sure you can understand that.
Tom St Denis wrote:
>
> "yomgui" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > if you can't recognise a xor everything must be homebrew for you anyway
>
> I don't want to start a flame war, but your cipher is a homebrew. Until you
> get more formal and have others analyze it you should consider it very
> unsecure.
>
> Tom
>
> >
> > Tom St Denis wrote:
> > >
> > > "yomgui" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > > free, small, cross platform, safe, simple, fast, open source,
> > > > symmetric stream and file encryption
> > > >
> > > > http://bigfoot.com/~kryptyomic
> > >
> > > Link doesn't work. Aren't you that guy that made a homebrew system
> anyways?
> > >
> > > BAAAAAAD
> > >
> > > Tom
> >
> > --
> > ���g��
> > oim 3d - surface viewer - http://i.am/oim
> > kryptyomic - encryption scheme - http://bigfoot.com/~kryptyomic
--
���g��
oim 3d - surface viewer - http://i.am/oim
kryptyomic - encryption scheme - http://bigfoot.com/~kryptyomic
------------------------------
From: yomgui <[EMAIL PROTECTED]>
Subject: Re: free en/decryption library
Date: Wed, 09 May 2001 10:04:02 +0100
Reply-To: [EMAIL PROTECTED]
Joseph Ashwood wrote:
>
> Definitely homebrew, and definitely not of decent grade. If I read it
> correctly a random change in the key (so lack-lusterly called "password")
> will on average only change bits beginning 32768 bytes in. Additionally the
> claim that the period "exceeds 2^60" is a bit worthless cryptographically,
> it's common to avoid any stream generator that does not have a period
> >>>>>>>>>>>> 2^100, especially since we have generators with period >
> 2^1000.
whatever, woudn't you attack that on the password side ?
> It is also apparent that the cipher is not fully explained on the
> webpage (denoted, again, erroneously as "active principle").
sorry, I tried to be just a bit funny.
as it is open source you can check in the code
the explaination that you think are missing
> The
> misspellings continue throughout,
you will forgive others for not being american, will you?
> along with misuse of what significant
> terminolgy has been used, a nearly complete lack of understanding about
> cryptography is evident.
you mean as the words are not the right ones it can't be the right
thing.
otherwise, feel free to devellop.
> I feel it's safe to recommend against the usage of
> kryptyomic for any purposes, it is not of even of significant use to write a
> paper breaking it, it has no reputation, and the author has no reputation.
you know, my first post where about having advice on my cypher.
and I can't say I received too much from this group.
so I advertised, and critics came. critics, I can use that.
you think the period of my cypher is too small, ok, I will put some BBS
there
it is the only thing I learned from your post am afraid
you tell me it is an homebrew, but the final op�ration is a xor with
a pseudo random number. so wathever I do before to transform A into B,
I finally encrypt B into C with an encryption scheme you won't contest,
a xor. How can you after that " recommend against the usage of " a xor
???
--
���g��
oim 3d - surface viewer - http://i.am/oim
kryptyomic - encryption scheme - http://bigfoot.com/~kryptyomic
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A Question Regarding Backdoors
Date: Wed, 09 May 2001 11:09:08 +0200
wtshaw wrote:
>
[snip]
> It matters not that there might be a weakest link is a well nested
> algorithm because all links need to be solved on their own merits.
In another thread you also said that weaker algorithms
can be compounded to produce new algorithms of any
complexity. I guess that these statements of yours are
true, though my poor knowledge doesn't allow me to
contribute any non-trivial comments. Given the often
seen scenario that even relative minor flaws or omissions
would be quickly exposed, I continue nontheless to wonder
that there have yet been no comments from experts to your
claims which are from nature of general significance
to crypto in view of the extent of their coverage
(or critique 'provoking' to look from the other side)
and hence their truth/false values should be established
through extensive discussions in my humble view. (Or
could I conclude from the silence that everyone in the
group in fact perfectly agrees with what you said?)
M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Wed, 09 May 2001 02:12:26 -0700
Mok-Kong Shen wrote:
> You are not arguing at the level of the above quote of
> mine [...]
Felling's analogy points to the essential understanding you
lack. You seem to want to brush his explanation off because
it doesn't directly answer your questions. That would be a
mistake. Your questions do not have answers of the form you
seem to expect.
> Bryan Olson has in his previous post expressed his
> viewpoint (I assume that you agree with him) that 'there
> is no best or worst permutation to choose' and I have from
> that logically deduced 'any choice is equivalent to the
> other' and from that deduced 'the choice is entirely free'.
My informally stated answer was:
| There is no best or worst permutation to choose; only good
| and bad methods by which to make the choice. Specifically,
| you lose perfect secrecy if the selection of the permutation
| is based, in whole or in part, on the content of the
| keystream segments that you are permuting. Matthew Skala
| stated this more formally as the requirement for
| independence.
[...]
> There is no best or worst x to choose --->
> Any choice x is equivalent to any other choice y --->
> One is entirely free to choose an (arbitrary) x
>
> Could you show the flaw in this chain in the 'formal'
> sense [...]
The above is not formal logic, and even as informal logic it
is much too vague. That said, I suspect the flaw is
assuming that a predicate true of any constant from some set
must also be true of a random variable ranging over the same
set. There is no best or worst permutation to choose, only
good and bad methods by which to make the choice.
--Bryan
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Wed, 09 May 2001 11:21:58 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
>
> > You are not arguing at the level of the above quote of
> > mine [...]
>
> Felling's analogy points to the essential understanding you
> lack. You seem to want to brush his explanation off because
> it doesn't directly answer your questions. That would be a
> mistake. Your questions do not have answers of the form you
> seem to expect.
>
> > Bryan Olson has in his previous post expressed his
> > viewpoint (I assume that you agree with him) that 'there
> > is no best or worst permutation to choose' and I have from
> > that logically deduced 'any choice is equivalent to the
> > other' and from that deduced 'the choice is entirely free'.
>
> My informally stated answer was:
>
> | There is no best or worst permutation to choose; only good
> | and bad methods by which to make the choice. Specifically,
> | you lose perfect secrecy if the selection of the permutation
> | is based, in whole or in part, on the content of the
> | keystream segments that you are permuting. Matthew Skala
> | stated this more formally as the requirement for
> | independence.
>
> [...]
> > There is no best or worst x to choose --->
> > Any choice x is equivalent to any other choice y --->
> > One is entirely free to choose an (arbitrary) x
> >
> > Could you show the flaw in this chain in the 'formal'
> > sense [...]
>
> The above is not formal logic, and even as informal logic it
> is much too vague. That said, I suspect the flaw is
> assuming that a predicate true of any constant from some set
> must also be true of a random variable ranging over the same
> set. There is no best or worst permutation to choose, only
> good and bad methods by which to make the choice.
To suspect is one thing, to demonstrate is another. A
more clear formulation is in my last post.
M. K. Shen
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: free en/decryption library
Date: Wed, 09 May 2001 10:01:57 GMT
"yomgui" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> as long as the last operation is a xor with a pseudo random number I
> maintain it's a xor.
> whatever I do before the result is at least as secure as the final xor.
> I am sure you can understand that.
This obviously is a sign you have no clue whatsoever of what you are doing.
(Hint why is a LFSR insecure when used directly?).
Tom
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Wed, 09 May 2001 03:04:53 -0700
Mok-Kong Shen wrote:
> Before we argue more in details, let me challenge you to
> show any flaws in the following simple purely formal
> argument which plays an essential role in my recent
> postings. I have modified the same in a post answering
> James Felling a bit in order to render the content more
> conspicous and in fact entirely trivial to be seen to
> be logically universally true:
>
> Denoting by x and y typical elements of a set whose
> elements can be compared, we have
>
> There is no max or min x (to choose) in the set <--->
> Any x is equivalent to any y <--->
> One is entirely free to choose an (arbitrary) x (without
> obtaining a higher/lower value)
>
> If you can show any flaws then please kindly do so.
> If, on the other hand, you accept the above as true, then
> please apply it to your previous claim 'there is no best
> or worst permutation to choose'
I did not post anything so misleading. I wrote:
| There is no best or worst permutation to choose; only good
| and bad methods by which to make the choice.
> and see what result
> you'll get. It's a rather simple task, isn't it?
To show the that it's nonsense is a simple task.
There's no defined min and max among distinct permutations.
But the real error is that you are still looking in the
wrong place. It's the method of choosing the permutations
that can destroy perfect secrecy, not any property of
particular permutations. You had to deliberately chop my
sentence in half to lead yourself so astray.
--Bryan
------------------------------
From: Simon Josefsson <[EMAIL PROTECTED]>
Subject: Re: Weird Rijndael test vectors wanted
Date: 09 May 2001 12:07:45 +0200
[EMAIL PROTECTED] (Mark Wooding) writes:
> Does anyone have any Rijndael test vectors for Nk = 5 or 7? The
> reference implementation doesn't seem to support these, although they're
> in the spec (second version). Just one of each would be fine.
Do you get these values? I do, but I just added Nk={5,7} support to
my implementation so it's not verified to be correct. (Nb=4)
KEY=0000000000000000000000000000000000000000
PT=00000000000000000000000000000000
CT=32CB23EE8DEBD0D4E0983EE4D3318A5F
KEY=00000000000000000000000000000000000000000000000000000000
PT=00000000000000000000000000000000
CT=BE47C9BF5D104A8EC32A13C94596237C
------------------------------
** 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
******************************
