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 +0000

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 +0000 (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 -0000

"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:O0U$AvMhAHA.274@cpmsnbbsa07...
> "John Myre" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > it's false economy to try to derive all of
> > that key material from some "small" base (e.g. 128 bits),
> > because there is no reason to trust the derivation that
> > much?
>
> It's a not as subtle problem as that. If you are given 128 bits of
entropy,
> you can manage only 128-bit security. This rule applies no matter how many
> deterministic operations you perform to get different keys. When you chain
> the AES finalists, you are attempting to get 5*128-bit security, at a
> minimum. Because of that you will need at least 5*128 bits of entropy to
get
> that level of security.

Not necessarily since some of those who want serial chaining are not seeking
key space expansion.  For example, one interest is not that of increasing
the key space but rather that of reducing the probability that the key space
is a great deal smaller than is implied by a 128 bit key because a single
cipher which is being used is found to have a significant weakness.

In any event it is strange to see people suggesting that 128 bit keys for
symmetric block ciphers are too short when we simply do not have
cryptographic implementation contexts that come anywhere close to
maintaining the security implied by such keys.  2^128 is around 10^38 and it
does not take too much thought to realise that engineering an environment
that reduces the probability of unintended key exposure to around 10^-38 is
not a trivial task.

Despite widespread advertising claims of '128 bit security', most users will
be very lucky to achieve even 20 bits of real key space.  Once key lengths
go above a few tens of bits the most serious 'real world' issue becomes that
of systems assurance - being confident that some aspect of systems operation
is not undermining the intended strength of the cryptography being used.

  Brian Gladman




------------------------------

Date: Tue, 23 Jan 2001 11:06:05 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Some help please

Jakob Jonsson wrote:
> 
> > I received this following msg, I believe it is using some simple
> > monoalphabetic cipher, but I am lacking time and expertise to decrypt
> > it....
> 
> It couldn't possibly be monoalphabetic substitution, because the 2nd and 4th
> letters are different. This is, of course, polyalphabetic  substitution.
> 
> :)

Wicked child! :-)

(But an excellent catch...)

-- 
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

------------------------------

From: B. Wooster <[EMAIL PROTECTED]>
Subject: Re: Block algorithm on variable length without padding - redux
Reply-To: [EMAIL PROTECTED]
Date: Tue, 23 Jan 2001 11:12:27 GMT

Not quote.  Maybe in non-CBC mode. 
_______________________________

>On Mon, 22 Jan 2001 20:42:37 -0800, "Scott Fluhrer" <[EMAIL PROTECTED]> wrote:
>I don't have a copy of _AC_ in front of me, but if I recall correctly, the
>above suggestion *was* what Schneier mentioned.


------------------------------

From: "*" <[EMAIL PROTECTED]>
Subject: Re: How to pronounce Vigenere
Date: Tue, 23 Jan 2001 13:23:32 +0100

YOU ARE RIGHT, that's the way it should be pronounced....




Bryan Mongeau a �crit dans le message ...
Isn't the word of French origin?
In that case it would be pronounced:

"vee-jhe-nair"

Pronounce "jhe" like the french say "I" ("je").

--
<==================================>
Bryan Mongeau
Lead Developer, Director
eEvolved Real-Time Technologies Inc.
www.eevolved.com
<==================================>

"As far as the laws of mathematics refer to reality, they are not certain,
as far as they are certain, they do not refer to reality."-- Einstein




------------------------------

From: "Olivier BREARD" <[EMAIL PROTECTED]>
Subject: Re: How to pronounce Vigenere
Date: Tue, 23 Jan 2001 13:28:03 +0100

Sorry, my newsreader was not properly configured, so my name did not appear
in my previous message ;=)
Anyway, be sure a french would pronounce Vigen�re the way you wrote it
before.... ;=)


* a �crit dans le message <94jt44$pvs$[EMAIL PROTECTED]>...
>YOU ARE RIGHT, that's the way it should be pronounced....
>
>
>
>
>Bryan Mongeau a �crit dans le message ...
>Isn't the word of French origin?
>In that case it would be pronounced:
>
>"vee-jhe-nair"
>
>Pronounce "jhe" like the french say "I" ("je").
>
>--
><==================================>
>Bryan Mongeau
>Lead Developer, Director
>eEvolved Real-Time Technologies Inc.
>www.eevolved.com
><==================================>
>
>"As far as the laws of mathematics refer to reality, they are not certain,
>as far as they are certain, they do not refer to reality."-- Einstein
>
>
>



------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Tue, 23 Jan 2001 12:27:59 GMT

On Tue, 23 Jan 2001 04:24:27 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:

>I frankly have no idea what (A / B)! could possibly be intended to
>represent.  Perhaps the equation should have been (A/B)**S, where S is
>the number of blocks, the length of a sequence of permutations.  

Well, since you criticized DES because it doesn't provide all (2^64)!
possible mappings of 64-bit blocks to 64-bit blocks, whereas you claim
that Dynamic Transposition is, in a sense, complete because it
provides all n! transpositions of an n-bit block, I am trying to point
out that you're comparing apples and oranges.

For both one transposition such as used in Dynamic Transposition, and
two rounds of DES, we get:

number of possible blocks < number of mappings provided by cipher <
number of mappings of the set of blocks to itself

For two rounds of DES, that is:

2^64 < 2^96 < (2^64)!

For arbitrary bit transposition applied to an n-bit balanced block, we
get

n!/((n/2)!(n/2)!) < n! < (n!/((n/2)!(n/2)!))!

Now, you might react and say that I'm unfairly criticizing Dynamic
Transposition because it is a _transposition_, but I think it should
be clear that I am looking at this at the right level of description:
the cipher is ultimately a mapping from the set of input blocks to the
set of output blocks. And transposition of bits is one kind of
restricted mapping between those two sets, just as XOR is another
restricted mapping, and substitution on small sub-blocks is a
restricted mapping.

John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Tue, 23 Jan 2001 12:36:33 GMT

On Tue, 23 Jan 2001 04:24:27 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:

>I'm sorry, but even if you were right "_here_," you would still not be
>right about the bandwidth "problem," and you have been trumpeting that
>for a sequence of responses.  

You are correct that a 2.5% bandwidth cost isn't exactly a crushing
burden of expense.

The reason I say it's a problem has more to do with current fashions
in cryptography; it has to do with the same reason that block ciphers
are so popular instead of stream ciphers, especially stream ciphers
with autokey properties (such as your Dynamic Transposition).

Essentially, without a _compelling_ reason, people are unwilling to
make any sacrifice of convenience for encryption, and so they insist
on properties like good error recovery, and zero expansion of the
plaintext (although they allow a fixed, _initial_, overhead, but I
fear only because they have been told that that is *essential* to
avoid the recognition of identical messages).

I regret that I have failed to make that sufficiently clear.

John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm

------------------------------

From: [EMAIL PROTECTED] (John Bailey)
Subject: steganography by random phase carrier convolution
Date: Tue, 23 Jan 2001 12:40:03 GMT

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 algorithm�s benchmark
results using Stirmark are presented.
Full text at:
http://www.kodak.com/US/plugins/acrobat/en/corp/researchDevelopment/dataEmbedding.pdf

John

John

------------------------------

Date: Tue, 23 Jan 2001 23:47:25 +1100
From: Chris <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss,alt.binaries.cracks
Subject: Re: RE-X-POST Quick-and-Dirty demonstration of twarting US6006328



Kasper Pedersen wrote:

> "Thomas J. Boschloo" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> > You do know 386 code and you have nice debuggers, don't you? I always
> > thought very highly of you with you PGP Disk patches, chosen keyID
> > utilities and things like that. Maybe you could rip the 386 MS-DOS code
> > of Screen Thief <http://www.villa.nildram.co.uk/download.htm>. It
> > somehow redirects IRQ 1 (the keyboard interrupt signal line) to another
> > interrupt and makes it call the interrupt 9 Chris traps in his code (by
> > peeking into the interrupt table at offset 0:24 length 4). Chris would
> > be too stupid to notice the difference and he has no knowledge on how to
> > twart this. This would be the ultimate keylogger that *works under DOS*.
> >
> Off topic to s.c, but..
>
> The way to redirect irq0..7 is to reprogram the first PIC to another
> position (PIC1 is default at 08h), say 78h. Then you can perform snooping no
> matter what. Also, ICW2 is readonly, so it's hard to detect. I used it in a
> game trainer circa 1989.
>
> /Kasper

Don't you have to enable the interrupts for that?
How's re-directing the PIC going to work for polled hardware IO?


------------------------------

From: Joachim Scholz <[EMAIL PROTECTED]>
Subject: Any cryptoanalysis available for 'polymorphic ciphers'?
Date: 23 Jan 2001 13:52:55 +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?

Kind regards
  Joachim Scholz

------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: 3G crypto algorithms
Date: Tue, 23 Jan 2001 14:06:25 +0100



Arturo wrote:
> 
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> 
> >Why is there such a funny restriction? Do they desire the
> >docs be known to the public or not?
 
>         No idea.  I think they want to make it easier for themselves while
> keeping it out of the public.  If so, I hope their algorithms are better than
> their registration controls!
> 
>         BTW: want to see the european version of Carnivore?  Get into ETSI and
> check the "lawful interception" section.  Enfopol come true.

Carnivore and akins can be no surprise to the people in 
Europe at all. In a town not too far from mine there is an 
Echelon station. It is possible in Germany for a government 
agency to lawfully but secretly install a microphone in 
one's home. Right now there is a little revision of the law 
underway to make the recording of telephone conversations 
an even more convenient task. These are in our terminology 
passive attacks. I have the firm impression, though, that 
there are also diverse forms of active attacks, some maybe 
quite clever, others are only semi-clever.

M. K. Shen
=========================
http://home.t-online.de/home/mok-kong.shen

------------------------------

Date: Wed, 24 Jan 2001 00:16:58 +1100
From: Chris <[EMAIL PROTECTED]>
Subject: Re: collisions risks of applying MD5 or SHA1 to a 48-bit input

collision preventing:
 store the same 48 bits over-and-over to pad out one full MD5 or SHA "word"

Offline hash table:
  maybe you should be encrypting your 48-bit values together with some salt using RSA
instead?

Would generating a public/private keypair, then discarding the private key, be a useful
"hash" function?  (given your 48bits are "random numbers" to start with)  RSA's 
slowness
might help prevent offline table generation then.?

JL wrote:

> Hi all,
>
> I would appreciate help in the following matter: we need to differentiate
> some entities based on a 48-bit value but are not very happy with storing
> the
> value itself. Would MD5 or SHA1 be recommended given the input is so short?
> I have strong doubts (including the possibilities of calculating the hash
> table offline for all 2^48 values) but thought of bouncing the idea with
> better informed people. The hash would not be used for authentication
> purposes (or at least not alone).
>
> Thanks.


------------------------------

Date: Wed, 24 Jan 2001 00:22:01 +1100
From: Chris <[EMAIL PROTECTED]>
Subject: Re: Intel assembler code for DES?

I wrote some years ago.

It's a tiny implimentation, but I missed some algorithmic improvements
so it's not really very fast.

It's 8088 (not protected mode).

What did you want it for?

It's quite easy to extract the assembly from a compiled C program and
turn it into working MASM code too - if you wanted to get protected
mode DES or any other algorithms that is.

"N. Weicher" wrote:

> Anyone know of any good Intel assembler (masm) code for DES?
>
> Thanks.


------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Any cryptoanalysis available for 'polymorphic ciphers'?
Date: Tue, 23 Jan 2001 14:35:08 +0100



Joachim Scholz wrote:
> 
> 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?

I tried to download the pdf file (English version) several
times but the process seemed to stuck each time.

M. K. Shen

------------------------------

From: CoyoteRed <[EMAIL PROTECTED]>
Subject: Re: Easy question for you guys...
Reply-To: This NewsGroup unless otherwise directed!
Date: Tue, 23 Jan 2001 13:38:23 GMT

Wow, You guys have been great.

Ha! Simple for you guys, way over my head for me! But I think I got
some pretty good ideas.

Thank you very much!

To answer some of the queries back (to the best of what I remember):

- No, it is not a class assignment. I'm not in school.

- I didn't what to use tables or other lookups. I THOUGHT is might be
earier to us a simple (!) expression to do this.

- I know about the dynamic IP's. This is really to prevent (or deter)
posters from making a post and then replying to the same post to make
it seem that others are agreeing. This is an anonymous (fairly) board,
no log-ons, passwords and such. Posters bounce around using different
names and such. There is a sister board that requires users names and
passwords and is otherwise identical--it is dead compared to the
free-for-all--1:20-30 post ratio. So you see why I don't want it to go
with passwords, the option is already there on the other board.

- More about the dynamic IP's. This is really to identify who posters
ARE, not who they are NOT. So, if you see a poster going by the Handle
"Joe" and has a number of say "A46F" and then another "Joe" has a
number "418C" then you know it's not the same "Joe"

- About hacking a computer with an IP reversed from the posted number.
This is really a peice-of-mind thing than real and true security. It's
just a bulletin board and I have a lot of posters who are newbies and
have gotten spooked by someone saying they can hack their computer
with the IP. So, I'm thinking post a number derived FROM the IP, not
the IP itself to satisfy them.

Anyway, thanks for the imput, you have been VERY helpful. If you
anymire suggestions, feel free!

Thanks, again.

CR

------------------------------


** 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
******************************

Reply via email to