Cryptography-Digest Digest #555, Volume #10 Fri, 12 Nov 99 15:13:02 EST
Contents:
Re: S/MIME plug-in for Eudora? Strong Encryption (Adam Kippes)
Re: Need technique for about 24 bytes (Paul Koning)
----------------------------------------------------------------------------
From: Adam Kippes <[EMAIL PROTECTED]>
Crossposted-To:
comp.security.misc,comp.security.pgp.tech,alt.security.pgp,comp.mail.eudora.ms-windows
Subject: Re: S/MIME plug-in for Eudora? Strong Encryption
Date: Fri, 12 Nov 1999 12:55:36 -0500
Reply-To: [EMAIL PROTECTED]
In <[EMAIL PROTECTED]>, Michael Ströder wrote:
> > Perhaps, but there is no expiry on the keys
> Well, I would regard this is as being a security drawback of PGP.
You would, I wouldn't.
> Just like all the key revocation handling in PGP.
This *can* be a nuisance.
> > and I can (and do) use it for
> > a lot more than encrypting mail.
> You can do everything with S/MIME that can be done with PGP (but you
> simply don't understand it).
There's a command line version that lets me quickly and easily encrypt
files for storage? Among other things.
-- AK
--
[EMAIL PROTECTED]
PGP keys available from servers
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Need technique for about 24 bytes
Date: Fri, 12 Nov 1999 12:19:37 -0500
Caesar Valenti wrote:
>
> I am in need of finding source code that will encode (and decode, of
> course) a string of about 24 characters. Out of necessity, the string
> will only consist of the 36 alpha numeric characters (case insensitive)
> The encrypted string is also limited to the same 36 characters. The
> encrypted string should be about the same size as the original.
>
> The code should relatively short and easy to implement. Security is a
> moderate concern; however I can accept 99.99% security for the general
> population (in this group, probably more like 20%!).
>
> I know this is a newbie question. I am extremely new to this, so be
> gentle. I will be getting a copy of Applied Cryptology this weekend,
> and will review it. Any ideas? Possibly RC4? XOR? or???
Off the top of my head...
1. Map each plaintext character to an integer 0..35.
2. Take bytes from the RC4 bytestream.
3. Add the two MOD 36.
4. Map the result back to an alphanumeric character.
Decrypt: ditto but subtract rather than add in step 3.
Clearly step 3 doesn't produce a uniform distribution since
256 isn't a multiple of 36, but I don't see how that property
creates a weakness. (If anyone disagrees, I'd welcome an
explanation!)
paul
------------------------------
** 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
******************************
