Cryptography-Digest Digest #314, Volume #14 Tue, 8 May 01 11:13:00 EDT
Contents:
Re: A Question Regarding Backdoors (Phil Carmody)
Re: free en/decryption library ("Tom St Denis")
Re: free en/decryption library ("Tom St Denis")
Re: Free Triple DES Source code is needed. (Phil Carmody)
Re: Free Triple DES Source code is needed. ("Tom St Denis")
Re: free en/decryption library (yomgui)
Re: Best encrypting algoritme (Mark Wooding)
Re: Free Triple DES Source code is needed. (Mark Wooding)
A simple encryption algorithm based on OTP ("Siva Prasad Gummadi [T]")
Re: Encryption Algorythm ("Joseph Ashwood")
Re: How much math is required to study this? ("Joseph Ashwood")
Re: linear vs nonlinear ("Joseph Ashwood")
Re: Best, Strongest Algorithm (SCOTT19U.ZIP_GUY)
Re: GF(2^W) sboxes timings (Phil Carmody)
Re: Question about randomness and OTPs (John Myre)
----------------------------------------------------------------------------
From: Phil Carmody <[EMAIL PROTECTED]>
Subject: Re: A Question Regarding Backdoors
Date: Tue, 08 May 2001 10:10:35 GMT
"Trevor L. Jackson, III" wrote:
> Consider the variation suggested by RW: non-backdoored crypto is outlawed.
> Such a draconian restriction would present the choice of crippled crypto or
> jail to anyone promoting (in the vague DCMA sense) non-bacdoored crypto. In
> that situation any professional with integrity should visit jail in the
> tradition of Thoreau, Parks, & Zimmerman.
Quick question -
Can a sensible amount of nested 'crippled crypto' be used to emulate
'strong crypto'?
e.g. one can turn DES into Triple-DES (though DES isn't exactly
crippled).
I'm getting at 'playing' the law - don't use strong crypto, simply
repeatedly use crippled crypto.
And if they outlaw back-to-back crypto start inserting non-crypto stages
between the crypto-stages. It's an unworkable law in any civilised
society (i.e. one where they have courts, lawyers, and appeals, oh and
accountability). There are too many intelligent opponents to such laws
for them to be not 'played' to death. (eventually - let's not forget the
Jens Johansens that get tied up in these issues.)
Phil
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: free en/decryption library
Date: Tue, 08 May 2001 10:14:29 GMT
"Jeffrey Walton" <[EMAIL PROTECTED]> wrote in message
news:3af76780$0$[EMAIL PROTECTED]...
> Thanks Tom. I'll try them (GMP and MPI). Thanks very much.
Righto, personally I like MPI more since it's a simpler library (about three
source files is all that is really needed)... Supposedly GMP is spiffy
because it's GNUized and fast.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: free en/decryption library
Date: Tue, 08 May 2001 10:16:42 GMT
"yomgui" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> free, small, cross platform, safe, simple, fast, open source,
> symmetric stream and file encryption
>
> http://bigfoot.com/~kryptyomic
Link doesn't work. Aren't you that guy that made a homebrew system anyways?
BAAAAAAD
Tom
------------------------------
From: Phil Carmody <[EMAIL PROTECTED]>
Subject: Re: Free Triple DES Source code is needed.
Date: Tue, 08 May 2001 10:16:12 GMT
Tom St Denis wrote:
> I agree they share a common ground language but they are not the same. If
> your program works in C++ it's a C++ program, if it's in C it's a C program.
Show me the programs and code in K&R 2nd Edition that aren't well formed
C++ programs or code.
This is _not_ a forum for language-lawyer discussions, but for
cryptography. I hope to see you on comp.lang.c++.moderated if you have
anything else to say about C++.
Phil
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Free Triple DES Source code is needed.
Date: Tue, 08 May 2001 10:37:40 GMT
"Phil Carmody" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> > I agree they share a common ground language but they are not the same.
If
> > your program works in C++ it's a C++ program, if it's in C it's a C
program.
>
> Show me the programs and code in K&R 2nd Edition that aren't well formed
> C++ programs or code.
>
> This is _not_ a forum for language-lawyer discussions, but for
> cryptography. I hope to see you on comp.lang.c++.moderated if you have
> anything else to say about C++.
I am not a spec guru. but just post "I want a C/C++ compiler" in
comp.lang.c and you will find out how different they really are.
It's a buzzward anyways... Are you a high tech leading edge IT specialists
highly qualified in Linux with C/C++ advanced programming skills? etc...
Meaningless crap.
Tom
------------------------------
From: yomgui <[EMAIL PROTECTED]>
Subject: Re: free en/decryption library
Date: Tue, 08 May 2001 11:57:14 +0100
Reply-To: [EMAIL PROTECTED]
if you can't recognise a xor everything must be homebrew for you anyway
Tom St Denis wrote:
>
> "yomgui" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > free, small, cross platform, safe, simple, fast, open source,
> > symmetric stream and file encryption
> >
> > http://bigfoot.com/~kryptyomic
>
> Link doesn't work. Aren't you that guy that made a homebrew system anyways?
>
> BAAAAAAD
>
> Tom
--
���g��
oim 3d - surface viewer - http://i.am/oim
kryptyomic - encryption scheme - http://bigfoot.com/~kryptyomic
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Best encrypting algoritme
Date: 8 May 2001 11:12:24 GMT
wtshaw <[EMAIL PROTECTED]> wrote:
> When Rijndael is combined with a chaining mode, it is no longer
> Rijndael. To measure the strength of an algorithm means no window
> dressing should be fudged into the process.
But we know how to measure the strength of a chaining mode relative to
the strength of the underlying block cipher. See, for example, `A
Concrete Security Treatment of Symmetric Encryption: Analysis of the DES
Modes of Operation', by Bellare, Desay, Jokipii and Rogaway.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Free Triple DES Source code is needed.
Date: 8 May 2001 11:17:16 GMT
Phil Carmody <[EMAIL PROTECTED]> wrote:
> Show me the programs and code in K&R 2nd Edition that aren't well formed
> C++ programs or code.
There are programs in K&R second ediiton which aren't even strictly
conforming C.
> This is _not_ a forum for language-lawyer discussions, but for
> cryptography. I hope to see you on comp.lang.c++.moderated if you have
> anything else to say about C++.
So being wrong about things outside of the group's specific subject
matter is just fine and perfectly all right and in no way indicative of
sloppy thinking in general. Good-oh.
-- [mdw]
------------------------------
From: "Siva Prasad Gummadi [T]" <[EMAIL PROTECTED]>
Subject: A simple encryption algorithm based on OTP
Date: Tue, 08 May 2001 16:42:08 +0530
==============5661BE482E27754272121720
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
Following is a simple algo. based on OTP which occurred to me just
a while ago.
Let's suppose we have N bits of plain text. Choose some k-bit key.
This is a secret key and thus needs to be transmitted to the other end
securely. Choose an appropriate value for k, in context of brute force
attacks. Now the procedure is to divide the plain text into blocks of
each k-bit length and encrypt (XOR) the first block with the key, second
block with the first block of plain text, and simly., every other block
with
the previous plain text block.
Since this is basically OTP I think it should be a good algorithm.
As per
my observation, these are the issues with the algorithm:
1. Private Key system , thus lacks some attractive properties of a
public
key encryption system
2. Since there are no complex operations involved, you can increase
the key
size as required to make brute force attacks impractical, but you
don't need
such a large key as in case of actual OTP
3. It should be easily broken if the same key is used again, as in case
of OTP.
But can some one explain how exactly an OTP becomes venerable when
a
key is repeated?
Thanks,
Siva
--
************************************************************
Siva Prasad Gummadi
Motorola India Electronics Ltd.
No 33A, Ulsoor Road,
Bangalore - 560042
Phone No: 5598615-4007
email id: [EMAIL PROTECTED]
************************************************************
[x] General Information
[ ] Motorola Internal Use only
[ ] Motorola Confidential Proprietary
************************************************************
==============5661BE482E27754272121720
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<br>
<br>Following is a simple algo. based on OTP which occurred to me
just
<br>a while ago.
<br> Let's suppose we have N bits of plain
text. Choose some k-bit key.
<br>This is a secret key and thus needs to be transmitted to the other
end
<br>securely. Choose an appropriate value for k, in context of brute force
<br>attacks. Now the procedure is to divide the plain text into blocks
of
<br>each k-bit length and encrypt (XOR) the first block with the key, second
<br>block with the first block of plain text, and simly., every other block
with
<br>the previous plain text block.
<p> Since this is basically OTP I think it should be
a good algorithm. As per
<br>my observation, these are the issues with the algorithm:
<p> 1. Private Key system , thus lacks some attractive properties
of a public
<br> key encryption system
<br> 2. Since there are no complex operations involved, you
can increase the key
<br> size as required to make brute force
attacks impractical, but you don't need
<br> such a large key as in case of actual
OTP
<br> 3. It should be easily broken if the same key is used again,
as in case of OTP.
<br> But can some one explain how exactly an OTP
becomes venerable when a
<br> key is repeated?
<p>Thanks,
<br>Siva
<pre>--
************************************************************
Siva Prasad Gummadi
Motorola India Electronics Ltd.
No 33A, Ulsoor Road,
Bangalore - 560042
Phone No: 5598615-4007
email id: [EMAIL PROTECTED]
************************************************************
[x] General Information
[ ] Motorola Internal Use only
[ ] Motorola Confidential Proprietary
************************************************************</pre>
</html>
==============5661BE482E27754272121720==
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Encryption Algorythm
Date: Fri, 4 May 2001 09:14:22 -0700
In a transient sense it is possible to know. In a permanent sense there are
certain extreme cases (One-Time-Pads) that we know to be secure, and we can
prove things about the security of various aspects of a function, other than
that no we cannot. What you can do is prove resistance to differential and
linear cryptanalysis, that is a good beginning. From there you can begin to
prove resistance to boomerang attacks, slide attacks, and a dozen other
types of attack. That will place you only in the position of having to find
a different method of attack, but will not prove the security. There are
also certain indicators tha can tell you that your cipher is bad, for
example encrypting a counter, and checking to see if the output passes
DIEHARD, but this will only tell you if your cipher is bad, it cannot judge
being good. You might also want to prove non-compressability, not just run
it through a zip program, but actually mathematically prove that the output
cannot be compressed with a low entropy input. I wish you luck, the proofs
are generally very difficult unless you've designed your cipher to be
provable.
Joe
"EE" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Is there a way to know if an encryption algorithm is secure? I would also
> like to know how strong this algorithm is.
>
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: How much math is required to study this?
Date: Fri, 4 May 2001 09:17:57 -0700
[sent by e-mail and posted]
It really depends on which area of cryptography you want to go into. Even
more so it depends on you having that something in your brain that does
cryptography. Having the extra mathematical basis will certainly aid you in
this, but it is not all that is required.
Most of the attacks you see on this newsgroup are because someone did
something they should have known not to. It really is up to you. Sounds like
you've got a fair amount of math behind you already, you might consider
getting ahold of a beginning cryptanalysis book (Applied Cryptography will
work as a basic introduction) so you can learn the basic types of attacks.
There is really no established route to take to success in cryptanalysis.
Good luck.
Joe
"Paradigm" <[EMAIL PROTECTED]> wrote in message
news:vwjI6.393$[EMAIL PROTECTED]...
> Hi,
>
> I'm finishing high school this year and I will apply for university right
> after to study math and computer science.
> I'm very interested in cryptography but I don't know very much about it.
In
> high school, we've learned about how RSA works but only from a math
> perspective, not from a cryptography perspective.
> I would really like to study cryptography, from the most simple ciphers to
> the most complex. My aim is to become so good that I can figure out ways
to
> attack ciphers or possibly even design my own (I'm very impressed when I
see
> postings here where some clever people are able to, apparently without too
> much difficulty, find loopholes in proposed ciphers etc.
> Anyway, I'm wondering if you could recommend some good books that doesn't
> require too much math. I took the 3-year A-level course in high school (In
> Denmark we've A, B and C level courses in high school) which among other
> things includes integration calculus, vectorials (is that what it's called
> in English?) and elementary number theory (not analytical). I've read a
book
> on analytical number theory on my own.
> Will this be enough for studying cryptography on my own or will I have to
> wait to we learn more math at uni?
> I really hope there is a good book on the subject that is advanced at the
> same time as being understandable to a person at "my level".
>
> I apologize for spelling errors etc. (I'm not a native speaker!)
>
> Thank you in advance,
>
> Martin
>
>
>
>
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: linear vs nonlinear
Date: Fri, 4 May 2001 09:30:40 -0700
Yes it is possible to construct everything so that it is linear. Just to
prove this take a block cipher (specifically the one that generates the
output values in the permutation desired), call it BC. Use it in counter
mode. You can easily define this as linear, you can count in it, simply
decrypt the value add one and encrypt. You can multiply, same basic
operation. The problem lies in the inability to do anything useful with it.
What we refer to as linearity is actually exploitable linearity. We can
easily count in GF2, Zp etc, but it is cryptographically difficult to count
in BC, so that cryptographic difficulty gets added to the complexity of the
attack. From a theoretic point of view you can construct attacks based on
being linear in BC, but in turn you have to establish the difficulty of
determining BC.
So basically you are correct, you can always construct linearity, but if it
is cryptographically difficult to determine or count there that linearity is
not useful.
Joe
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:IiwI6.13405$[EMAIL PROTECTED]...
> It's my understanding that a function is only nonlinear wrt to a
particular
> group. For example, DES sboxes are nonlinear wrt to GF(2).
>
> Is it not possible to always define a group in which a function is linear?
> I.e
>
> F(x) o F(x o A) o A = 0 for all A within the group and o is some form of a
> group operator.
>
> For example, F(x) = x + k mod p is nonlinear wrt to GF(2) but if we use
> GF(p) it's linear, etc..
> --
> Tom St Denis
> ---
> http://tomstdenis.home.dhs.org
>
>
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm
Date: 8 May 2001 14:35:16 GMT
[EMAIL PROTECTED] (Joseph Ashwood) wrote in <envXT2m0AHA.274@cpmsnbbsa07>:
>There are no known usable flaws in Rijndael/AES. The NSA did not choose
>Rijndael to be AES, NIST did. This is an important distintion because
>NIST is in charge of setting requirements for government agencies, NSA
>is in charge of brutalizing the security of all other countries and
Actually when it comes to crypto the NSA has the final word.
>supplying ciphers to us (meaning the US) that are not subject to
>brutality. The relatively short key in Rijndael is also not an issue,
>simply do the math.
The ciphers the NSA uses for the government are not open for
us to view. There is no reason to believe that Rijndael is any
where close to the secret ciphers the NSA uses. Rijndael will
only be implimented in modes the NSA can safely break. If it was
otherwise the NSA has failed its main job. And that is to keep
tabs on everything.
>
>You have in front of you a machine that can do certainly no more than 2
>billion additions per second. Let's say that it only takes one addition
>to encrypt with Rijndael (which it doesn't it actually takes much more),
>that means that 32-bit crypto can be broken in 2 seconds, 64-bit in 8
>billion seconds. But even with 1 billion billion of these machine
>working 24 hours a day it would take 20,000 years to break 128-bit
>cryptography. To break 256-bit cryptography with 1 billiob billion
>billion billion of those machines would take 400,000,000 years. I don't
>believe the short key is a major issue.
>
Again you use the approach that the NSA are fools. Even versions of
the Naval Engima had far more then 256 bit key. Hell by your defination
a ceaser cipher of the ascii character set is safe since the number
of keys 256! much much longer than your punny AES of 256 bits.
The point is be limiting it to 256 bits you limit the complexity
of the resultion encryption.
However that said I think one can foil the NSA by at least not
using weak modes and by using fully bijective versions of Rijndael
such as Matts BICOM. Instead of versions that will help the NSA
breaking system. One should never have a sytem where is possible that
one key is the only one that works. In Matts system at least all of
the keys point to a potinally file.
But the phony crypto gods seem to not want effective encryption
why? Why don't they bless systems like Matts. I think the reason is
obvious. I go back to start of message. The NSA wants to be able to
read all encrypted messages. And maybe thats a good idea then we can
beat the rest in business deals since we will read all there mail.
It may also help law encforcement with drugs. Since they maybe be
able to better check how much drugs are comming in so that those that
take bribes get a share of the profit. And newcomers trying to mussle
in on the organization already paying off our government officals
wont be a threat.
IN short the NSA has to much power. The more power it has the more
corrupt it will be come. I prefer a free people that don't need a
big brother watching our every step.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: Phil Carmody <[EMAIL PROTECTED]>
Subject: Re: GF(2^W) sboxes timings
Date: Tue, 08 May 2001 14:46:14 GMT
Tim Olson wrote:
> On deeply-pipelined processors like Athlon and Pentium-III, the
> if-then-else tests in the middle of the loop are going to cause a lot of
> branch mispredictions with large mispredict penalties. You might be able
> to speed up the loop quite a bit if you do the following trick to get rid
> of the conditional branches:
>
> unsigned long gf_mul(unsigned long a, unsigned long b)
> {
> unsigned long result = 0;
> long signB, lsbA;
>
> while (a) {
> lsbA = ((long)a << 31) >> 31;
> result ^= (b & lsbA);
> a >>= 1;
> signB = (long)b >> 31;
> b = (b << 1) ^ (0xd59c382dul & signB);
> }
> }
Beware the barrel shift problem that some processors have (e.g. P4)
lsbA = ((long)a << 31) >> 31;
can become
lsbA = ~((a&1)-1);
The '&' extracts the lowest bit, the -1 gives you all ones, or all
zeros, but the wrong way round, hence the ~.
Some processors have a ANDNOT, which would mean that you can ditch the
'~' above and just do
result ^= (b &~ not_lsbA);
However, some processors have conditional moves and
maybeB = (a&1) : b : 0;
result ^= maybeB;
could be in fact fastest.
On x86 family (PPro and beyond) the conditional move will need to be
prefixed with a test of the lowest bit of a. However, on the Alpha
family (and maybe others) there's a conditional move on 'oddness'.
If you know you're on a modern processor, and your compiler can handle
it, I'd go for the conditional move. However, this is simply gut feel.
Tom, please report back any findings if you try this out.
Cheers,
Phil
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Question about randomness and OTPs
Date: Tue, 08 May 2001 08:53:46 -0600
Joe H Acker wrote:
><snip>
> If that's correct, then I don't understand why I cannot use the
> ciphertext to encrypt another plaintext with it, and so on.
<snip>
Because the ciphertext is presumably not secret.
That is, we assume that the ciphertext can be intercepted;
if not, then why bother encrypting? Work out what would
happen if the adversary captured two consecutive messages
encrypted this way.
JM
------------------------------
** 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
******************************
