Cryptography-Digest Digest #17, Volume #14 Mon, 26 Mar 01 19:13:02 EST
Contents:
Re: RC4 ("Ryan M. McConahy")
Re: Data dependent arcfour via sbox feedback ("Henrick Hellström")
Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged (Dave
Howe)
Re: New stream cipher ("John L. Allen")
Re: New stream cipher ("Paul Pires")
Re: Please read. (Tony L. Svanstrom)
Re: 64 versus 128 (or bigger) bits cipher data block ("Joseph Ashwood")
Re: compression ratio as a predicter of cipher strength ("Joseph Ashwood")
Re: Data dependent arcfour via sbox feedback (Mok-Kong Shen)
Re: Large numbers in C ( 512 bits or more) (Bob Harris)
Re: Potential of machine translation techniques? ("Douglas A. Gwyn")
Re: Large numbers in C (512 bits or more) ("Douglas A. Gwyn")
Re: TEA, Blowfish with non-random data? ("Douglas A. Gwyn")
Re: Idea - (LONG) ("Douglas A. Gwyn")
Re: Uniform random integer (Benjamin Goldberg)
Re: Fractal Compression ("Joseph Ashwood")
Re: Large numbers in C (512 bits or more) ("Joseph Ashwood")
Re: ECDSA question ("Joseph Ashwood")
----------------------------------------------------------------------------
From: "Ryan M. McConahy" <[EMAIL PROTECTED]>
Subject: Re: RC4
Date: Mon, 26 Mar 2001 17:14:09 -0500
Oh. Ok. Thanks. I thought it was a block cipher. Does anyone know of where I
could find the VB source for AES-256?
Paul Pires wrote in message ...
>Ryan M. McConahy <[EMAIL PROTECTED]> wrote in message
news:3abf98aa$0$88182$[EMAIL PROTECTED]...
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Ok, I'm assuming RC4 is 128bit.
>
>128 bit what?
>RC4 is a stream cipher with a 2048 bit internal state.
>
>>
>> So, lets say I tell the user to give me a 16byte key. If they don't,
> > I just ignore it. I split the key in half, generating K1 and K2. I
>> hash these to get HK1 and HK2. I encrypt the plaintext with HK1, then
>> re-encrypt that with HK2. Would this be 256 bit encryption? Would it
>> be strong? Could I call it 2RC4?
>
>Let's say we did and then don't. You have to covey this special process
>to the recipient or provide it in the code. If it is kept secret, it is
security
>through obscurity. If it is known, it adds nothing. An attacker knowing the
>process just pushes the 16 byte guesses through this front end. 16*8=128.
>No, it's not the same as 256 bit encryption. The only "surprise" an
attacker
>has to overcome is 128 bits worth...IF ALL ELSE IS DONE WELL.
>
>Designing the proper process to key
>a cipher could be seen as a more demanding challenge than developing
>a cipher. If your gonna go through all that, why not write a super-strength
>home brew cipher to use with it?.... :-)
>
>Paul
>>
>> I'm making a program to "compete" with ShyFile (www.shyfile.de). I
>> want to prove that I can make a better one. The only advantage theirs
>> has over that little RC4 program I threw together last night is that
>> t's 256 bit and that it can generate self-decrypting HTML pages. My
>> program wouldn't do that, but it could be downloaded in about five
>> seconds.
>>
>> Oh, and if anyone has any AES code that would work in VB4, let me
>> know. :)
>>
>> Thanks in advance,
>>
>> Ryan M. McConahy
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: 6.5.8ckt http://www.ipgpp.com/
>> Comment: KeyID: 0xA167F326A5BE3536
>> Comment: Fingerprint: 838C 815E 5147 2168 5A76 16F1 A167 F326 A5BE 3536
>>
>> iQA/AwUBOr+Y/KFn8yalvjU2EQJahgCgnmiGbErKKJRN3lxl6lLVOCDUegUAniSy
>> CD7awgu9R8P8yQw9Ba5rFNLb
>> =MjSR
>> -----END PGP SIGNATURE-----
>>
>>
>>
>
>
>
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Data dependent arcfour via sbox feedback
Date: Tue, 27 Mar 2001 00:24:56 +0200
"Mok-Kong Shen" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
>
>
> Lassi Hippeläinen wrote:
> >
>
> > But please remember that patents are relevant only in the commercial
> > field. A cryptographer doing research can (and should) use them as
> > sources of ideas. Things get rough only when you start talking about
> > money. Even then you can negotiate a licence. Using a patent to prevent
> > fair competition is illegal in many countries - even in the U.S., IIRC.
>
> Are you sure of that? From some stuffs about genomes I
> read in newspaper, I got the impression that researches
> in molecular biology would be hampered, if these involve
> patented materials. Or putting the question in another
> field, could a research institution self-build and use a
> piece of patented machine purely for research without
> any monetary exploitation?
I believe Lassi Hippeläinen is right, at least in part: If you want to
protect your knowledge you can always do so by keeping it secret. A patent
is an option for those who do want to protect their knowledge, but publish
it anyway. However, if you have an option to either (a) do research that
will result in a product you must pay a third party to be allowed to
exploit, or (b) do research that will result in a product you will be the
sole owner of, then (b) is clearly a more lucrative option, all other things
equal.
> M. K. Shen
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: Dave Howe <[EMAIL PROTECTED]>
Crossposted-To:
alt.privacy.anon-server,alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.resources,comp.security.pgp.tech
Subject: Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged
Date: Mon, 26 Mar 2001 23:32:08 +0100
In our last episode (<alt.security.pgp>[Mon, 26 Mar 2001 19:16:25
GMT]), "Roger Schlafly" <[EMAIL PROTECTED]> said :
>If the attack has access to my private machine to do all that,
>wouldn't it be easier for him to patch my PGP.exe in some way
>to make it insecure?
yes.
however, it is possible to imagine situations where he would have
access to the key and not the machine.
Assume (for example) you follow recommended best practice and keep
your keyrings on a write-protected floppy disk physically separated
from the machine when not in use
Now assume that the attacker for some reason has access to the
location you store your key floppy (a fire safe maybe?) but not the
hard drive of your machine (bios protection, and tamper-proof cases)
Assuming further that he can gain access to at least one signed
message on a predetermined day, he could modify your floppy, wait for
the following evening, then modify it back. Particularly for Usenet
posts, few signatures are actually verified, so the odds of any
particular signed post you made being reported back to you as having a
bad .sig are low - and you would probably just blame a usenet server
for mangling the post enroute.
ok, it's a reach - but it is a possible scenario.
--== DaveHowe ( is at) Bigfoot dot com ==--
------------------------------
From: "John L. Allen" <[EMAIL PROTECTED]>
Subject: Re: New stream cipher
Date: Mon, 26 Mar 2001 22:36:05 GMT
Paul Rubin wrote:
> [EMAIL PROTECTED] (Gregory G Rose) writes:
> > There are 6 relatively new stream ciphers in the NESSIE project
> > http://www.nessiecrypt.org/ . Try them.
>
> I think you mean www.cryptonessie.org. But I don't immediately see
> the stream ciphers there.
They're under the "accepted submissions" link:
https://www.cosic.esat.kuleuven.ac.be/nessie/workshop/submissions.html
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: New stream cipher
Date: Mon, 26 Mar 2001 14:40:06 -0800
Frank Gerlach <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Paul Pires wrote:
>
> > Frank Gerlach <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
> > > MarinaP wrote:
> > > >
> > > > Hi, all!
> > > > I would like to analyze a new stream cipher.
> > > > Where can I find it?
> > > > Where can I find RC4-like ciphers?
> > > > What stream ciphers are used in practice? -RC4, A5, PKZIP ( It is clear.)
> > > > Thank you.
> > > try google.com
> > >
> > > A5 and PKZIP are erm, not "military-strenght" :-)
> >
> > Your probably not going to take this well but.....
> >
> > "military-strenght" or "military-strength" are meaningless terms.
> > If you don't know the answer, wait for someone else to answer
> > instead of posting less than helpful or non-responsive replies.
> >
> > Paul
>
> I didn't want to call it CRAP from my employer's account.
Read this real slow. That is less than helpful and un-resposive.
The O.P didn't ask for what is thought of them.
See the responses of Greg Rose and Paul Rubin for an
alternative.
Paul
>
>
------------------------------
Subject: Re: Please read.
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Mon, 26 Mar 2001 22:54:27 GMT
Paul Pires <[EMAIL PROTECTED]> wrote:
> Use a killfile. And do NOT reply or comment.
> You are just pushing these headers past the killfiles
> of those who are using them and giving this turd
> a certain amount of satisfaction.
Then they need to change their killfiles to catch the fups too.
/Tony
--
########################################################################
I'm sorry, I'm sorry; actually, what I said was:
HOW WOULD YOU LIKE TO SUCK MY BALLS?
- South Park -
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: 64 versus 128 (or bigger) bits cipher data block
Date: Mon, 26 Mar 2001 14:41:41 -0800
It's fairly simple. Because encryption is based on permutations, a 64-bit
block cipher can only reach 2^64! permutations, once you eliminate the few
off permutations (those permutations that exist where if you swap K elements
you reach the others, for small K, these are generally related keys) you
reduce the space to very much smaller, while it's still a large enough
space, it's getting a bit cramped versus the state of computing power. With
a 128-bit cipher you start with 2^128! before eliminatng the few-off
entries, this gives us much more room to make the search harder. To see the
effect that this has scale it down completely, to the point where you have
1-bit encryption, and you can very easily see that there is simply no way to
make a secure cipher that small (without going into interesting chaining
modes).
Joe
"Peter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Someone can explain me main reasons (or all) for which 128 bits block
> is better than 64 bits block?. I had made think on this and I found
> some goals for use bigger block but I still dont know if they are
> primary.
>
> Best regards
>
> Peter
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: compression ratio as a predicter of cipher strength
Date: Mon, 26 Mar 2001 15:07:23 -0800
It's far more complex than that, but to make a long post very short
(continued below), no compressibility is not an accurate description of
cipher strength.
What does measure the strength of a cipher is the difficulty in finding a
compression algorithm that will compress it, under given data. So if you can
prove that the file cannot be compressed, you have proven the encryption to
be strong, and vice versa. However this is excessively difficult. The reason
for this is that is I take the deceptively simple:
3DES_Encrypt(Data, random key)
it will not compress realistically with an accessible compression algorithm.
However by doing 2^90 work I can break the 3DES encryption, place the key
before the Data, and compress normally. However right now finding this
compressor takes 2^90 work. Alternately after 2^64 blocks have been fed
through the compressor, language techniques can be applied to the data and
it will compress. It's a very twisted way of viewing attacks on an
encryption algorithm.
What the Snake Oil page should use the logic of "If it is strong encryption
it will not compress", instead what I assume they used of "If it doesn't
compress it's strong encryption" in English these sound very similar, in
math they are entirely different. There are numerous subtleties involved,
but if someone is reduced to using how much something doesn't/does compress
to justify strength step away from the software slowly so as not to alarm
the natives.
Joe
"Curtis Williams" <[EMAIL PROTECTED]> wrote in message
news:l0rv6.10793$[EMAIL PROTECTED]...
> Hi,
>
> An encryption product claims that a ciphertext file should be compressed
> and the compression ration is a predictor of cipher strength (i.e. encrypt
a
> file then zip it. if the compression ratio is 0, the encryption is
strong).
> Is this valid or snakeoil?
>
> Thanks
>
>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Data dependent arcfour via sbox feedback
Date: Tue, 27 Mar 2001 01:20:30 +0200
"Henrick Hellström" wrote:
>
> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote:
> > Lassi Hippeläinen wrote:
> >
> > > But please remember that patents are relevant only in the commercial
> > > field. A cryptographer doing research can (and should) use them as
> > > sources of ideas. Things get rough only when you start talking about
> > > money. Even then you can negotiate a licence. Using a patent to prevent
> > > fair competition is illegal in many countries - even in the U.S., IIRC.
> >
> > Are you sure of that? From some stuffs about genomes I
> > read in newspaper, I got the impression that researches
> > in molecular biology would be hampered, if these involve
> > patented materials. Or putting the question in another
> > field, could a research institution self-build and use a
> > piece of patented machine purely for research without
> > any monetary exploitation?
>
> I believe Lassi Hippeläinen is right, at least in part: If you want to
> protect your knowledge you can always do so by keeping it secret. A patent
> is an option for those who do want to protect their knowledge, but publish
> it anyway. However, if you have an option to either (a) do research that
> will result in a product you must pay a third party to be allowed to
> exploit, or (b) do research that will result in a product you will be the
> sole owner of, then (b) is clearly a more lucrative option, all other things
> equal.
I understand the post of Hippeläinen to mean that, as
long as one is doing research (e.g. inside one's
university) without making money, i.e. not in competition
with patentholders in the open market, then one could make
use of patents of others freely, e.g. building a machine
involving patents. I vaguely remember that there is
certain exemption of copyright for educational institutions,
i.e. these could freely make substantial amounts of copies
from parts of books for teaching purposes. But I doubt that
analogous applies to patents.
M. K. Shen
------------------------------
From: Bob Harris <[EMAIL PROTECTED]>
Subject: Re: Large numbers in C ( 512 bits or more)
Date: Mon, 26 Mar 2001 18:24:10 -0500
Dobs recently posted this plea:
> I was advised that if I want to use big numbers in C I should use OPENSSL
> BIG NUMBERS library. How should I use this library in my program so I could
> just make the declaration of my variable q( wchich I want to be large) like
> this:
> BIGNUM q;
> Can somebody who has ever used big numbers from OPENSSL could tel me what
> should I do. I found such a structre, but what more should I copy to my
> program?????????????????
>
> typedef struct bignum_st
> {
> BN_ULONG *d; /* Pointer to an array of 'BN_BITS2' bit chunks. */
> int top; /* Index of last used d +1. */
> /* The next are internal book keeping for bn_expand. */
> int dmax; /* Size of the d array. */
> int neg; /* one if the number is negative */
> int flags;
> } BIGNUM;
I haven't seen the package (if you found a free version of it somewhere, it
would help if you posted the URL in your plea), but from the structure
you've shown, I think you might want to declare your variable q like this:
BN_ULONG qdata[???] = { 0 };
BIGNUM q = { qdata, 1, ???, 0, 0 };
Where '???' is some suitable constant that describes the number of chunks,
each of which should contain BN_BITS2 bits, to get the maximum size you
want.
I would think, though, that the package would have some function such has
NewBignum (bits) that would take care of all that sort of thing for you,
allocating the necessary space from the heap.
Hope that helps,
Bob
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Potential of machine translation techniques?
Date: Mon, 26 Mar 2001 23:00:15 GMT
"SCOTT19U.ZIP_GUY" wrote:
> maybe in germany though they would reather get flowers. Or
> does flower ( Blume I guess) have other connotations ...
In many crossword puzzles, a flower of England turns out
to be Avon or Thames.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Large numbers in C (512 bits or more)
Date: Mon, 26 Mar 2001 23:03:13 GMT
Dobs wrote:
> I was advised that if I want to use big numbers in C I should use OPENSSL
> BIG NUMBERS library. How should I use this library in my program so I could
> just make the declaration of my variable q( wchich I want to be large) like
> this:
> BIGNUM q;
> Can somebody who has ever used big numbers from OPENSSL could tel me what
> should I do. I found such a structre, but what more should I copy to my
> program?????????????????
OpenSSL provides on-line documentation (manual pages)
that explain all this. Read them!
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: TEA, Blowfish with non-random data?
Date: Mon, 26 Mar 2001 23:15:25 GMT
Mark G Wolf wrote:
> One often wonders. I'm a newbie myself, but to test how random something is
> you can run various statistical analyses on the output file, if it's
> "really" random it will have a certain distribution for a particular
> analysis.
No, the observed distribution is whatever it is, and the best
that can be done (if you can't inspect the internal operation
of the source that generates the data) is to evaluate how
probable it is that some statistic computed from the observed
data would have at least (or at most, depending) that value
if the source did operate according to the assumed model (of
randomness, in this instance). If you have no a priori
expectation one way or another, then that probability can
rationally be taken as the likelihood that the source operates
according to the model. (But with limited information, that
estimate is not very accurate.) The most common such statistic
is Pearson's chi-square, computed in various ways depending on
just what kind of pattern one suspects might be present.
(There are other statistics that facilitate accumulation of
relevant information, of all kinds, as it becomes available.)
Knuth's TAOCP vol. 2 says quite a lot about this subject.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Idea - (LONG)
Date: Mon, 26 Mar 2001 23:19:05 GMT
Joseph Ashwood wrote:
> ... to have unbreakable security you MUST have a key at least as long
> as the plaintext (I believe it was Shannon that proved this).
Actually Shannon showed something else. A shorter key could suffice
if the source has appreciable redundancy. And that whole approach
doesn't take into account work factor.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Uniform random integer
Date: Mon, 26 Mar 2001 23:44:24 GMT
Frank Gerlach wrote:
>
> NEVER use rand() from the c std lib for security-related purposes. To
> easy to guess the next value from the current. Instead, use DES or RC4
> or any other strong symmetric cipher.
I never said I was, and I apologize if I gave that impression.
I meant for "rand()" to simply be whatever statistically good rng you
happen to have... perhaps I should have used "prng()" instead.
And anyway, that still doesn't answer the question... what are the
proper names of ranmod_a and ranmod_b, if they have any?
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Fractal Compression
Date: Mon, 26 Mar 2001 15:14:12 -0800
[now on encryption]
While the various fractal attempts at encryption haven't proven useful, they
may yet prove to be. Some of the idea is that fractal equations are just
another set of functions that can be used. They may or may not prove useful.
The index into PI methodology is not likely to be of much use, I assume that
the key is an index into Pi that forms the beginning. The reason being
fairly simple. As an attacker I can easily compute PI (since it's a given
that I will know your algorithm, just not your keys). With the ability to
compute Pi, I can keep iterating down until the decryption looks like it's
expected to, so brute force towards the key is very possible. To break a key
more analytically, precompute small stretches of Pi at regular intervals,
this will allow fast checks against data.
If you ever use the same key twice your security completely disappears, at
that point it becomes a Vigenere cipher.
If a single plaintext leaks I have found your range of abilities.
The encryptor and decryptor have do perform linearly less work than the
attacker, this is a very bad thing
etc
Currently these represent some the problems that fractal encryption hasn't
(yet) been able to address.
Joe
"Merrick" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Would someone please provide me with a simple explanation of Fractal
> Compression?
>
> Most of the search results I get are rather difficult to wade through,
> and the simplest I found gave an example of using PI to offset the
> values (eg abcdefg -> a+3 b+1 c+4 d+1 e+5 f+9 g+2 -> dcgejoi), which
> somehow didn't seem quite right to me.
>
> Any takers?
>
> Thanks
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Large numbers in C (512 bits or more)
Date: Mon, 26 Mar 2001 15:34:23 -0800
There are functions to work with the big numbers, with names like:
BN_bin2bn(...)
BN_mod_mul(...)
etc
Many of these can be found on http://www.openssl.org/docs/crypto/bn.html#
where the BIGNUM library is documented.
So to build a basic RSA encryption routine looks like this:
BIGNUM *N;
BIGNUM *e;
BIGNUM *M;
BIGNUM *X;
BN_CTX *ctx;
BN_CTX_init(ctx);
N= BN_new();
e= BN_new();
M = BN_new();
X = BN_new();
BN_bin2bn(N, <insert the representation here>);
BN_bin2bn(e, <insert the represantation here>);
BN_bin2bn(M, <insert the representation if the message here>);
BN_mod_exp(X, M, e, N);
BN_bn2bin(X, <the output variable>);
Of course I've skipped error checking and various other things, but that's
the basics.
Joe
"Dobs" <[EMAIL PROTECTED]> wrote in message news:99nqu8$c5r$[EMAIL PROTECTED]...
> I was advised that if I want to use big numbers in C I should use OPENSSL
> BIG NUMBERS library. How should I use this library in my program so I
could
> just make the declaration of my variable q( wchich I want to be large)
like
> this:
> BIGNUM q;
> Can somebody who has ever used big numbers from OPENSSL could tel me what
> should I do. I found such a structre, but what more should I copy to my
> program?????????????????
>
> typedef struct bignum_st
> {
> BN_ULONG *d; /* Pointer to an array of 'BN_BITS2' bit chunks. */
> int top; /* Index of last used d +1. */
> /* The next are internal book keeping for bn_expand. */
> int dmax; /* Size of the d array. */
> int neg; /* one if the number is negative */
> int flags;
> } BIGNUM;
>
>
>
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: ECDSA question
Date: Mon, 26 Mar 2001 15:38:35 -0800
Actually there is a problem. It is far easier to compute a new message m' =
m mod n, than it is to compute a new message sha-1(k) = sha-1(m) mod n.
The second and the original reason for doing it this way was the need to
reduce the compute time. It takes massively less time to generate the SHA-1
hash of a message than it takes to perform numerous other possiblities. This
isn't a problem with ECDSA because the reduction time will go unnoticed, and
may be faster than hashing. However the security problem may be of great
interest.
Joe
"Cristiano" <[EMAIL PROTECTED]> wrote in message
news:FIMv6.27062$[EMAIL PROTECTED]...
> In Elliptic Curve DSA:
> "[...] Compute s = k^-1 {SHA1(m) + dr} mod n [...]" (m is the message).
> Is there any problem if I use "m" instead of "SHA1(m)" (the signature
> validation works fine)?
>
> Cristiano
>
>
------------------------------
** 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
******************************
