Cryptography-Digest Digest #537
Cryptography-Digest Digest #537, Volume #13 Wed, 24 Jan 01 02:13:00 EST Contents: Re: Fitting Dynamic Transposition into a Binary World (Kenneth Almquist) Re: TSEPRNG, a secure RNG ? (Bryan Mongeau) Re: Dynamic Transposition Revisited (long) (Terry Ritter) Re: Dynamic Transposition Revisited (long) (Terry Ritter) Re: Dynamic Transposition Revisited (long) (Terry Ritter) Re: Dynamic Transposition Revisited (long) (Terry Ritter) From: [EMAIL PROTECTED] (Kenneth Almquist) Subject: Re: Fitting Dynamic Transposition into a Binary World Date: 24 Jan 2001 05:41:18 GMT [EMAIL PROTECTED] (John Savard) wrote: > 2^160 equals > 1461501637330902918203684832716283019655932542976 > > and the number of 164-bit balanced strings is > 1454706556296192477283016662986999417820887445240 > > so one way to use Dynamic Transposition on arbitrary binary sequences > would be to have a coding for 160-bit arbitrary sequences into 164-bit > balanced sequences. > > Some sequences of 160 bits wouldn't have an equivalent, and so would > have to be converted to something else; either to shorter balanced > sequences, which could also be enciphered by Dynamic Transposition, or > to some other kind of object to be enciphered in another way. This means that your encoding is effectively variable length. For each 160-bit sequence, you need to transmit an indication of whether it has been encoded as a 164-bit balanced sequence, or some other way. This wastes communication bandwidth (though not a lot) and also complicates the encoding because the indication cannot be transmitted in the clear (or you leak information). Might I suggest coding 158-bit arbitrary sequences as 162-bit balanced sequences? There number of 162-bit balanced sequences is 365907784099042279561985786395502921046971688680 while 2^158 is slightly less: 365375409332725729550921208179070754913983135744 This would create a fixed overhead of four additional bits for every 158-bit block, which would add a communication overhead of about 2.53%. If you decided to use a block size of 128 bits (in order to interface to standard 32 and 64 bit hardware more easily), adding four bits per block amounts to a communication overhead of 3.125%, which is still quite reasonable. > Of course, this kind of begs the question of how to devise an > efficient coding for arbitrary strings into balanced strings. From > arbitrary binary strings, one could use a simple numeration of > balanced strings... > > = 01 > 0001 = 10 > 0010 = 110111 > 0011 = 111011 > ... > 1011 = 10 > 1100 ... coded to something else > > and maybe there *might* be a simple algorithm to do this for strings > too large to put in a table Finding an algorithm to do this is an interesting challenge. The arbitrary strings can be regarded as binary numbers. We define a mapping between balanced strings and numbers by listing the balanced strings in lexical order and numbering them starting from zero, as you have done above. The first thing to note is that we can compute the number of balanced strings with a given prefix relatively efficiently. For example, let's say that our balanced strings are 162 bits long, meaning they contain 81 "1" bits and 81 "0" bits. If we want to know how many strings have the prefix "110", we count the number of zeros and ones in the prefix. There are two "1" bits and one "0" bits. This means that the remainder of the string must have 79 "1" bits and 80 "0" bits. The number of possibilities is (79+80)! / (79! * 80!). This allows us to process a balanced string from left to right, keeping track of the number of the first (or last) balanced string beginning with the bits we have seen so far. This minimum starts out as zero. As we scan the string, if the next bit is zero, then the minimum is unchanged. If we encounter a one, then we know that all the balanced strings which have a zero where the string we are scanning has a one must lexically precede the string we are scanning. Therefore, we add the number of such strings to the minimum. To compute the number of a balanced string, we perform the operation described in the preceding paragraph, counting the number of "0" and "1" bits as we go along. When we have seen 81 of either type of bit, then there is only one possible value for the remaining bits. (They must be all zeros or all ones.) At that point there is only one balanced string beginning with the bits we have seen so far, and we know what the number of that balanced string is, so we are done. To generate the balanced string corresponding to a number, we modify the algorithm to generate bits rather than reading them. At each step, we first try outputting a "1" bit. If that would make the minimum exceed the number whose bit string we are trying to construct, (or if we have already output 81 "1" bits) we output a "0" instea
Cryptography-Digest Digest #536
Cryptography-Digest Digest #536, Volume #13 Wed, 24 Jan 01 00:13:00 EST
Contents:
Problem solved & thanks... (psyclops)
Re: Dynamic Transposition Revisited (long) (AllanW)
Re: America can teach England something about GUNS ("Harry Krishnah")
Re: Secure game highscore server (graywane)
Re: Dynamic Transposition Revisited (long) ("Matt Timmermans")
Re: Secure game highscore server (Tom St Denis)
Re: 32768-bit cryptography (Tom St Denis)
Re: Secure game highscore server (Paul Rubin)
Re: Why Microsoft's Product Activation Stinks (zapzing)
Re: Question about security of Oracle get_hash_value (Paul Rubin)
caching passwords in windows registry ("Ben Newman")
Re: 32768-bit cryptography ("Scott Fluhrer")
From: psyclops <[EMAIL PROTECTED]>
Subject: Problem solved & thanks...
Date: Wed, 24 Jan 2001 03:02:19 GMT
Thanks for your comments on this subject - I now see that the oracle
hashing function is not the best bet at all!
I am still set on using MD5 though - but not in SQL as I had first
intended. I discovered that you can actually use Java programs as
stored procedures, so I wrote an MD5 Java program, figured out how to
load it into the database (thanks to http://www.auerbach-
publications.com/scripts/fast_track.html and the Oracle docs) using a
function wrapper. The compiled java md5 sproc is ~ 150 times faster
than the original PL/SQL one, I clocked it as crunching 1 hashes in
61 seconds, as compared to 100 hashes in 94 seconds for raw sql
Woohoo!
cheers,
nick.
Nick Donaldson mailto:[EMAIL PROTECTED]
Bit Wrangler Extraordinaire!http://www.psyclops.com/
CLIQ Services Cooperative http://www.cliq.com/
510.531.8722 voice 510.593.5638 mobile
Sent via Deja.com
http://www.deja.com/
--
From: AllanW <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Wed, 24 Jan 2001 03:00:42 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote:
> Dynamic Transposition is unusual in that knowing the plaintext and the
> associated ciphertext does not reveal the enciphering permutation.
> The reason for this is that many different bit-permutations will
> produce the bit-for-bit exact same transformation between plaintext
> and ciphertext. Therefore, having known plaintext does not reveal the
> enciphering permutation, and thus cannot be exploited to begin to
> expose the RNG sequence.
>
> Note that even if the correct permutation were found, the RNG sequence
> which created it would not be exposed to any extent, if
> double-shuffling was used to create the permutation. The reason for
> this is that double-shuffling would use twice the amount of RNG
> sequence as needed for a selection among all possible permutations.
> Double-shuffling is literally an arbitrary permutation from a known
> state, and then another arbitrary permutation from that to any
> possible permutation. Any particular result permutation could be the
> result of any possible first permutation, with the appropriate second
> permutation, or vise versa. Accordingly, one knows no more about what
> sequence was involved than before one knew the correct permutation.
Consider this alternative to double-shuffling (or they could be
used together): Process the entire plaintext once using an
N-byte block. But instead of considering the output to be
ciphertext, pack it into blocks of M-bytes, where M is less than
N/3, and mutually prime to N. For instance, N=2187, M=512. Once
again, use filler bits so that the number of 0-bits and 1-bits
are balanced, and then shuffle that buffer. I haven't thought
this through all the way yet; you might have to use two PRNG's in
order to be able to decrypt the numbers later, but if we can find
a way to know which PRNG values are used for which decoder (i.e
first N for the first buffer, then 3M for the second buffer, and
then N more for the big one and so on), then a single PRNG might
still suffice. The smaller buffer will need slightly more values
than the big one, due to adding a very few bytes to each buffer
to balance 0-bits with 1-bits.
The point of using double-shuffling is to make known-plaintext
attacks more difficult by further masking the actions of the
PRNG. But you also acknowledged that the result of two rounds
of shuffling is equivalent to one round controlled by some
other unknown sequence of random numbers. On the other hand,
using two buffers of different sizes makes the two passes have
different meaning. Also, in order to know that you're using
PRNG values that will succeed, you will have to decode at least
4 of the smaller blocks in order to have enough data to feed
into the larger block. Using two different PRNG's might make
analysis even more difficult.
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent
Cryptography-Digest Digest #535
Cryptography-Digest Digest #535, Volume #13 Tue, 23 Jan 01 22:13:01 EST
Contents:
Cryptographic Camouflage ("Joseph Ashwood")
Re: Some Enigma Questions (David Hamer)
Re: Dynamic Transposition Revisited (long) (William Hugh Murray)
Re: NSA and Linux Security (Shawn Willden)
Re: 32768-bit cryptography ("lemaymd")
In case you don't want to visit my website ("lemaymd")
Re: Some Enigma Questions -- 150*10^18 settings? (wint)
Re: collisions risks of applying MD5 or SHA1 to a 48-bit input ("JL")
Re: Dynamic Transposition Revisited (long) (AllanW)
Secure game highscore server ("Robert Larsen")
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Cryptographic Camouflage
Date: Tue, 23 Jan 2001 16:10:13 -0800
A while back there was a discussion regarding cryptographic camouflage, at
the time there were some things that I couldn't say. Well I recieved notice
a bit ago that I can now say that you can find all the information at
http://www.delphion.com/details?pn=US06170058__ . I will avoid rendering any
personal opinions about it for the time being.
Joe
--
Date: Tue, 23 Jan 2001 19:16:05 -0500
From: David Hamer <[EMAIL PROTECTED]>
Subject: Re: Some Enigma Questions
"Douglas A. Gwyn" wrote:
>
> "David C. Barber" wrote:
[snipped]
> > Q3: The plugs interchanged pairs of characters, hence there were two plugs
> > at each end. Were these plugs keyed to prevent improper insertation?
>
> No need to; they're symmetrical.
Actually they're not symmetrical...each stecker has two pins
at each end - 4mm. and 3mm. in diameter respectively - so
that they can only be inserted into corresponding socket on
the steckerboard in one way. The 'fat' pin at one end is
connected to the 'thin' one at the other thus acting as a
'crossover' for the signal.
David Hamer
--
~~~
David Hamer The Crypto Simulation Group
[EMAIL PROTECTED]or[EMAIL PROTECTED]
~~~
--
From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Dynamic Transposition Revisited (long)
Date: Wed, 24 Jan 2001 00:22:44 GMT
Terry Ritter wrote:
> On Tue, 23 Jan 2001 06:54:04 GMT, in
> , in sci.crypt "Matt
> Timmermans" <[EMAIL PROTECTED]> wrote:
>
> >"Terry Ritter" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> Essentially the problem is one of ambiguity: the idea that Kahn is
> >> talking about a real, practical OTP, when in fact he can only be
> >> talking about the theoretical OTP. For example, he starts out saying:
> >
> >Real practical OTP's do exist, and have been used to good effect.
I agree with Terry on this. It can be nearly practical or nearly provable but
not both.
--
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: NSA and Linux Security
Date: Tue, 23 Jan 2001 17:02:57 -0700
Greggy wrote:
> In article <[EMAIL PROTECTED]>,
> Shawn Willden <[EMAIL PROTECTED]> wrote:
> > And have the courts further upheld the application
> > of those powers, and noted that the reason for such
> > permissiveness is the ongoing state of emergency?
> The congress removed the issue from the jurisdiction of the US Supreme
> Court. We see this when they say, "This is a political matter" and
> deny a hearing. They are not allowed to hear the case and they say
> those words verbatim according to the law passed by congress.
Cites? You'll have to excuse me if I'm not willing to take your word for
it. Really, you should expect a great deal of skepticism, though, since
you're saying some rather surprising things. If what you're saying is
correct, however, you should be able to support it.
Shawn.
--
From: "lemaymd" <[EMAIL PROTECTED]>
Subject: Re: 32768-bit cryptography
Date: Tue, 23 Jan 2001 18:56:49 -0600
Poncho,
From what you've written, it's looks as though simplicity is not this
cipher's weakness. What path would you suggest to strengthen it? I don't
truly understand how you would retrieve a completely random key (which of
course it's not, but for simplicity let's say it is) when you have only the
ciphertext. Theoretically, as is the case with the true stream cipher, one
XOR operation between the key and data should be sufficient to make an
entirely impossible to crack piece of ciphertext. Because of the huge size
of the key utilized by this algorithm, it almost qualifies as a stream
cipher itself. Thanks for your valuable input! : - )
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:94j39m$map$[EMAIL PROTECTED]...
>
> lemaymd <[EMAIL PROTECTED]> wrote in message
> news:94i87e$d0e$[EMAIL PROTECTED]...
> > Poncho,
> > How does this algorithm look? Eight identical rounds are performed
on
> > each byte and each ke
Cryptography-Digest Digest #534
Cryptography-Digest Digest #534, Volume #13 Tue, 23 Jan 01 19:13:00 EST
Contents:
Re: using AES finalists in series? (Bryan Olson)
Re: using AES finalists in series? (wtshaw)
Encrypted file? ("Ernst")
TSEPRNG, a secure RNG ? (Bryan Mongeau)
Re: Why Microsoft's Product Activation Stinks (Noah Simoneaux)
Re: Why Microsoft's Product Activation Stinks (wtshaw)
Re: Creating a self extracting encrypted exe? (Bryan Mongeau)
Re: Some Enigma Questions (David Hamer)
Snake Oil (William Hugh Murray)
Re: TSEPRNG, a secure RNG ? (Splaat23)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Some Enigma Questions (David Hamer)
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: using AES finalists in series?
Date: Tue, 23 Jan 2001 22:38:55 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
>
> Douglas A. Gwyn wrote:
> >[...]
> >Chaining of AES candidates seems to be proposed as a
> >way to feel better about the uncertainty of their actual strength
> >against competent cryptanalysis, but if so that is misguided,
> >since *that* concern has not yet been addressed for chaining.
>
> I think that issue *has* been plainly addressed, and has been implicit
> in most such discussions.
>
> For one thing, a "chain" of ciphers is certainly stronger against
> known-plaintext attacks which could function against an individual
> cipher.
Though probably correct, no proof of that is known. What we
can prove is that against known plaintext or ciphertext only,
the chain must be at least as strong as the first cipher in
the chain. Against chosen plaintext, it must be at least as
strong as the strongest. Both assume independent keys. See:
U. M. Maurer and J. L. Massey.
Cascade ciphers: The importance of being first.
J. of Cryptology, Vol. 6, No. 1, pages 55-61, 1993.
> Simply by preventing access to information which is otherwise
> considered exposed (plaintext and the related ciphertext for one of
> the internal ciphers), whole classes of attacks simply cannot be
> mounted.
That's just a handwave. Excluding the obvious way to mount
the attack proves nothing.
> The other issue is what we do not know. Presumably, your argument is
> that if we are willing to assume that a particular cipher can be
> broken, we might as well assume that all ciphers can be broken, and
> there can be no advantage. So if we can throw a baseball, we should
> be able to throw a house. What is wrong with this reasoning?
That reasoning is your own straw man. I think we can agree
that the three cipher chain with independent keys is a more
conservative design that any one of those three ciphers by
itself. It does not solve the problem of uncertainty about
the strength of encryption. On the issue provable strength we
have a tie.
> If we are willing to accept that some ciphers may be weak (of course
> we would not knowingly use a weak cipher), it is to our advantage to
> use multiple ciphers -- I would say at least three -- including the
> best we know of. If that cipher really *is* good, the data are
> protected. But if there is some weakness in that cipher -- and if
> that weakness can be exploited in the ciphering chain -- then the
> other ciphers may act to protect our data in the face of weakness.
Of course we can apply the same reasoning to the three-cipher
chain to show that we should use a nine-cipher chain. No
matter how many we compose, we never arrive at a method
certain to resist cryptanalysis. Somewhere we must make the
trade-off between efficiency and confidence in security.
Let's not fall for the fallacy that in cipher design, more
conservative means better. The only crypto that can protect us
is the stuff we deploy, not the stuff we advocate. Today the
world of personal and commercial communication runs on
un-authenticated cleartext. To change that, we need to build
crypto into the systems people actually use. AES is for the
real world.
--Bryan
Sent via Deja.com
http://www.deja.com/
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: using AES finalists in series?
Date: Tue, 23 Jan 2001 16:21:17 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> > Terry Ritter wrote:
> > > That idea that we need "key efficiency" represents a time now long
> > > gone. In the context of modern communications, why should anyone be
> > > anxious about sending additional keying material? Do we really worry
> > > about sending another 256 bits, or 1024 bits, or whatever? This is
> > > message key material, random and endless; we can take all we need, and
> > > send it at almost no cost.
>
> This is utterly wrong. I'm currently working on the design of a
> new communication system, and key distribution is a major issue.
You too?? What will we do with so much expertise? I reflect that Herr
Ritter already sees efficiency as impor
Cryptography-Digest Digest #533
Cryptography-Digest Digest #533, Volume #13 Tue, 23 Jan 01 18:13:00 EST
Contents:
Re: Some Enigma Questions ("Douglas A. Gwyn")
Re: cryptographic tourism in Russia (Jim)
Re: Some Enigma Questions (Jim)
Re: Some Enigma Questions ("Robert Reynard")
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Some Enigma Questions ("Douglas A. Gwyn")
Re:O.T. Corpspeak was (Why Microsoft's Product...) ("Paul Pires")
Re: Why Microsoft's Product Activation Stinks (phil hunt)
Creating a self extracting encrypted exe? ("Ernst")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Some Enigma Questions ("Douglas A. Gwyn")
Re: Creating a self extracting encrypted exe? ("Paul Pires")
Re: JPEG infidelity for crypto (wtshaw)
KASUMI Analysis? (Was: Re: 3G crypto algorithms) (Kenneth Almquist)
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Some Enigma Questions
Date: Tue, 23 Jan 2001 20:02:32 GMT
"David C. Barber" wrote:
> ... why doesn't the plug board remove, or at least greatly
> reduce this vulnerability e.g. A->R->plug board->A?
Because the plugboard accomplishes just a relabeling of the keys.
> Q2: How did the plug board disconnect the previous straight through
> mapping? Did the process of inserting the plug disconnect the previous
> wiring in the same manner that inserting headphone plugs in some stereo
> systems automatically disconnects the main speakers?
Yes; the jacks are "normally closed" and were quite common in
telephone switchboards.
> Q3: The plugs interchanged pairs of characters, hence there were two plugs
> at each end. Were these plugs keyed to prevent improper insertation?
No need to; they're symmetrical.
> Q4: Is there still a commercial version of the Enigma for sale that is
> essentially the WW II machine?
Not unless somebody is manufacturing them specially for collectors.
> Q5: If properly used (e.g. few messages, good mixing of rotor settings, no
> obvious rotor settings (e.g. QWE), varying messages to avoid obvious cribs,
> having all rotor increment the next rotor at the same position, not sending
> the same message in more than one cipher system, changing of rotors more
> often than once a war, etc), say along the lines of the German Navy, would
> an Enigma today be reasonably secure? Put another way, would it be easily
> crackable today by a single person with some cracking tools and a computer,
> or would it require a high level team like that assembled during the war?
It depends on who is doing the work. A *lot* more is now known
about cryptanalysis of rotor systems in the classified crypto
community than was known when Bletchley Park was operating.
> Q6: How critical is the rotor wiring? While there are some obvious weak
> rotors (e.g. a straight through design, a Caesar cipher rotor, or
> duplicating the same wiring on the second 13 positions of the rotor), is it
> easy or hard to create weak rotors?
This requires a long discussion of cycles, Good diagrams, etc.
which I am not in a position to explain.
> Q7: Did the German Navy's creation of a 4th rotor position that included a
> rotor that in one position made the machine act like 3 rotor machine result
> in a weakened 4th rotor -- even if it hadn't already been compromised
> otherwise? Seems to me what the 4th rotor did was simply create a 3 rotor
> machine with 26 possible reflecting rotors, instead of the previous 1 fixed
> rotor. Right or wrong?
I was under the impression that the additional rotor was a true rotor.
--
From: [EMAIL PROTECTED] (Jim)
Subject: Re: cryptographic tourism in Russia
Reply-To: Jim
Date: Tue, 23 Jan 2001 21:02:25 GMT
On Tue, 23 Jan 2001 10:54:23 +0300, "Vladimir Katalov" <[EMAIL PROTECTED]>
wrote:
>
>Eric Lee Green wrote in message ...
>>Hmm... a point there, given that the government there is now run by a
>>former intelligence officer and that they've a nasty habit of
>>imprisoning Americans that they think are nosing around in the wrong
>>place...
>>
>>A friend of a friend spends time in Russia from time to time (he
>>supposedly is a school teacher, but has this strange habit of turning
>>up wherever things are heating up... e.g. Columbia during the worst of
>>the drug wars, Poland when Solidarity kicked out the Communist
>>government, Russia during the failed coup, ...). The stories I hear
>>are pretty bad -- things apparently got pretty lawless for a while,
>>the old government had virtually collapsed into meaninglessness, and
>>the new government apparently is overreacting by attempting to clamp
>>down harshly on all the lawlessness. I'm not sure I'd be adventurous
>>enough to plan a trip to Russia right now.
>
>Exactly. A trip to Russia might be really dangerous nowadays... I don't
>want to scare you, but the situation here looks very similar to Chicago
>in 30's.
No more dangerous than going to America now that
Cryptography-Digest Digest #532
Cryptography-Digest Digest #532, Volume #13 Tue, 23 Jan 01 16:13:01 EST
Contents:
Re: JPEG infidelity for crypto (Kenneth Almquist)
Re: Kooks (was: NSA and Linux Security) ("Douglas A. Gwyn")
Re: using AES finalists in series? ("Douglas A. Gwyn")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Why Microsoft's Product Activation Stinks ("Joseph Ashwood")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Some Enigma Questions ("David C. Barber")
Re: using AES finalists in series? (Terry Ritter)
Re: Cryptographic Windows APIs or OCX? ("Joseph Ashwood")
Re: collisions risks of applying MD5 or SHA1 to a 48-bit input ("Joseph Ashwood")
From: [EMAIL PROTECTED] (Kenneth Almquist)
Subject: Re: JPEG infidelity for crypto
Date: 23 Jan 2001 20:10:47 GMT
[EMAIL PROTECTED] (John Savard) wrote:
> On Sun, 21 Jan 2001 17:03:18 +0800, Dido Sevilla <[EMAIL PROTECTED]>
> wrote, in part:
>
>> What relation does this have to cryptography? Have you missed saying
>> something?
>
> Well, the relation is obvious: simple forms of steganography, which
> depend on preserving things like the LSB of every single pixel, don't
> work with .JPG files.
Steganography is not covered by the sci.crypt FAQ, but my understanding
is that the term refers to hiding data in messages which look like
something else, the point being to disguise the fact that you are
sending encrypted messages. For this purpose, the fact that JPEG is
a lossy compression algorithm is relevant only if the communication
channel applies JPEG compression to all transmitted data. This seems
rather far fetched.
JPEG images would be a good choice for hiding messages precisely because
it is common for multiple compressions of the same scan to appear on the
internet. A typical scheme might work as follows:
1) You and your partner agree on a set of images.
2) When you want to send a message, you select an image and
compression parameters at random. (The compression parameters
should be chosen from a set of "plausible" parameters.)
3) The JPEG image standard specifies that you apply a discrete
cosine transformation, and then round the resulting values
to the nearest integer. (The rounding step makes JPEG lossy.)
Apply the transform, but rather than rounding to the nearest
integer, round up or down based on the next bit of the data to
be hidden. This encodes one bit per pixel.
4) To extract the message, the receiver performs the same discrete
cosine transformation and compares the result with the received
message to determine whether each value was rounded up or down.
If an evesdropper observes multiple copies of the same image being
sent, that might provide a clue that steganography is being used, so
you would want a fairly large number of pictures for this purpose.
The alt.binaries.pictures newsgroups provide a good supply.
> You could complain that we already knew that, and that there are more
> sophisticated (but less efficient) methods of steganography that even
> work with JPEGs; they're mainly used for watermarking.
Watermarking involves modifying an image or other work slightly so
that you can recognize it when you see it again. This is a different
problem than hiding a message. Watermarking systems are designed to
foil deliberate attempts to obscure the watermark by making small
changes to the watermarked copy. The fact that small changes can be
introduced by JPEG compression rather than a deliberate attempt to
obscure the watermark would seem to be irrelevant since protecting
against the latter also protects against the former.
By "small" changes, I mean changes that are not visually obvious. The
example that started this thread was one where the JPEG compression
created visible artifacts. Since these artifacts were not specificly
chosen to obscure a watermark, I suppose the odds are that they would
not affect a typical watermark system.
Note that converting a typical color image to GIF format also loses
information. In a GIF image, each pixel must have a color which
appears in the color map, and the color map is limited to 256 colors.
This typically creates signficant visual artifacts throughout the
image. Of course artificially constructed images (as opposed to
photographic images) can be designed to contain no more than 256
colors. I suspect that a watermark applied to such an image could
be obscured by reducing the watermarked image to 256 colors, and
then fiddling with the low order bits of the color map.
Kenneth Almquist
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Kooks (was: NSA and Linux Security)
Date: Tue, 23 Jan 2001 19:11:01 GMT
Greggy wrote:
> And no inquiry was made of the new four states.
> An oversigh
Cryptography-Digest Digest #531
Cryptography-Digest Digest #531, Volume #13 Tue, 23 Jan 01 15:13:01 EST
Contents:
Re: steganography by random phase carrier convolution (Splaat23)
Some Enigma Questions ("David C. Barber")
Re: secure RNG (Splaat23)
Re: Some Enigma Questions (Jim Gillogly)
Leo Marks dies ("David C. Barber")
Re: Kooks (was: NSA and Linux Security) (Darren New)
Re: Some Enigma Questions ("David C. Barber")
Re: Some Enigma Questions (Jim Gillogly)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Some Enigma Questions (John Savard)
Re: Leo Marks dies (John Savard)
Re: rubik's cube ("Douglas A. Gwyn")
Re: Kooks (was: NSA and Linux Security) (John Myre)
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: steganography by random phase carrier convolution
Date: Tue, 23 Jan 2001 18:04:42 GMT
It doesn't appear to be that spectacular (from my first look). It's
just watermarking with some resistance to filtering. It doesn't solve
the one problem with (image) stenography - if you can get the original
image, you can find that a difference exists and detect the
transmission of data.
As with all watermarking solutions that run on computers under the
control of the user, it will not function as a right management
package. The same data that would all the information to be retrieved
can be used to erase or managle the watermark enough to disable it.
As far as I can tell, this is not that interesting.
- Andrew
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Bailey) wrote:
> http://www.rochesterbusinessnews.com/
> The Rochester (NY) Democrat and Chronicle mentioned tech briefs to be
> put on the web by Kodak,
> (quote)The first installment, released yesterday, highlights Kodak's
> work to make digital imaging copyrights more secure and in developing
> new screens for consumer electronics. (end quote)
> Following a Byzantine trail of links I finally came to this article
> (pdf) which may be of interest to this newsgroup.
>
> Data Embedding Using Phase Dispersion
> Chris Honsinger and Majid Rabbani
>
> Abstract
> A method of data embedding based on the convolution of message data
> with a random phase carrier is presented. The theory behind this
> method is reviewed and it is shown that the technique can be used to
> hide both pictorial and non-pictorial data. The details of the
> procedures used for carrier design, message template optimization,
> message extraction optimization, block synchronization, and rotation
> and scale correction are discussed. Finally, the algorithms benchmark
> results using Stirmark are presented.
> Full text at:
>
http://www.kodak.com/US/plugins/acrobat/en/corp/researchDevelopment/data
Embedding.pdf
>
> John
>
> John
>
Sent via Deja.com
http://www.deja.com/
--
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Some Enigma Questions
Date: Tue, 23 Jan 2001 11:11:55 -0700
Hi.
Just finished Kahn's "Seizing the Enigma". Have also read "Codebreakers" in
the past and "Applied Cryptography" as well as seen the Nova presentation on
PBS.
I *still* have a few Enigma questions I hope the group can help with:
Q1: A weakness of the German reflector rotor machines is always given that
no input character could ever map back to itself. I.e. while A->R, you
could never have A->A. While it is easy to understand why this happens, and
the advantage it can give in checking a suspected plain text against
encrypted text, why doesn't the plug board remove, or at least greatly
reduce this vulnerability e.g. A->R->plug board->A?
Q2: How did the plug board disconnect the previous straight through
mapping? Did the process of inserting the plug disconnect the previous
wiring in the same manner that inserting headphone plugs in some stereo
systems automatically disconnects the main speakers?
Q3: The plugs interchanged pairs of characters, hence there were two plugs
at each end. Were these plugs keyed to prevent improper insertation?
Q4: Is there still a commercial version of the Enigma for sale that is
essentially the WW II machine?
Q5: If properly used (e.g. few messages, good mixing of rotor settings, no
obvious rotor settings (e.g. QWE), varying messages to avoid obvious cribs,
having all rotor increment the next rotor at the same position, not sending
the same message in more than one cipher system, changing of rotors more
often than once a war, etc), say along the lines of the German Navy, would
an Enigma today be reasonably secure? Put another way, would it be easily
crackable today by a single person with some cracking tools and a computer,
or would it require a high level team like that assembled during the war?
Q6: How critical is the rotor wiring? While there are some obvious weak
rotors (e.g. a straight through design, a Caesar cipher rotor, or
duplicating the same wiring on the second 13 positions of the rotor), is it
easy or hard to create weak
Cryptography-Digest Digest #530
Cryptography-Digest Digest #530, Volume #13 Tue, 23 Jan 01 13:13:01 EST
Contents:
Re: Any cryptoanalysis available for 'polymorphic ciphers'? (Joachim Scholz)
Conway Polynomials (Andrei Heilper)
Re: Conway Polynomials (Mehdi-Laurent Akkar)
magazine cryptologia... ("Danijel Kopcinovic")
Re: Conway Polynomials (Mehdi-Laurent Akkar)
Re: Any cryptoanalysis available for 'polymorphic ciphers'? ("Jakob Jonsson")
Re: A Small Challnge ("Frog2000")
Cryptographic Windows APIs or OCX? (Armando P.)
Question: Heard of ENCIPHERMENT COMMUNICATIONS? ("Melinda Harris")
Re: Dynamic Transposition Revisited (long) ("John A. Malley")
Re: Why Microsoft's Product Activation Stinks (JCA)
Re: Conway Polynomials ("Brian Gladman")
Re: magazine cryptologia... (Mok-Kong Shen)
Re: magazine cryptologia... (Quisquater)
Re: Any good source of cryptanalysis source code (C/C++)? (Bob Silverman)
Re: secure RNG (Paul Crowley)
Producing "bit-balanced" strings efficiently for Dynamic Transposition (John Savard)
Re: Fitting Dynamic Transposition into a Binary World (John Savard)
From: Joachim Scholz <[EMAIL PROTECTED]>
Subject: Re: Any cryptoanalysis available for 'polymorphic ciphers'?
Date: 23 Jan 2001 15:21:07 +0100
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> I tried to download the pdf file (English version) several
> times but the process seemed to stuck each time.
The pdf file contains the same information (or lack of it) as the web
page.
Kind regards, Joachim Scholz
--
From: Andrei Heilper <[EMAIL PROTECTED]>
Subject: Conway Polynomials
Date: Tue, 23 Jan 2001 17:05:09 +0200
There has been a discussion about primitive and irreducible polynomials.
The finite fields in Magma are constructed using what they called
"Conway polynomials". Doeas somebody knows what is the definition of
these polynomials.
Andrei Heilper
--
From: Mehdi-Laurent Akkar <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Conway Polynomials
Date: Tue, 23 Jan 2001 15:03:15 GMT
The Conway polynomial C_(p, n) is the lexicographically first monic
irreducible, primitive polynomial of degree n over GF(p) with the property
that it is consistent with all C_(p, m) for m dividing n. Consistency of
C_(p, n) and C_(p, m) for m dividing n means that for a root alpha of C_(p,
n) it holds that beta = alpha^((p^n - 1)/(p^m - 1)) is a root of C_(p, m).
Lexicographically first is with respect to the system of representatives
-((p - 1)/2), ..., - 1, 0, 1, ..., ((p - 1)/2) for the residue classes
modulo p, ordered via 0 < - 1 < 1 < - 2 < ... ((p - 1)/2) (and we only need
to compare polynomials of the same degree). To compute the Conway
polynomial C_(p, n) one needs to know all Conway polynomials C_(p, m) for m
dividing n, and as far as we know, no essentially better method is known
than enumerating and testing the primitive polynomials of degree n in
lexicographical order.
More information: www.google.com
A+ MLA
Andrei Heilper a écrit :
> There has been a discussion about primitive and irreducible polynomials.
>
> The finite fields in Magma are constructed using what they called
> "Conway polynomials". Doeas somebody knows what is the definition of
> these polynomials.
>
> Andrei Heilper
--
From: "Danijel Kopcinovic" <[EMAIL PROTECTED]>
Subject: magazine cryptologia...
Date: Tue, 23 Jan 2001 15:15:42 -0800
anyone knows where i could get some articles published in "cryptologia"
magazine?
thx!
--
From: Mehdi-Laurent Akkar <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Conway Polynomials
Date: Tue, 23 Jan 2001 15:13:13 GMT
> and as far as we know, no essentially better method is known
> than enumerating and testing the primitive polynomials of degree n in
> lexicographical order.
>
Better methods seem to be known but I do not know their efficiency
see for more details
http://ei.cs.vt.edu:8090/Dienst/UI/2.0/Describe/ncstrl.vatech_cs%2fTR-98-14
A+ MLA
>
> More information: www.google.com
>
> A+ MLA
>
> Andrei Heilper a écrit :
>
> > There has been a discussion about primitive and irreducible polynomials.
> >
> > The finite fields in Magma are constructed using what they called
> > "Conway polynomials". Doeas somebody knows what is the definition of
> > these polynomials.
> >
> > Andrei Heilper
--
From: "Jakob Jonsson" <[EMAIL PROTECTED]>
Subject: Re: Any cryptoanalysis available for 'polymorphic ciphers'?
Date: Tue, 23 Jan 2001 16:16:45 +0100
> Hello, on
> http://www.identification.de/crypto/descript.html
> a method is described which the authors call 'polymorphic
> encryption'. They claim it to be the most secure algorithm on the
> market. Of course, this is a site where the authors want to promote
> their product. So, has anyone made an independent cryptoanalysis of
> it?
A
Cryptography-Digest Digest #529
Cryptography-Digest Digest #529, Volume #13 Tue, 23 Jan 01 09:13:01 EST
Contents:
Re: Easy question for you guys... (Paul Rubin)
Re: Why Microsoft's Product Activation Stinks (Gordon Walker)
Re: Easy question for you guys... (Niklas Frykholm)
Re: using AES finalists in series? ("Brian Gladman")
Re: Some help please (Richard Heathfield)
Re: Block algorithm on variable length without padding - redux (B. Wooster)
Re: How to pronounce Vigenere ("*")
Re: How to pronounce Vigenere ("Olivier BREARD")
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Dynamic Transposition Revisited (long) (John Savard)
steganography by random phase carrier convolution (John Bailey)
Re: RE-X-POST Quick-and-Dirty demonstration of twarting US6006328 (Chris)
Any cryptoanalysis available for 'polymorphic ciphers'? (Joachim Scholz)
Re: 3G crypto algorithms (Mok-Kong Shen)
Re: collisions risks of applying MD5 or SHA1 to a 48-bit input (Chris)
Re: Intel assembler code for DES? (Chris)
Re: Any cryptoanalysis available for 'polymorphic ciphers'? (Mok-Kong Shen)
Re: Easy question for you guys... (CoyoteRed)
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Easy question for you guys...
Date: 23 Jan 2001 02:13:49 -0800
CoyoteRed <[EMAIL PROTECTED]> writes:
> I want to take four 8 bit numbers and create an number that can't be
> converted back by an amateur. Resolution can be 12 - 16 bits.
>
> Here is what I'm trying to do. I want to take an IP number and give it
> a not-so unique number. The number of IP's to be converted range maybe
> in the 10-50 range, so I think that should be sufficient.
Why do you want cryptography? Why not just assign a unique number for
each IP? E.g.
sub lookup_ip {
my $ip = shift;
$ip_list{$ip} = $list_size++ unless $ip_list{$ip};
return $ip_list{$ip};
}
You can of course use dbmopen() or tie() to store the list in a dbm
file if you want to keep it around between runs of the program.
But if you really want to cryptographically hash the IP's, try this:
# you may have to load this library from cpan
use Digest::MD5 qw(md5_hex);
$your_secret = "some secret garbage, don't publish";
Then to convert an IP to a 8 digit hex code:
$hash = substr (md5_hex ($ip + $secret), 0, 8);
You're not likely to get duplicate hex codes til you've hashed
around 64k different IP addresses.
--
From: Gordon Walker <[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Tue, 23 Jan 2001 10:09:39 +
On Mon, 22 Jan 2001 23:30:18 -0800, Anthony Stephen Szopa
<[EMAIL PROTECTED]> wrote:
>Did you develope an anti-piracy computer software module that will
>prevent perhaps half at a minimum of the illegal copying of
>computer software in the world? Do you know how important a
>contribution this is?
Personally I wouldn't boast about it even if I had invented the thing.
In Windows it will prove to be an annoyance that will in no way slow
down real piracy and will rather only damage sales. In the mass market
the scheme is infeasible.
--
Gordon
--
From: [EMAIL PROTECTED] (Niklas Frykholm)
Subject: Re: Easy question for you guys...
Date: Tue, 23 Jan 2001 10:24:05 + (UTC)
In article <[EMAIL PROTECTED]>, CoyoteRed wrote:
>I want to take four 8 bit numbers and create an number that can't be
>converted back by an amateur. Resolution can be 12 - 16 bits.
>
>Here is what I'm trying to do. I want to take an IP number and give it
>a not-so unique number. The number of IP's to be converted range maybe
>in the 10-50 range, so I think that should be sufficient.
>
>What I'm trying to do is identify a poster on a bulletin board without
>giving out the IP or computer name. (or force user names and
>passwords)
>
>Here's the kicker, I want to use simple math that is available in
>Perl, in the fewest lines possible, and be easy enough to understand
>that almost anyone can follow the math. But be unable to reverse the
>process easily.
Why not use cookies to identify the posters? That's what they are there
for. IP identification doesn't work well with dynamic IP adresses or proxies.
But if you really want to do it:
sub make_secret {
use Digest::SHA1 sha1_base64;
my $secret = "put_some_random_characters_here";
sha1_base64(join(@_,".").$secret);
}
Truncate the return value to desired length (the shorter, the higher is the
risk of collision).
If someone finds out your secret they can calculate the IP addresses without
too much trouble.
// Niklas
--
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: using AES finalists in series?
Date: Tue, 23 Jan 2001 10:27:22 -
"Joseph Ashwood" <[EMAIL PROTECTED]> w
Cryptography-Digest Digest #528
Cryptography-Digest Digest #528, Volume #13 Tue, 23 Jan 01 05:13:01 EST
Contents:
Re: Why Microsoft's Product Activation Stinks (Anthony Stephen Szopa)
Re: cryptographic tourism in Russia ("Vladimir Katalov")
Re: Easy question for you guys... (Anders Thulin)
another Microsoft lawsuit on the horizon (Matthew Montchalin)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: collisions risks of applying MD5 or SHA1 to a 48-bit input (Serge Paccalin)
Re: Some help please (Jim Gillogly)
Re: Some help please ("Douglas A. Gwyn")
Re: Easy question for you guys... (Anders Andersson)
Re: Some help please ("Jakob Jonsson")
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Mon, 22 Jan 2001 23:30:18 -0800
Richard Heathfield wrote:
>
> Anthony Stephen Szopa wrote:
> >
>
> >
> > So that's all I have to say for a while.
>
> Is that a promise?
Here is a guy who spits on the souls of anyone for no damned reason.
I told you that I am the inventor that will save people tens or
hundreds of billions of dollars in lost revenue and you verbally
shit on me with your sarcasm.
Did you develope an anti-piracy computer software module that will
prevent perhaps half at a minimum of the illegal copying of
computer software in the world? Do you know how important a
contribution this is?
I can prove that I did this. And if I eventually do prove it
publicly everyone will know you are a fool. But most importantly
you will know. I think you probably already know you are a fool.
I am certainly one of a very very few and perhaps the only person in
the world who can prove that they did it before MS. I am not going
to divulge my thought processes here or my plans or my actions
regarding the implications of this situation at this time, as I have
said. I am actively pursuing my interests.
I think I read that there is about $50 billion dollars worth of
computer software piracy going on every year.
You must be a real high achiever to top this. Tell your friends
what a proud soul you are and give them the example you posted here
and explain to them why you are the one to be so sarcastic. What
are your qualifications?
I would tell them that you are a high risk gambler and that they
should stay as far away from you as possible. You just can't
believe that I did what I say I did, can you? You think you can
make the jump and take the leap to ridicule me. You have no proof
that I am lying. Yet you risk your reputation. As I said, you have
poor judgment although you have calculated that you are on solid
ground. Quicksand, yes. You are in quicksand and there will be no
one to come to your aid. Just wait and see.
If and when the proof comes out I hope someone brings it to you
attention.
I was waiting for a worm to show their slime. You finally showed up.
What is a fool? A fool is a person who plays an Eric Clapton song
on their own guitar. He plays the song perhaps even as good as Eric
Clapton. And then he thinks he is as great an artist as Eric
Clapton.
You are an even greater fool than this because you would play the
air guitar while listening to Eric Clapton and really believe you
are as great a musician and artist as Eric Clapton.
Can you feel your heart literally shrinking? You will.
Thanks a lot.
AS
Gee, you didn't get any more significant information from me about
my claim?
Too bad.
--
From: "Vladimir Katalov" <[EMAIL PROTECTED]>
Subject: Re: cryptographic tourism in Russia
Date: Tue, 23 Jan 2001 10:54:23 +0300
Eric Lee Green wrote in message ...
>Hmm... a point there, given that the government there is now run by a
>former intelligence officer and that they've a nasty habit of
>imprisoning Americans that they think are nosing around in the wrong
>place...
>
>A friend of a friend spends time in Russia from time to time (he
>supposedly is a school teacher, but has this strange habit of turning
>up wherever things are heating up... e.g. Columbia during the worst of
>the drug wars, Poland when Solidarity kicked out the Communist
>government, Russia during the failed coup, ...). The stories I hear
>are pretty bad -- things apparently got pretty lawless for a while,
>the old government had virtually collapsed into meaninglessness, and
>the new government apparently is overreacting by attempting to clamp
>down harshly on all the lawlessness. I'm not sure I'd be adventurous
>enough to plan a trip to Russia right now.
Exactly. A trip to Russia might be really dangerous nowadays... I don't
want to scare you, but the situation here looks very similar to Chicago
in 30's.
St Petersburg is a bit better (more safe) than Moscow. You will not find any
crypto-related stuff
