Cryptography-Digest Digest #389, Volume #13 Mon, 25 Dec 00 12:13:00 EST
Contents:
Re: Merry Christmas ("John A. Malley")
Re: All irreducible polys of degree 32 over GF(2) (Bryan Olson)
MD5 and hash127 questions ([EMAIL PROTECTED])
Re: Foolproof Quantum Cryptography (PB)
Re: RSA == hash function? ("Tom ST Denis")
Re: Steganography using text as carrier (Andre van Straaten)
Re: Foolproof Quantum Cryptography (PB)
Re: Foolproof Quantum Cryptography (PB)
Re: All irreducible polys of degree 32 over GF(2) (Benjamin Goldberg)
polynomial permutation cipher (Benjamin Goldberg)
polynomial permutation cipher (Benjamin Goldberg)
----------------------------------------------------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Merry Christmas
Date: Mon, 25 Dec 2000 00:14:54 -0800
David A Molnar wrote:
>
> That being said, happy holidays!
> (and a crypto question: what does Santa use to keep his list of
> "naughty" and "nice" children private? how does he look up a kid in the
> database?)
Christmas hash?
http://chef2chef.com/recipes/jfolse/stir509.shtml
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: All irreducible polys of degree 32 over GF(2)
Date: Mon, 25 Dec 2000 09:18:09 GMT
Benjamin Goldberg wrote:
> But I did not say that I *knew* that the attacker knowing
> the entire message would automatically enable him to get
> the generator output, only that it MIGHT, concievably, be
> possible.
O.K. That's why I asked. Against this cipher, I thought my
explanation of how to determine some outputs uniquely and
narrow down the others to several candidates was reasonably
clear. Admittedly, solving the Mersenne Twister recurrence
would be a good deal of work. The scheme was presented as
seemingly secure "provided that you do have a statistically
good PRNG, like Mersenne Twister." For other such PRNG's,
for example as large LFSR's or integer additive generators,
the solution is straightforward.
Incidentally, within the last week you suggested a linear
three-pass protocol and asserted the difficulty of inverting
a certain matrix. As in the current discussion, I believe
that I (and another) refuted those, but you have not said
you know them to be weak. Are those settled?
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: MD5 and hash127 questions
Date: Mon, 25 Dec 2000 12:26:01 GMT
Hi, I have two questions: 1 Mr.Bruce Schneier's "Secrets and Lies" book, page
94, 5 lines from the bottom: " ...MD5 is showing some cracks and is not used
for anythong new." Is this true? What kind of cracks? What about TCP/IP syn
cookies - they are almost new and they use MD5.
2. Some oppinions about Mr. D.JBernstein's hash127 and sigs packages. Can I
make ASCII armored ciphertext with them?
Best Regards,
S.I.Jekov
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (PB)
Subject: Re: Foolproof Quantum Cryptography
Date: Mon, 25 Dec 2000 13:12:14 GMT
On Sun, 24 Dec 2000 16:37:42 -0500, Steve Portly <[EMAIL PROTECTED]>
wrote:
<snip>
>>Just to sidetrack a bit on quantum cryptography (of which I am no
>> expert), it seems to me that, if I wanted to stop anybody using it, I
>> would just intercept all their messages. They would be aware the messages
>> had been intercepted because (I think) the photon states would have
>> changed and the message they received with therefore be garbage, forcing
>> them to use a more accessible system.
>>
>> Or maybe I'm wrong.
>
>A denial of service attack would be practical in most cases however one of
>the articles mentioned the primary use would be for rekeying satellites.
>
Of course, if you communicate using entangled particles (which I
believe they have managed to do at CERN - just as soon as Christmas is
over I'll be able to look these things up) then there is nothing (?)
to intercept?
------------------------------
From: "Tom ST Denis" <[EMAIL PROTECTED]>
Subject: Re: RSA == hash function?
Date: Mon, 25 Dec 2000 13:42:46 GMT
<[EMAIL PROTECTED]> wrote in message news:926r69$52f$[EMAIL PROTECTED]...
> In article <sXm16.11676$[EMAIL PROTECTED]>,
> "Tom ST Denis" <[EMAIL PROTECTED]> wrote:
> >
> > <[EMAIL PROTECTED]> wrote in message
> news:924mjv$okj$[EMAIL PROTECTED]...
> > > I think RSA cannot be considered as a hash function because its
> input
> > > and output length is a variable depending on the modulo n. Hash
> > > function should take variable input length and produce fixed length
> > > output.
>
> > This is simply not true. The size of RSA parameters are always
> fixed. While
> > it's true in some cases they can be optimized but 99% of the time they
> > can't. RSA plaintext and ciphertext ARE THE SAME SIZE!
>
> I agree that RSA with cipher block chaining can take variable input
> length. I overlook this case.
>
> Let's scope down the hash function to one-way hash function.
> Can RSA in block chaining mode be a one-way hash function?
No it can't be turned into a safe hash function. Plus it's slow.
Tom
------------------------------
From: Andre van Straaten <[EMAIL PROTECTED]>
Subject: Re: Steganography using text as carrier
Date: 25 Dec 2000 08:32:13 -0600
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> Andre van Straaten <[EMAIL PROTECTED]> wrote:
>> > assume the following carrier text:
>>
>> > <received your e-mail, will respond soon>
>>
>> > assume the following message text:
>>
>> > <delete and wipe everything in your z folder immediately!>
>>
>> > the algorithm would first transform the two messages into ascii
> three
>> > digit strings:
>>
>> > carrier text:
>>
>> > 114 101 099 101 105 118 101 100 032 121 111 117 114 032 101 045 109
> 097 105 108 044 032 119 105 108 108 032 114 101 115 112 111 110 100 032
> 115 111 111 110
>>
>> > message text:
> 100 101 108 101 116 101 032 097 110 100 032 119 105 112 101 032 101 118
> 101 114 121 104 105 110 103 032 105 110 032 121 111 117 114 032 122 032
> 102 111 108 100 101 114 032 105 109 109 101 100 105 097 116 101 108 121
> 033
>>
>> > the algorithm now compares the strings of the two texts, sees that
> the
>> > carrier text is shorter, and adds the 032 representation for empty
>> > space to make the two texts of equal length:
>>
> 114 101 099 101 105 118 101 100 032 121 111 117 114 032 101 045 109 097
> 105 108 044 032 119 105 108 108 032 114 101 115 112 111 110 100 032 115
> 111 111 110 032 032 032 032 032 032 032 032 032 032 032 032 032 032 032
> 032
>> > it would then compute the offset, and represent it as a MPI.
>>
>> I see you use the ASCII character set. In former posting, you
> suggested
>> an operation like this:
>> resulting string = 256 - message text + carrier text
> actually, 300 - M + C
>>
>> I leave spaces between the 3-digit-numbers for better reading.
>>
>> 270 256 247 256 245 ... ... ... 183 191 172 187 180 167 255
>>
>> I calculated only the beginning and the end to avoid writing a program
>> for that.
>>
>> You see that the tail looks different from the head.
>>
>> If you meant another operation, please show it here instead.
>>
> i did mean that operation, but did not show it in the previous post , i
> showed only the representations of the message and character texts
> [sorry],
> the operation to get the offset of message to carrier text is
> <Offset = 300 - Carrier + Message> for each ascii triad, and for the
> above example, is:
> 286 300 309 300 311 283 231 297 378 279 221 302 291 380 300 287 292 321
> 296 306 377 372 286 305 295 224 373 294 231 306 299 306 304 232 390 217
> 291 300 298 368 369 382 300 373 377 377 369 368 373 365 384 369 376 389
> 301
> to re-construct the message, given the offset and carrier, the
> operation is: <Message = Offset + Carrier - 300> for each ascii triad
>> But I don't see any difference to an OTP.
> correct, there are none, as a proposal for a new cryptographic method.
> there are already many excellent and abundantly secure methods, but not
> one {that i know of, anyway ] method for undetectable steganography(by
> scrutinous systematic analysis) with really plausible deniablility.
There is at least one. If you use the OTP with XORing ASCII characters,
you do
P ^ K = C
which means xor'ing every byte of the plaintext with every byte of the
key text delivers the ciphertext.
Generally, you use random bytes for the key text. If you use a send a
sensible ASCII instead, you have two pieces which together form the
plaintext P: the key text K and the ciphertext C.
If you transmit the ciphertext C (which contains non-readable characters)
the same way as you carriertext, you can transmit or make public the
key text which is a nice, sensible text.
The only disadvantage apart from the management of the ciphertext in this
case (generally the key text for OTP's), is that you have not chosen
randomly your key text and you'll deliver some, even if minimal, clues
if you send many messages over a long time that way.
> in this proposal, if a recipient has an agreed carrier text set up, and
> is sent an e-mail in html by which an MPI can be recovered, it is
> undetectable from the e-mail text, or from the base 64 encoding, and
> has plausible deniability in that the judicious choices of fonts, font
> sizes, underlining, italicizing, are a personalization of the e-mail
> appearance.
> as an attacker would not have access to the carrier text, and the
> carrier text would be changed each time, there is complete deniablilty,
> and impossiblilty of demonstrating a hidden message.
>>
>> > There are many possible ways to unobtrusively hide/mark things in
>> > carrier text.
>>
>> Not on a byte basis as you describe it.
>> E.g.:
>> You have two ASCII characters: "re"
>> This is decimal 114, 101
>> or bitwise
>> r: 0111 0010
>> e: 0110 0101
>>
>> You can change only a bit, as this is the smallest atomic unit
>> in computer memories.
>> There is nothing to hide in between, or like that.
>> And if you flip only one bit, you have another ASCII character.
>> So, there is not even one way to "unobtrusively hide/mark things".
>>
> Example:
> assign a value of 0-9 corresponding to a font size of 10-19
> so that a font displayed at this range [not unusual for a subject
> heading in the beginning of a text ]denotes a number from 0-9.
> assign a number from 0-9 to each of 10 different unobtrusive font types
> to be used.
> assign a number from 0-9 to each one of 10 different plausible
> stationeries.
> assign a value to each of combination boldface, italicized, underlined
> and whether it appears within the subject heading or the body of the
> text -- 12 different combinations
> the intent being to eventually be able to denote a representation of an
> mpi in the form (aSubN,aSubN-1,...aSub0)subB where B is the radix base
> {see Handbook of Applied Cryptography, p591 ff )
> as there are a limited number of things that can be varied, this may
> limit the size of the mpi that can be represented, and the size of the
> message that can be sent, {and this will need some further analysis and
> creative thought}
> but as can be seen, this is not too difficult to do without changing
> the ascii characters of the text at all.
>> This means you can only change bits where they are redundant or quasi-
>> redundant as in color bytes of grahics, e.g.
>> In ASCII text, there are no redundant bits. You can only insert
>> whitespace or typos.
> no bits are being changed, the message is sent with html turned on
> and 'rich' text allowed. The patterns of the choices of the rich text
> is what will be used to set up the system.
>> One suggestion:
>> Try all your ideas explicitely, for example writing down bytes bit by
>> bit.
>> Intuition is good for having ideas, but to proof them you have to show
>> it explicitely. Mathematics are very helpful to strongly needed.
>> "Elementary Cryptanalysis" from Abraham Sinkov is good book for
> beginners
> ok, will try, while not a mathematician, did minor in math, and can
> follow Menezes, but not quickly or easily,
> would prefer something in between "The Code-Breakers' and Schneier or
> Menezes, hopefully the text you suggested will be a good starting
> point.
It doesn't require many prerequisites, so it's good for starting.
I think steganography, is not so much mathematical as cryptography, as
it applies fewer principles over and over again in different real-time
situations which are difficult to categorize.
-- avs
Andre van Straaten
http://www.vanstraatensoft.com
The signs and the omens are everywhere
But too few see them - too few even care
(Lee Clayton - singer/songwriter, 1979)
====== 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: [EMAIL PROTECTED] (PB)
Subject: Re: Foolproof Quantum Cryptography
Date: Mon, 25 Dec 2000 15:43:55 GMT
On Sun, 24 Dec 2000 11:47:42 GMT, [EMAIL PROTECTED] (PB)
wrote:
>On Sun, 24 Dec 2000 14:29:50 +0800, Dido Sevilla <[EMAIL PROTECTED]>
>wrote:
>
>>Matt Timmermans wrote:
>>>
><snip>
>>This is not true. There are quantum computers already running in
>>several experimental labs all over the world, though they're of
>>pathetically small scale. Several people have successfully experimented
>>with bulk spin resonance and ion trap approaches to quantum computers,
>>but none of these is useful for doing anything other than simulating
>>some simple low-level quantum phenomena, due to the fact that the number
>>of qubits they have available is pathetically small. IIRC, the ion trap
>>team was only able to produce two qubits, while the bulk spin resonance
>>team four, meaning that the largest number that they can try factoring
>>using Shor's algorithm is only 15!
>I seem to recall a 7 qubit machine - I will look up the reference
>after Christmas :-)
yep, LAL did 7 qubits, but their NMR technique tops out at 15 qubits.
So that probably won't be the route for a "final" design.
http://www.wired.com/news/technology/0,1282,35121,00.html
cheers
pete
------------------------------
From: [EMAIL PROTECTED] (PB)
Subject: Re: Foolproof Quantum Cryptography
Date: Mon, 25 Dec 2000 15:43:57 GMT
On Sun, 24 Dec 2000 16:37:42 -0500, Steve Portly <[EMAIL PROTECTED]>
wrote:
>>
>> Just to sidetrack a bit on quantum cryptography (of which I am no
>> expert), it seems to me that, if I wanted to stop anybody using it, I
>> would just intercept all their messages. They would be aware the messages
>> had been intercepted because (I think) the photon states would have
>> changed and the message they received with therefore be garbage, forcing
>> them to use a more accessible system.
>>
>> Or maybe I'm wrong.
>
>A denial of service attack would be practical in most cases however one of
>the articles mentioned the primary use would be for rekeying satellites.
Does anyone know if there is a way to communicate using entangled
particles/quantum teleportation (Uni of Geneva - not CERN, my mistake)
which does not provide anything to intercept? [See New Scientist, 11
Oct 1997!! for Cambridge Uni's work]
cheers
pete
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: All irreducible polys of degree 32 over GF(2)
Date: Mon, 25 Dec 2000 15:39:51 GMT
Bryan Olson wrote:
>
> Benjamin Goldberg wrote:
> > But I did not say that I *knew* that the attacker knowing
> > the entire message would automatically enable him to get
> > the generator output, only that it MIGHT, concievably, be
> > possible.
>
> O.K. That's why I asked. Against this cipher, I thought my
> explanation of how to determine some outputs uniquely and
> narrow down the others to several candidates was reasonably
> clear. Admittedly, solving the Mersenne Twister recurrence
> would be a good deal of work. The scheme was presented as
> seemingly secure "provided that you do have a statistically
> good PRNG, like Mersenne Twister." For other such PRNG's,
> for example as large LFSR's or integer additive generators,
> the solution is straightforward.
You seem to suddenly be jumping from the suggestion that it is
concievably possiple for someone who knows the entire plaintext to get
the PRNG output, to the idea that it is "straightforward" to get the
seed from the ciphertext if a different prng is used.
I still have not seen you or anyone else say how one can learn the
generator output, given the entire plaintext and the entire ciphertext.
IF someone knows the generator output, it is relatively easy to get the
seed for mt or either of the other prngs you suggested -- although mt
needs more data and computation time to do this, the formulae for
working backwords from output to seed do exist.
> Incidentally, within the last week you suggested a linear
> three-pass protocol and asserted the difficulty of inverting
> a certain matrix. As in the current discussion, I believe
> that I (and another) refuted those, but you have not said
> you know them to be weak. Are those settled?
Within the last week I made some comments on someone else's suggestion
for a three-pass protocol, and [mistakenly] agreed with someone else's
assertion that inverting a matrix under multiplication mod pq was
difficult without p and q (within that same thread).
I think that it's been settled that that particular key exchange idea is
weak.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: polynomial permutation cipher
Date: Mon, 25 Dec 2000 16:23:08 GMT
This idea is nearly identical to a scheme I recently suggested as an
AONT (except I don't output the key afterwards). The security is
dependent on a function which generates a permutation on the values from
0 to 2^32-1, but encrypting a counter.
k = hash( secret key || IV )
counter = 0
repeat (messagelength/4) times {
do {
poly = E_k( counter );
counter = counter + 1;
} until( irreducible( poly ) );
output( crc( file, poly ) );
}
Decryption is done using the Chinese Remainder Theorem on all of the
polynomial/crcvalue pairs.
Because E_k produces a permutation, we can be certain that no crc poly
is sent more than once, and because all polys used are irreducible, we
can optimize our CRT implementation in some ways.
Can anyone see any attacks on this system? (Assuming that neither the
hash function, nor E, are broken to start with.)
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: polynomial permutation cipher
Date: Mon, 25 Dec 2000 16:27:37 GMT
This idea is nearly identical to a scheme I recently suggested as an
AONT, except I don't output the key afterwards. The security is
dependent on a function which generates a permutation on the values from
0 to 2^32-1, by encrypting a counter.
k = hash( secret key || IV )
counter = 0
repeat (messagelength/4) times {
do {
poly = E_k( counter );
counter = counter + 1;
} until( irreducible( poly ) );
output( crc( file, poly ) );
}
Decryption is done using the Chinese Remainder Theorem on all of the
polynomial/crcvalue pairs.
Because E_k produces a permutation, we can be certain that no crc poly
is sent more than once, and because all polys used are irreducible, we
can optimize our CRT implementation in some ways.
Can anyone see any attacks on this system? (Assuming that neither the
hash function, nor E, are broken to start with.)
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
** 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
******************************
