Cryptography-Digest Digest #289, Volume #12 Wed, 26 Jul 00 06:13:01 EDT
Contents:
Re: TheArgon Site (James Pate Williams, Jr.)
Re: Playing with an 8 bit cipher. (Mack)
Re: How is the security of Outlook Express encryption ? (Greg)
Re: Proposal of some processor instructions for cryptographical applications (Greg)
Re: How is the security of Outlook Express encryption ? ([EMAIL PROTECTED])
Re: How is the security of Outlook Express encryption ? (jungle)
Re: FAQ (jungle)
Re: WinZip (Sébastien SAUVAGE)
How to Convert p12 Files to Ascii for certificate installation ([EMAIL PROTECTED])
Re: purpose of final swap in Twofish? (Runu Knips)
Re: AESC-stream cipher ([EMAIL PROTECTED])
Re: purpose of final swap in Twofish? (=?iso-8859-1?Q?H=E5vard?= Raddum)
Re: How to Convert p12 Files to Ascii for certificate installation (Paul Rubin)
Re: CypherCalc - Any good? (Mark Wooding)
Small hash checksum ([EMAIL PROTECTED])
Re: Cursory Comments on Recursion (Mok-Kong Shen)
Re: Database encryption (Mok-Kong Shen)
Re: MD5 Collision Resistance (Mark Wooding)
Re: Database encryption (Paul Rubin)
Re: News about quantum computer (Mok-Kong Shen)
Re: 8 bit block ciphers (Runu Knips)
Re: 8 bit block ciphers (Runu Knips)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Subject: Re: TheArgon Site
Date: Wed, 26 Jul 2000 05:15:28 GMT
On Tue, 25 Jul 2000 17:07:44 -0400, "George Gordon"
<[EMAIL PROTECTED]> wrote:
>Hi group,
>
>Can anyone help this poor site? I think it's of some value to the community.
>http://www.theargon.com
>
>Regards,
>
>George
>
What does the acronym ARGON stand for and why is this site germane to
sci.crypt readers? From elementary chemistry we know that argon is an
"inert" gas, a.k.a "noble" gas and is used in some lasers and other
forms of illumination.
==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com/~pate
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Playing with an 8 bit cipher.
Date: 26 Jul 2000 06:14:20 GMT
"Trevor L. Jackson, III" [EMAIL PROTECTED] wrote:
>
>If you have MIPS to use instead of memory you could emulate the permutation
>table with a smaller working set. You'd need a lookup function that, given a
>single byte of input (virtual array index), would return the contents of the
>shuffled table that you don't have room to store. The lookup function would
>have to (laboriously) backtrack the shuffle process until it could determine
>the contents of the desired slot in the table.
>
>This can probably be implemented in only a few bytes, but would take O(N^2/2)
>operations on average where each operation is a virtual byte swap driven by
>the RNG controlling the shuffle. Since N is 256, this is not going to be
>fast.
>
>
That is why I was looking for 8 bit block ciphers
that were reasonbly fast. On the fly calculation
with minimal memory.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: How is the security of Outlook Express encryption ?
Date: Wed, 26 Jul 2000 06:10:07 GMT
> Does anyone know what is the key lenght of Outlook Express's
> singing/encryption ?
Irrelevent.
> And is it safe enough ?
Irrelevent.
Outlook Express uses CryptAPI which is in itself unsafe.
I developed a piece of software that placed itself between
OE and the crypto layer and intercepted the plain text. From
this result, you can imagine that the data could be covertly
sent over the internet to a clandistine ip address from a
virus and you would never know it was happening (well, 99.999%
of the population would never know it).
Look at my web site for some additional information on this
topic http://www.ciphermax.com
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: Wed, 26 Jul 2000 06:14:22 GMT
> > At the second level, the swapping is done separately on each half of
> > the word. Analogously for the higher levels.
>
> Doing this isn't very difficult either. Consider:
>
> mov r14, #&ff
> orr r14, r14, r14, lsl #16
> eor r1, r0, r0, lsr #8
> and r1, r1, r14
> eor r0, r0, r1
> eor r0, r0, r1, lsl #8
It can get hard (and a lot of fun too) if you use a RISC that
has lots of parallel execution features that can be exploited
to make the overall process much faster once you arrange the
instructions just right.
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How is the security of Outlook Express encryption ?
Date: Wed, 26 Jul 2000 06:33:23 GMT
Greg <[EMAIL PROTECTED]> wrote:
[...]
> Outlook Express uses CryptAPI which is in itself unsafe.
I would hardly rule out the original questions as
irrelevant. Subverting the CryptAPI presupposes you can install
software on the machine. Granted, that's not farfetched to do even
remotely, given most of MS's design choices but still, an important
consideration for encrypted email is how safe is the message during
transit. By your reasoning, any encryption at all on System V is also
useless, as I can push a STREAMS module onto the terminal stack and
record the user's every keystroke.
That's not to say that CryptAPI doesn't have problems, possibly
serious ones, just that it hardly makes the strength of the cipher
used irrelevant.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: How is the security of Outlook Express encryption ?
Date: Wed, 26 Jul 2000 03:18:16 -0400
Greg wrote:
>
> > Does anyone know what is the key lenght of Outlook Express's
> > singing/encryption ?
===============
> I developed a piece of software that placed itself between
> OE and the crypto layer and intercepted the plain text.
this has nothing to do with the ORIGINAL question ...
you don't need to use your "a piece of software" to get PLAIN TEXT ...
use any KEY LOGGER instead ...
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: FAQ
Date: Wed, 26 Jul 2000 03:29:02 -0400
in sci.crypt forum ...
LecturaX Porodum wrote:
> Where can I find the sci.crypt FAQ?
------------------------------
Subject: Re: WinZip
From: [EMAIL PROTECTED] (Sébastien SAUVAGE)
Date: Wed, 26 Jul 2000 07:31:51 GMT
[EMAIL PROTECTED] (Martin 'SirDystic' Wolters) wrote in
<8lkdvu$ibd$[EMAIL PROTECTED]>:
>>Yes, search for 'crack zip' on http://neworder.box.sk
>
>These tools use brute force. It's the slowest possible
>method of recovering encryption keys.
With a good dictionnary, this can be sometimes quite fast.
There are also plaintext attacks againt ZIP encryption where you will
get the password immediatly.
--
Sébastien SAUVAGE - [EMAIL PROTECTED]
http://www.bigfoot.com/~sebsauvage
------------------------------
From: [EMAIL PROTECTED]
Subject: How to Convert p12 Files to Ascii for certificate installation
Date: Wed, 26 Jul 2000 07:35:27 GMT
Hello,
how can i convert my p12 files, which i exportet from Netscape or IE
cert db to the ascii strings that start with :
i.e :
=====BEGIN CERTIFICATE=====
MIIBKjCB1QIBADBwMQswCQYDVQQGEwJERTEPMA0GA1UECBMGQkVSTElOMQ8wDQYD
VQQHEwZCRVJMSU4xFzAVBgNVBAoTDmJvbmUgbGFicyBHbWJIMSYwJAYDVQQDEx13
+CMO1BBbkhYZ3vvcXA8=
=====END CERTIFICATE=====
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 26 Jul 2000 09:54:32 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: purpose of final swap in Twofish?
Eric Smith wrote:
> The Twofish paper does a great job of explaining the purpose of
> most of the elements of the algorithm, but I'm mystified as to
> the purpose of the swap after round 16, which cancels out the
> swap done in that round.
>
> Is there any particular reason for this extra swap (or equivalently,
> for eliminating the swap of the last round)?
I can't find such a thing in neither my own, nor Brian Gladman's
nor the GnuPG sources, and also not in the paper, so what are
you talking about ?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AESC-stream cipher
Date: Wed, 26 Jul 2000 08:20:04 GMT
New feature.
' Braking cycles in key stream'
Encryption and decryption procedures are modified in order to brake
cycles in key stream generation. Periodically two bytes of plain text
stream are inserted in the input of key stream generator. This brakes
cycles in key stream and makes key stream dependent on parts of the
plain text.
Updated source code and executable are available for download at
www.alex-encryption.de.
Please follow link for 'AESC'
Regards.
Alex.
In article <8lhbn8$h1v$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Due to request to change the name of algorithm.
> Relates to the thread 'new stream cipher'.
> AESC-Alex Ernst Stream Cipher.
>
> Performance of this implementation is 190 Mbyte/sec.
> It was measured sending 256 byte in loop 777215 times.
>
> Description.
>
> Idea of this algorithm goes up to Vigenere cipher.
> Plain text stream is a sequence of bytes.
> Key stream is generated as stream of words but it
> is used for encryption as stream of bytes.
> Key has length 256 byte.
> Vigenere Tableau is implemented as multiplication table
> of finite group of the order 256.
>
> Key stream is generated using finite group of the order
> 65536 and chained encryption.
>
> Key schedule.
>
> 1. A key is interpreted as sequence of automorphisms of 256-group.
> 2. The key is interpreted as sequence of automorphisms of 65536-group.
> 3. The key is a start segment of key sequence generation using
> 65536-group and chained encryption, which may be called as
> Quasi One Time Pad.
>
> Encryption.
>
> Byte of input plain stream and byte of key stream are
> operands of group law of composition.
> This gives one byte of output cipher stream.
>
> Decryption.
>
> Byte of input cipher stream and inverse to byte of
> key stream are operands of group law of composition.
> This gives one byte of output plain stream.
>
> Delphi source code, EXE, description in pdf and
> description to view online are available at
> www.alex-encryption.de. Please follow links for 'AESC'
>
> Regards.
> Alex.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: =?iso-8859-1?Q?H=E5vard?= Raddum <[EMAIL PROTECTED]>
Subject: Re: purpose of final swap in Twofish?
Date: Wed, 26 Jul 2000 10:50:33 +0200
Eric Smith wrote:
> The Twofish paper does a great job of explaining the purpose of
> most of the elements of the algorithm, but I'm mystified as to
> the purpose of the swap after round 16, which cancels out the
> swap done in that round.
>
> Is there any particular reason for this extra swap (or equivalently,
> for eliminating the swap of the last round)?
>
> I'm working on an implementation for the Microchip PIC16 family of
> microcontrollers. An implementation for the PIC18 family would be
> somewhat more efficient, but those aren't yet in widespread usage.
>
> Thanks!
> Eric
Undoing the last swap is common in all Feistel ciphers. The reason for
this is that decryption becomes the same as encryption with the round
keys in reversed order, so one can use the implementation for encryption
to decrypt also. If you draw a diagram of a general Feistel cipher and
trace the halves of the intermediate ciphertexts you will see that this
is so.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: How to Convert p12 Files to Ascii for certificate installation
Date: 26 Jul 2000 08:52:22 GMT
In article <8lm4bv$39u$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Hello,
>
>how can i convert my p12 files, which i exportet from Netscape or IE
>cert db to the ascii strings that start with :
>
>
>i.e :
>
>-----BEGIN CERTIFICATE-----
>MIIBKjCB1QIBADBwMQswCQYDVQQGEwJERTEPMA0GA1UECBMGQkVSTElOMQ8wDQYD
>VQQHEwZCRVJMSU4xFzAVBgNVBAoTDmJvbmUgbGFicyBHbWJIMSYwJAYDVQQDEx13
>+CMO1BBbkhYZ3vvcXA8=
>-----END CERTIFICATE-----
Simplest way is with the openssl pkcs12 and x509 commands (see
the built in help strings). www.openssl.org.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: CypherCalc - Any good?
Date: 26 Jul 2000 09:10:09 GMT
Doug Stell <[EMAIL PROTECTED]> wrote:
> We are considering the purchase of CypherCalc for the generation of
> public key test vectors. Does anybody have an opinions on this
> product?
>
> If there are other products, preferably Windows based, that you know
> of, please send me a pointer. We've tried UBASIC and PARI with no
> success and I have not been able to locate any others.
In the development of my Catacomb library, I've been greatly helped by
`calc', a multiprecision calculator with a C-like programming language
originally written by David I. Bell and now maintained by Landon Curt
Noll. It's free software and runs on most Unix boxes. There's a Debian
package `apcalc' which is useful if you run Debian.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED]
Subject: Small hash checksum
Date: Wed, 26 Jul 2000 09:08:07 GMT
Hello,
I am looking for a way to represent a larger checksum like this:
A0D20D19181D1DCF9A0BAADAE496CEB5
with a smaller signature using 4 or 6 characters (e.g. A62D9K or just
A62T). It doesn't have to secure at all since the two will be placed
besides each other. It just has to be fairly unique.
I will use it for a fast check, and the larger checksum I will use in
cases of doubt.
I don't know anything about coding this sort of algorithms, which is
why am asking here. I just don't thisk I would be able to create a
unique string on my own.
Kind regards
ras
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cursory Comments on Recursion
Date: Wed, 26 Jul 2000 11:39:08 +0200
wtshaw wrote:
> [snip]
>
> I was surprised to see the full results, that the Best Bases in recursion
> are 66, 78, 93, and 94, and that the bottom five categories include the
> most popular bases recursively used in so-called modern algorithms.
>
> The common wisdom is that prime numbers are best for encryptive bases, but
> the data seems to say, if anything, that bases of all integer powers of
> low primes, 2, 3, 5, and 6, with a very few unpredicted others, are
> ill-suited as compared with others for recursive usage.
I don't rememeber to have seen your definition of recursion of bases.
Do you mean successive changes of a number of number bases?
I suppose that using a pair of larger relatively prime bases results in
a larger mapping and hence may be more advantageous in general.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Database encryption
Date: Wed, 26 Jul 2000 11:38:27 +0200
Kevin Crosbie wrote:
> Encryption is not a problem, the problem is in the storage of the primary
> key... Where do I store such a sensitive piece of data. I don't want it
> possible to have my system compromised by someone find the single system
> secret.
Sorry, I still can't understand. If you run an encryption algorithm
of your own choice to process your data before putting it into the
database, you could store the key anywhere, including your
biological memory space. Or I am missing something? If you use
a system provided encryption facility, then I don't know, for that
can depend on your system.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: MD5 Collision Resistance
Date: 26 Jul 2000 09:26:39 GMT
Paul Martin <[EMAIL PROTECTED]> wrote:
> I'm currently investigating different hashing algorithms for use of
> primary keys in our database. Having sequences is simply not an
> option because of the tremendous difficulty of keeping numbers
> distinct in a distributed environment, so we though hashing distinct
> values could solve the problem.
>
> We're sort of sold on MD5 already because of it's speed and 128-bit
> result. Our internal benchmarks were really impressive for MD5. There
> will be a large amount of data to hash on a regular basis: Our primary
> requirements are speed and collision-resistance.
Two important questions at this stage.
1. Are your preimages (inputs to the hash function) chosen by malicious
adversaries?
2. Do you need to allow third parties to compute your hash function?
If the answer to 1 is `no' then I'd use MD4 instead. It's much faster,
still has a 128-bit result, and I'm not aware of any research which
suggests that collisions occur in random preimages more often than
expected. (When I say `much faster', I recall one test I did which
suggested that MD4, with a 128-bit result, was faster than a 32-bit CRC.
Both functions were written in assembler; the MD4 code worked best on
word-aligned input data.)
If the answer to 1 is `yes' and the answer to 2 is `no' then use
MD5-HMAC. HMAC is secure provided your adversary can't find collisions
in the underlying hash function with unknown IV. Since the best result
I know of against MD5 finds only pseudocollisions in the compression
function (that is, two input block/chaining variable pairs which give
the same result from the compression function), this should be rather
strong.
If the answer to both questions is `yes' then use some other hash
function. If you're really sold on a 128-bit result, then your best bet
could well be RIPEMD-128 (not the original RIPEMD -- the cut-down
128-bit version of RIPEMD-160). Or you could take one of SHA1,
RIPEMD-160 or Tiger and just keep the first 128 bits of the result,
although this will tend to be slower than a purpose-designed 128-bit
hash function. Of course, if you can cope with larger hash results then
use one of SHA1, RIPEMD-160 or Tiger and keep the whole output. If your
platform is a proper 64-bit architecture, Tiger's probably your best
bet for performance.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Database encryption
Date: 26 Jul 2000 09:46:38 GMT
In article <8lkga0$[EMAIL PROTECTED]>,
Kevin Crosbie <[EMAIL PROTECTED]> wrote:
>Encryption is not a problem, the problem is in the storage of the primary
>key... Where do I store such a sensitive piece of data. I don't want it
>possible to have my system compromised by someone find the single system
>secret.
>
>I figured a smart-card or dongle would be a viable storage area for such a
>key.
I see what you mean, you want to make sure there's no hot data on your
backup tapes and stuff like that.
You need a hardware encryption module. For low traffic, a smart card
or dongle would be ok, but they are very slow. You could use one to store
a secret key and load it into your computer, but that would be much
less secure than doing the encryption in the module.
For a nice dongle, see
www.ibutton.com/ibuttons/java.html
For more serious modules, see:
www.ncipher.com -- NForce/NShield modules
www.ibm.com/security/cryptocards/index.html -- 4758 coprocessor
The 4758 is more secure and flexible of the bunch but it's hard to program.
I haven't used it but have been wanting to.
I'm using the NCipher stuff which is closer to plug and play, but
less flexible and kind of expensive (starts around $5k, vs. about $2k
for the 4758). It has the advantage of being hard to mess up with.
There are some other vendors too. See
http://csrc.ncsl.nist.gov/cryptval/140-1/1401val.htm
for a list.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: News about quantum computer
Date: Wed, 26 Jul 2000 12:04:48 +0200
Bill Unruh wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> writes:
>
> >The German newspaper Computer Zeitung reported in its 13 July
> >issue that a team consisting of US and German researchers
> >has succeeded to synthesize a molecule that can store 5 qubits,
> >while the best previous result was 3 qubits.
>
> ??? I do not know what this means. The record is 7 bits for an NMR
> system.
The Computer Zeitung has in its next issue of 20th July
presented a one-page report on the 5 qubit. It seems that
this is indeed the current record, unless you could find
out a literature reference on your said 7 qubit.
M. K. Shen
------------------------------
Date: Wed, 26 Jul 2000 11:45:59 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: 8 bit block ciphers
Mack wrote:
> >Mack wrote:
> >> Accept I don't have 64 bytes to play with.
> >He also said before:
> >> I am looking for something that could be implemented without
> >> having the entire table in memory. For example only using
> >> 32 bytes.
> >
> >You said 'for example' so I thought you meant 'for example'.
> >Well, with only 32 byte, I guess you still can implement
> >Twofish or Serpent, at least in a 128 bit only version.
>
> I do have 64 bytes total. But all of it can't be used for
> the encryption. 8 of it has another use.
ARG ! 64 bytes TOTAL ???? No stack space or such ? :-((((((((
OUCH. No, forget it, I meant 32 Bytes 'on the heap' plus masses
of stack space during the algorithm execution itself.
------------------------------
Date: Wed, 26 Jul 2000 12:01:39 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: 8 bit block ciphers
Mack wrote:
> I do have 64 bytes total. But all of it can't be used for
> the encryption. 8 of it has another use.
I don't believe you have 64 bytes total. How many stack
space do you have, and how many registers (of which
size) ? 64 bytes total is pretty small to do anything
useful.
A good cipher should have at least a 80 bits (20 bytes) key
length and a 64 bit (16 bytes) block size. And one normally
needs the last block for CBC mode.
The AES candidates (such as Serpent or Twofish) have 128 bit
block size (normally on the stack) and a key size of either
128, 192 or 256 bits.
------------------------------
** 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
******************************
