Cryptography-Digest Digest #337, Volume #12 Wed, 2 Aug 00 10:13:01 EDT
Contents:
Re: Secure key-based steganography (Mok-Kong Shen)
IV for arfour ("Andreas Sewe")
Software package locking ("Harris Georgiou")
Re: IV for arfour (Runu Knips)
Re: Software package locking ("Ian Dichkovsky")
Re: IV for arfour ("Andreas Sewe")
Re: Has RSADSI Lost their mind? (Sander Vesik)
Re: Small hash checksum ("Ilya O. Levin")
Re: Elliptic Curves encryption (Sander Vesik)
Re: Blowfish Implementation (Mark Wooding)
Re: I did do it PROTOCOL: (jkauffman)
Re: Sending Messages in Morse Code (John Savard)
Re: unbreakable code? Yes (Sundial Services)
Software in market(ECDSA) ("Sergio Arrojo")
Re: MD5 algorithym as a VBA module ([EMAIL PROTECTED])
Re: Blowfish Implementation (Daniel Leonard)
Re: Hash function? (tweaked) (Francois Grieu)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Secure key-based steganography
Date: Wed, 02 Aug 2000 12:29:06 +0200
Toby Sharp wrote:
> Alice uses an image (say 8-bit gray-scale) to mask the covert message. The
> image has P pixels, where P >> N, say P > 8N. The pseudo-random sequence
> generator begins generating numbers which will correspond to available pixel
> indices. This sequence defines the ordering in which pixels will be visited.
> At each visited pixel, the least significant bit of image data is replaced
> by the next covert message bit until all data bits have been encoded. The
> remaining pixels continue to be visited, encoding dummy data bits whose
> noise statistics are aligned with the covert message bits to ensure uniform
> noise distribution. The image is not visibly altered, since the human eye
> cannot differentiate between as many as 128 shades of grey.
This is in principle analogous to a scheme I described quite a time
back. One takes a file of numerical data, say from physical measurements,
which are real numbers. One pseudo-randomly picks m such numbers
and use their last digit position to transmit m digits of the ciphertext.
The file may be stuffs of public interest and downloaded by many from
Alice's site but only Bob knows that it contains secret information for
him.
M. K. Shen
=============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Andreas Sewe" <[EMAIL PROTECTED]>
Subject: IV for arfour
Date: Wed, 2 Aug 2000 12:21:50 +0200
Well, any stream-cipher needs an IV, and in most cases it is altogether
sufficant to XOR the key K with the IV to get the session-key K_s.
But now, arcfour doesn't use a simple n-bit value as key K, but a
permutation of 256 elements. Of course, this permutation, the internal key
K_i, is generated - in Rivest's implementation - out of a 2048 bit, i.e. 256
bytes; the external key K_e. So you can simply xor an 2048 bit IV with the
external key, perform Rivest's algorithm of generating the internal key, and
you get an internal key modified by the IV.
But, the ugly is, this method relies heavily on the algorthim for generating
internal keys.
Now suppose I get my permutations toying with 256 coloured marbles, getting
real random ones. But now, I can't use the XOR method described above to get
my session key out of two permutations, generated by the "marble method". So
I have to link two permutations, key K and IV, to get a third permutation -
the session key K_s.
/* in C it can be done by the following code */
typedef char permutation[256];
permutation k, k_s, iv;
int n;
for(n = 0; n < 256; n++)
k_s[n] = k[iv[n]];
Are there any fundamental weaknesses, perhaps a chosen-key-attack?
Andreas Sewe
PS: Well, for those paranoid one, who fear one session key might be found
by an attacker, the above method is not one-way. Knowing K_s and IV, your
attacker gets key K (and all your other session key, using this one).
------------------------------
From: "Harris Georgiou" <[EMAIL PROTECTED]>
Subject: Software package locking
Date: Wed, 2 Aug 2000 13:52:12 +0300
Hello all,
I have designed a security scheme to for locking non-public domain software
packages, like expensive commercial packages do with hasp devices, but in
software level. The basic idea is to use steganographic techniques and bind
a specific product & it's serial number to each client. The access control
(keys) are machine-dependant, time-variant and installation-specific. In
regular time intervals, the client should contact the publisher and update
it's key.
However, I cannot find a good way to produce a satisfying key from
machine-dependant attributes. I have tried CMOS, HD partition table, etc,
but usable keys seem to be very short in length, since most PCs share common
characteristics.
Any thoughts?
--
_________________
______/ Harris Georgiou \______
Informatics Systems Analyst
mailto:[EMAIL PROTECTED]
------------------------------
Date: Wed, 02 Aug 2000 13:17:55 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: IV for arfour
Andreas Sewe wrote:
> Well, any stream-cipher needs an IV, and in most cases it is altogether
> sufficant to XOR the key K with the IV to get the session-key K_s.
Why that ??? I would concatenate the IV with the key ? Arcfour can
handle plenty of key bits. XOR'ing the key with the IV reduces the
space of possible keys drastically.
------------------------------
From: "Ian Dichkovsky" <[EMAIL PROTECTED]>
Subject: Re: Software package locking
Date: Wed, 2 Aug 2000 14:50:06 -0700
"Harris Georgiou" <[EMAIL PROTECTED]> wrote in message
news:8m8v6a$1grv$[EMAIL PROTECTED]...
> software level. The basic idea is to use steganographic techniques and
bind
> a specific product & it's serial number to each client. The access control
> (keys) are machine-dependant, time-variant and installation-specific. In
Forget it!
Crackers and hackers anyway break this protection.
Even if someone would purchase new serial number, he(she) could
simple upload to the warez sites.
------------------------------
From: "Andreas Sewe" <[EMAIL PROTECTED]>
Subject: Re: IV for arfour
Date: Wed, 2 Aug 2000 13:59:57 +0200
"Runu Knips" wrote:
> Andreas Sewe wrote:
> > Well, any stream-cipher needs an IV, and in most cases it is altogether
> > sufficant to XOR the key K with the IV to get the session-key K_s.
> Why that ??? I would concatenate the IV with the key ? Arcfour can
> handle plenty of key bits. XOR'ing the key with the IV reduces the
> space of possible keys drastically.
Well, concatenating works fine, when you don't use the whole keyspace - and
standard 128bit arcfour is miles away from generating 256! different
permutations.
But this one also relies on Rivest's key generation algorithm:
k_s = arcfour_key(k + iv); // where addition is concatenating
If someone has the possibility to generate real random permutations, why
force this person to a downgrade. He is able to use the whole keyspace, and
not only 2^128 maximum or, using an 128 bit iv, 2^256 bits max. This was the
original intent of my posting "IV for arcfour".
The full 256 elements permutation works as some kind of interface, and while
an key K generated out of a passphrase using the Rivest algorithm is
altogether ok and easy to reproduce, there is no reason for not using an IV
which uses the full keyspace of 256!. The way it was created is of no
interest, if it was a random one, because it does not have to be
reproduceable; the iv is plainly transmitted with the ciphertext.
k_s = (arcfour_key(k))[iv] // where [] represents the for()-statement,
which uses IV to mix up the arcfour_key
I hope, this explanation is quite clear, if the original posting lacks that
aspect.
Andreas Sewe
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Subject: Re: Has RSADSI Lost their mind?
Date: 2 Aug 2000 12:11:53 GMT
Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Sander Vesik <[EMAIL PROTECTED]> wrote:
> <snip>
>>
>> But of course, there is the whole matter of what is better. If a set
> of
>> the finalists (any number between 2 and 5) can be shown to be equally
>> strong in the face of all known attacks, then surely the one selected
>> must be selected based upon other criteria than security?
> It currently *appears* as if one very strong non-crypto criterion
> is speed and memory requirements on very small devices. This
> currently seems to be a major concern.
FWIW: IMHO NIST should have (had) a separate contest for these. They have
been caught in the trap of wanting to impose a uniform 'one size fits all'
crypto standard on everybody. I don'tthink any of those has ever succeeded
in the long run.
> --
> Bob Silverman
> "You can lead a horse's ass to knowledge, but you can't make him think"
--
Sander
FLW: "I can banish that demon"
------------------------------
From: "Ilya O. Levin" <[EMAIL PROTECTED]>
Subject: Re: Small hash checksum
Date: Wed, 2 Aug 2000 18:02:43 +0600
> From: "Mack" <[EMAIL PROTECTED]>
>>I will use it for a fast check, and the larger checksum I will use in
>>cases of doubt.
>
> Just use a 32 bit CRC they have the requirements you need.
> Table driven implementations are very fast.
Definitely, it'll faster then take a piece of a big hash. In addition to
avoid a CRC32 weakness you may use it in combination with other simple
32-bit hash such as elf, calculate in a same loop. I'm using such technique
in the XUM32 project and it works reliable and fast enough.
Sincerely,
Ilya O. Levin
http://www.code.f2s.com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: 2 Aug 2000 12:20:21 GMT
Terry Ritter <[EMAIL PROTECTED]> wrote:
> On Sat, 29 Jul 2000 13:08:49 -0600, in
> <[EMAIL PROTECTED]>, in sci.crypt Jerry
> Coffin <[EMAIL PROTECTED]> wrote:
>>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>>
>>[ ... ]
>>
>>> >OTOH, in most cases we can at least do the proof-like thing
>>> >of classifying things into what we have to assume, and what we can
>>> >prove based on those assumptions. Better yet, it comes as little
>>> >suprise when one of those assumptions IS proven.
>>>
>>> It probably comes as a nice surprise to the guy who does it, and the
>>> result is a nasty surprise to a user who loses information, but you
>>> will get no surprise at all until the guy decides to tell you, and
>>> that will never happen.
>>
>>That's highly doubtful -- most of the assumptions I'm talking about
>>are NOT things that are likely to be found first by a cryptanalyst.
>>Most proofs about rings, fields, etc., are found by mathematicians
>>and openly published.
> Alas, "most proofs . . . are openly published" is an assertion beyond
> your possible knowledge. We don't know what is done in secret, so we
> can't make a comparison.
> That is the same sort of logic error as asserting that PK is strong
> absent a true proof of strength: we can't know, and we can't just
> assume what others have or have not done in secret.
> NSA is one of the world's largest employers of mathematicians. If
> math really is generated by university professors who publish, why
> *does* NSA employ all those mathematicians? And do we see an amount
> of open publication consistent with that amount of work?
Just a guess - to work on speech recognition, AI, and SIGINT. Also,
as they (iirc) do the orange book, etc. certifications, a lot of
the mathematicians also have to be working on systems research,
automatic proofs (see part on 'beyond A1' in orange book), etc.
It's IMHO a fallacy to think that a significant part - or even
most - ofteh mathematicians employed by NSA have anything to do
with cryptography.
> ---
> Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
> Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
--
Sander
FLW: "I can banish that demon"
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Blowfish Implementation
Date: 2 Aug 2000 12:24:40 GMT
Boris Kazak <[EMAIL PROTECTED]> wrote:
> Just for you two short routines, they are self-explanatory.
And wrong.
>
> word32 MakeH1( ByteType *B )
> /*
> Assemble a word32 from the four bytes provided.
> */
> {
> union {
> unsigned long All ;
> ByteType Byte[4] ;
> } RetVal ;
>
> RetVal.Byte[0] = *B++ ;
> RetVal.Byte[1] = *B++ ;
> RetVal.Byte[2] = *B++ ;
> RetVal.Byte[3] = *B ;
> return RetVal.All ;
> }
Hopeless.
* There's no guarantee that an `unsigned long' is 32 bits long. It
might be 64 bits, or 37 bits or...
* There's no guarantee that there's any type which is exactly 8 bits
long. `unsigned char' might be 9 bits, or 16 bits, or...
* There may be padding bits in `unsigned long'. You can't just write
bytes to the middle of it and hope that the right thing comes out
the end.
* As icing on the cake, Blowfish, as usually implemented, is actually
big-endian. On an x86, the above code will, by pure coincidence,
read in a little-endian word.
Please try learning C before posting advice like this.
For working code, consider this:
#include <limits.h>
#if UINT_MAX >= 0xffffffffu
typedef unsigned int uint32;
#else
typedef unsigned long uint32;
#endif
typedef unsigned char octet;
#define MASK8 0xffu
#define MASK32 0xffffffffu
#define U8(x) ((octet)((x) & MASK8))
#define U32(x) ((uint32)((x) & MASK32))
#define GETBYTE(p, o) (((octet *)(p))[o] & MASK8)
#define PUTBYTE(p, o, v) (((octet *)(p))[o] = U8((v)))
#define LOAD32_B(p) \
(((uint32)GETBYTE((p), 0) << 24) | \
((uint32)GETBYTE((p), 1) << 16) | \
((uint32)GETBYTE((p), 2) << 8) | \
((uint32)GETBYTE((p), 3) << 0))
#define LOAD32_L(p) \
(((uint32)GETBYTE((p), 0) << 0) | \
((uint32)GETBYTE((p), 1) << 8) | \
((uint32)GETBYTE((p), 2) << 16) | \
((uint32)GETBYTE((p), 3) << 24))
#define STORE32_B(p, v) \
(PUTBYTE((p), 0, (uint32)(v) >> 24), \
PUTBYTE((p), 1, (uint32)(v) >> 16), \
PUTBYTE((p), 2, (uint32)(v) >> 8), \
PUTBYTE((p), 3, (uint32)(v) >> 0))
#define STORE32_L(p, v) \
(PUTBYTE((p), 0, (uint32)(v) >> 0), \
PUTBYTE((p), 1, (uint32)(v) >> 8), \
PUTBYTE((p), 2, (uint32)(v) >> 16), \
PUTBYTE((p), 3, (uint32)(v) >> 24))
The macros above assume that the implementation can actually think about
octet streams in some way, and that these are represented as arrays of
unsigned char. This isn't true in some embedded systems. Then you just
lose, I'm afraid.
(The code is an extract from `bits.h', part of my mLib library.)
-- [mdw]
------------------------------
From: jkauffman <[EMAIL PROTECTED]>
Subject: Re: I did do it PROTOCOL:
Date: Wed, 02 Aug 2000 05:13:11 -0700
Give the trusted server an RSA key and get it to append a
timestamp to the packet, hash the lot and sign the hash.
* Sent from AltaVista http://www.altavista.com Where you can also find related Web
Pages, Images, Audios, Videos, News, and Shopping. Smart is Beautiful
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.math
Subject: Re: Sending Messages in Morse Code
Date: Wed, 02 Aug 2000 13:15:18 GMT
On Wed, 02 Aug 2000 06:21:11 GMT, I wrote, in part:
>On Tue, 01 Aug 2000 19:10:00 GMT, [EMAIL PROTECTED] (JimD)
>wrote, in part:
>>I'm not qualified to comment on its security.
>Except for that which may be conferred by obscurity, it has none.
Ah, you were talking about Atbash, not my little brainstorm.
John Savard (teneerf <-)
Now Available! The Secret of the Web's Most Overused Style of Frames!
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
Date: Wed, 02 Aug 2000 06:25:01 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: unbreakable code? Yes
Not to mention that CDs can become scratched and not every byte that is
written to one will always be read back perfectly. (CD players
compensate for this by skipping tracks.) And heaven help me if I lose
one because I'll never decode.
>Joseph Ashwood wrote:
>
> Except that you still have that same issue of getting the CD
> to the other person securely. You can't tell if I've
> hijacked your Post, read the CD, and dropped it back in the
> post. If you plan on delivering it in person, why don't you
> deliver your information in person too? Not to say that you
> can't make a go of it, after all M$ has produced _much_
> worse and people keep buying it at insane rates.
> Joe
------------------------------
From: "Sergio Arrojo" <[EMAIL PROTECTED]>
Subject: Software in market(ECDSA)
Date: Wed, 2 Aug 2000 15:13:13 +0200
Reply-To: "Sergio Arrojo" <[EMAIL PROTECTED]>
I would like to look what kind of software is for sale in order to implement
ECC with ECDSA.
Sergio Arrojo
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: MD5 algorithym as a VBA module
Date: Wed, 02 Aug 2000 13:34:24 GMT
Hi Aequi,
have a look at http://homepages.ihug.com.au/~bakharev/ebcrypt/.
I think you will find that this will solve your problem.
Kind regards,
bs
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi All
>
> I have the C source (or is it an example) of MD5. I also have the
> RFC1321, which explains the methodology/steps and I have a java
> source/example from a web site.
>
> http://bbs.cruzio.com/~schlafly/md5.htm
>
> http://www.w3.org/Library/src/HTDigest.html
>
> ftp://ftp.nue.et-inf.uni-siegen.de/pub/SECURITY/rfc/rfc1321.txt
>
> I'm know next to nothing about encryption <g> .. but all I want to
> know is .. has someone got this same source in VBA ? I'm not lazy, and
> given some time can code one up, its just that I'm in a bit of a hurry
> and would hate to "re-invent" the wheel (vba) when its already been
> done.
>
> Thankies
> Aequi
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Daniel Leonard <[EMAIL PROTECTED]>
Subject: Re: Blowfish Implementation
Date: Wed, 02 Aug 2000 13:42:53 GMT
> > > > Just tell the computer that it's a pointer to a different type, in =
this case
> > > > long instead of char.
> > >
> > > Ah, gee. Are you seriously intending to promulgate this practice
> > > to programmers who plainly don't know any better? Or is this a
> > > joke, and my sense of humor has malfunctioned? Not every computer
> > > is an Intel x86.
> >=20
> > That is why he said as introduction (not exact quote) :
> >=20
> > if you do not worry about endianness
>=20
> It is NOT the endianess that is the problem, it is the alignment. You
> get
> SIGBUS signals if you try to read unaligned integer data on other
> machines than the x86 (or some other old CISC machine such as the m68k).
> Many systems catch SIGBUS by themself (such as OSF1), but they print
> ugly warnings on the console and its of course very inefficient.
>=20
> Too, if you cast to long, you get a pointer to 64 bit numbers on modern
> 64 architectures (such as the alpha processor). So better use some
> typedef for 32 bit types.
That why most of my programming is done in Java, no pointer or aligment
problems, and all the data types have a predetermined length.
On the other hand, having tough programming courses, it was clear that the
original poster did not know about the bit shifting operators (<< >> | &
^ ~). While some tried to help him with these, other brought out the big
gun (aka pointer cast), which degenerated in this thread.
I was somehow playing the role of the devil advocate, it can lead often to
interresting discussion, never taking anything for granted. Well,
sometimes succeed, sometimes I don't.
==========
Daniel L=E9onard
OGMP Informatics Division E-Mail: [EMAIL PROTECTED]
D=E9partement de Biochimie Tel : (514) 343-6111 ext 5149
Universit=E9 de Montr=E9al Fax : (514) 343-2210
Montr=E9al, Quebec Office: Pavillon Principal G-312
Canada H3C 3J7 WWW :
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Hash function? (tweaked)
Date: Wed, 02 Aug 2000 16:04:10 +0200
More thoughts on Boris Kazak's hash function Karagash (2000-07-29)
A basic fact is that all bytes of the hash except the leftmost 3 ones
can never reach some 123 values out of 256, for example are never in the
range [0x80..0xCC], for the value of SEED=0xB7E1 given.
This is a consequence of how the rightmost bytes of the hash are
constructed at each round, that is as
(((multiplicand*SEED)>>16)^multiplicand)>>8
for some 16 bit value of multiplicand: this function only takes 133
distinct values when multiplicand varies in [0..65535]
So at the very least, the hash is very far from evenly spread. Still,
finding collisions is an interestingly non trivial problem.
Francois Grieu
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
