Cryptography-Digest Digest #813, Volume #8       Wed, 30 Dec 98 07:13:03 EST

Contents:
  Re: seeking SSH shell account (Nico Kadel-Garcia)
  Re: Free ENCRYPTION  Programs (32b) (Zach)
  Re: Common Modulus Attack on RSA ([EMAIL PROTECTED])
  Re: Free ENCRYPTION  Programs (32b) (AES Logic)
  Re: Security through obscurity in the smartcard world (Lincoln Yeoh)
  Re: Opinions on S/MIME ("Roger Schlafly")
  Re: Decoder for Reed-Solomon codes? (Jyrki Lahtonen)
  REQ: Anybody heard of these people? ([EMAIL PROTECTED])
  "Encrypted Magic Folders" substitute (Chuck Harrison)
  Re: ppdd - Encrypted filesystem (incl root filesystem) for Linux - rev  (Allan 
Latham)
  "should have" for an encrypting filesystem (Florian Erhard)
  Re: Open source Crypto algorithms in Java (Mr. Tines)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Nico Kadel-Garcia)
Crossposted-To: comp.security.ssh,alt.security
Subject: Re: seeking SSH shell account
Date: Wed, 30 Dec 1998 03:33:19 GMT

On 29 Dec 1998 14:26:20 -0800, Gregory G Rose <[EMAIL PROTECTED]> wrote:
>In article <768uup$7aa$[EMAIL PROTECTED]>,
>James J. Lippard <[EMAIL PROTECTED]> wrote:
>>Most people seem to prefer SecureCRT to F-Secure SSH, in my experience.
>
>I would dispute this gross generalisation. But
>then I'm not "most" people. Are you?

I am. The fonts and terminal handling and general screen behavior of
SecureCRT are vastly superior.


------------------------------

From: [EMAIL PROTECTED] (Zach)
Crossposted-To: alt.privacy,fido7.crypt,talk.politics.crypto,alt.privacy.anon-server
Subject: Re: Free ENCRYPTION  Programs (32b)
Date: 30 Dec 1998 04:12:01 GMT
Reply-To: [EMAIL PROTECTED]

On Tue, 29 Dec 1998 14:52:01 GMT, [EMAIL PROTECTED] wrote:

>DPTxx  Dos,  Win 95,  NT,   ENCRYPTION program
>  ( Download all programs for free! )
>
>Encrypt, Files, Directory's, Floppys, E-mail,  Messages ...
>Easy, with a few mouse clicks. 
>
>Hide your encrypted data's in a picture file, so there is no 
>traces of encryption.
>
>Visit the  Data  Privacy  Tools home page.
>
>       http://www.xs4all.nl/~bernard  
>
>
>
Has anyone any opinions on this encryption program? Looks interesting,
but I wouldn't know how to go about judging it on quality.

-Zach

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: Common Modulus Attack on RSA
Date: Mon, 28 Dec 1998 23:32:49 GMT

In article <D5ipormM#[EMAIL PROTECTED]>,
  "Max" <[EMAIL PROTECTED]> wrote:

> OK, but what if all the user knows is n (the modulus), not phi(n) [which is
> (p-1)(q-1)]?  What I'm really wondering is how someone factors n, given only
> an e,d pair and the modulus n.

Here is a way to do this from an old sci.crypt posting:

Subject: Re: Factoring n given d in RSA Author: Shai Halevi Email:
[EMAIL PROTECTED] Date: 1996/05/05 Forums: sci.crypt Message-ID:
<4milmr$[EMAIL PROTECTED]> organization: Laboratory for Computer
Science, MIT references: <4mfe4k$[EMAIL PROTECTED]>
<4mgh07$[EMAIL PROTECTED]> <4mhs34$78 [EMAIL PROTECTED]>

This is just a recap of a posting which already appeared here
a few days ago (since nobody seems to have read it). An algorithm
For factoring N given d and e (which works whether or not d, e are
small) can be found in Stinson's book. Below I repeat the algorithm
without the proof of correctness.

Given d, e, N, compute s = d*e -1, and write s = 2^i * r where r is
some odd integer.

Now pick at random an element x between 1 and N-1 and compute the
series y_0 = x^r   mod N
       y_1 = y_0^2 mod N
       y_2 = y_1^2 mod N
...
       y_i = y_{i-1}^2 mod N = 1

Consider the last element in the series of y_i's which is different
than 1. Call this element y. With probability 1/2, y is also different
than -1. Thus we have y^2 = 1 mod N, but y +-1 <> 0 mod N.

This implies that (y+1)(y-1) = y^2 - 1 = 0 mod N, so we have two
numbers which are not divisible by N, such that their product is
divisible by N. Thus we get gcd(y-1, N) = p, gcd(y+1, N) = q.

-- Shai

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

------------------------------

From: [EMAIL PROTECTED] (AES Logic)
Crossposted-To: alt.privacy,fido7.crypt,talk.politics.crypto,alt.privacy.anon-server
Subject: Re: Free ENCRYPTION  Programs (32b)
Date: Wed, 30 Dec 1998 04:41:27 GMT

My thoughts exactly, I looked at it, it does look nice, but I dont see
anything on that site that tells why kind of algorithm it uses or what
the cipher block size is, unless I missed that part.  But it does look
like a neato program.

On 30 Dec 1998 04:12:01 GMT, [EMAIL PROTECTED] (Zach)
wrote:

>On Tue, 29 Dec 1998 14:52:01 GMT, [EMAIL PROTECTED] wrote:
>
>>DPTxx  Dos,  Win 95,  NT,   ENCRYPTION program
>>  ( Download all programs for free! )
>>
>>Encrypt, Files, Directory's, Floppys, E-mail,  Messages ...
>>Easy, with a few mouse clicks. 
>>
>>Hide your encrypted data's in a picture file, so there is no 
>>traces of encryption.
>>
>>Visit the  Data  Privacy  Tools home page.
>>
>>       http://www.xs4all.nl/~bernard  
>>
>>
>>
>Has anyone any opinions on this encryption program? Looks interesting,
>but I wouldn't know how to go about judging it on quality.
>
>-Zach


------------------------------

From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: Security through obscurity in the smartcard world
Date: Wed, 30 Dec 1998 04:36:46 GMT
Reply-To: [EMAIL PROTECTED]

On 29 Dec 1998 17:58:21 GMT, Gary Howland <[EMAIL PROTECTED]> wrote:

>
>Security through obscurity in the smartcard world
>
>Admittedly, in the case of the GSM hack, early peer review of the
>system might have resulted in SIM cards that cannot be cloned at
>the present time, since they (the GSM designers) might have used
>a better algorithm due to the peer review.  But who's to say that

As far as I know the encryption the GSM designers came up with was
originally stronger than now, but it was watered down because of the Brits
(some claim the NSA had a hand in that) and other European countries. So
it's not just technical issues involved but political. So if the Spooks
want weak crypto then they push for it, if they want phones that can be
cloned then they'd push for that too. And so far they've got what they
wanted. 

There was some media noise in UK about the watering down of the GSM crypto
years ago (late 80s or early 90s?), but to no avail and it soon died down.
But it was public knowledge (in UK newspapers) that the crypto used was
weakened, so it was a bit surprising to me when a big deal was made out of
US hackers cracking GSM crypto. I'm not sure what is the real story behind
that story.

>obscurity.  My reason for wanting debate, first on the question of
>"is security through obscurity" valid, and second on "how?", is

Keep it secret between just two parties?

>dangers or mixing algorithms that have weak keys etc.  Any comments
>on the design of proprietary algorithms based on tried and trusted
>algorithms would be much appreciated.

I figure if the proprietary stuff isn't that popular then most people won't
bother cracking it. If it costs more to reverse engineer than it's worth
then most people won't try. Maybe the NSA will give it to trainees for
practice?

Cheerio,

Link.
****************************
Reply to:     @Spam to
lyeoh at      @[EMAIL PROTECTED]
pop.jaring.my @ 
*******************************

------------------------------

From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Opinions on S/MIME
Date: Tue, 29 Dec 1998 21:04:48 -0800


Brad Aisa wrote in message <[EMAIL PROTECTED]>...
>Excuse my possible ignorance, but I am assuming that the association of
>key lengths with dates is not supposed to mean that someone can
>effectively break the messages on those dates, only that they may very
>well be able to break the messages some fairly small number of years
>*after* the date, if they were encrypted using the indicated key
>lengths.

I suppose. Some people want to protect data for a few minutes, and
others for many years. Either way, I don't see the justification for the
rapid increase in key length, unless you think computers are going
to get 5 times as fast, every years, for many years.




------------------------------

From: [EMAIL PROTECTED] (Jyrki Lahtonen)
Crossposted-To: comp.dsp,sci.math
Subject: Re: Decoder for Reed-Solomon codes?
Date: 30 Dec 1998 06:50:11 GMT

In article <769k5i$piq$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says:
>
>
>
>I'm trying to implement a decoder for "Reed-Solomon" codes.
>I checked out the ECC codes page, and found a few encoders/decoders,
>but they all are designed for codes based on GF(2^m), m usually being
>something in the range 6..16.
>Unfortunately, my problem requires me to decode for codes built around
>GF(929).... any ideas? I'm stumped. And my math ain't what it used to
>be.... not that aceing Calc 101 would help!!

I would say that GF(929) is simpler (in theory at least) than the
char 2 fields that are usually used. As 929 is a prime, the arithmetic
(here multiplication and addition suffice, I think) is simply 
mul and add modulo 929. You probably also need to find a primitive
element modulo 929. This shouldn't be too hard - I will come back to
this later. 

The only other difference I can think of is that some implementation
in char 2 might depend on the fact that addition and subtraction
are the same thing in char 2 but not in char 929.

>Appreciate any pointers to freely accessible C code...
>
>--
>
Sorry don't know any. You might want to look at the book
"Algebraic methods for signal processing and communications coding"
by R.E.Blahut (published by Springer in a series on signal
processing and digital filtering). This explains the theory quite
well and is to a great extent designed to be read by engineers.
You also get an errors-and-erasures decoding algorithm plus
variations of Berlekamp-Massey algorithm in both time and frequency
domains.

Jyrki Lahtonen, Ph.D.
Department of Mathematics,
University of Turku,
FIN-20014 Turku, Finland
Note to human e-mailers! To obtain my real e-mail address form the
string consisting of my first name, a period, my family name (names in
lower case) and an at-sign followed by utu.fi

------------------------------

From: [EMAIL PROTECTED]
Subject: REQ: Anybody heard of these people?
Date: Wed, 30 Dec 1998 14:59:38 -0800
Reply-To: [EMAIL PROTECTED]

Hi,

There is an outfit on the net advertising an automatic e:mail encryption
system based on Diffie/Hellman.

I'm just curious to know if anyone has heard of them.

They can be found at 

http://www.nc-tech.net/nctmap.htm

Comments appreciated.

Thanx

------------------------------

From: Chuck Harrison <[EMAIL PROTECTED]>
Subject: "Encrypted Magic Folders" substitute
Date: Tue, 29 Dec 1998 23:05:27 -0800
Reply-To: [EMAIL PROTECTED]

A colleague of mine is building an MSWindows/PC based system which
streams multimedia data from disk. The multimedia data should be
encrypted ('cause someone else owns the copyright). For demo purposes
he's using "Encrypted Magic Folders", a shareware program
 (http://www.pc-magic.com/des.htm#emf).

>From the manufacturer's description of this product --
>     * How Secure is it?    
> 
>     EMF's encryption offers good protection and excellent speed.  It 
>     hasn't been broken yet   [...]
>     We developed our own encryption instead of using a standard
>     because we wanted EMF to be able to decrypt at the byte level.  

-- it seems likely it's an easy crack. What can be used for disk
encryption that's pretty secure but also decrypts fast enough to do
multimedia on the fly?

Thanks for any pointers,
 Chuck Harrison

------------------------------

From: Allan Latham <[EMAIL PROTECTED]>
Subject: Re: ppdd - Encrypted filesystem (incl root filesystem) for Linux - rev 
Date: Wed, 30 Dec 1998 10:00:29 +0100
Reply-To: [EMAIL PROTECTED]

=====BEGIN PGP SIGNED MESSAGE=====


Replies to recently asked questions:

> My biggest concern is that I will start using it, but that
> support for it will not be maintained in newer versions of
> Linux. 

This is still a BETA version and you should be prepared for nasty
events like total loss of the data. This has not happened so far
but please bewarned that it might! As for support, I intend to 
make a version for the 2.1 series as soon as this becomes the
"normal" standard. There is no point in putting cryptography
into an ever changing bug ridden hacker kernel. Changes in 2.0
series are now confined to areas well away from the block drivers
which ppdd uses. We can expect changes in the 2.0 series after
2.0.36 to patch using the 2.0.36 patch file. In view of the beta
stage of development I would expect users to make available any
patches they have used for higher revs (if necessary). It is my
intention to continue maintaining ppdd but of course I cannot
promise it.

> What exactly does it patch?

Your best bet is to look at the code itself. As well as the patch
file you will
find a "linux" directory in the ppdd-0.6 source directory. It
contains the new versions of items in the real linux source tree;
the patch file is the differences which need to be applied.

> What steps are taken to prevent key snooping by an unfriendly
> program?

If your attacker has root access there is no defense. Without root
access there is no way I know of to get the keys from kernel memory.
After you have mounted the ppdd device your security depends on the
unix file access permissions.

Remember that ppdd alone cannot protect you in a multi-user
environment any better than the environment itself. What it is
designed to do is to prevent someone who gains physical access to
your computer from gaining access to your data. Without ppdd it is
very easy to use a boot diskette and reset the root password and take
over the machine.
 
> Are any steps taken to prevent cleartext from being swapped to a
> swapfile?

They are in kernel buffers which do not get swapped. In non-kernel
programs they are destroyed as soon as no longer needed. If you are
paranoid you can swap to a file on an encrypted disk. For the ultra
paranoid there is always root filesystem encryption where no
plaintext at all gets written to disk.

Note that if your application loads plaintext into memory (whether
from a ppdd filesystem or not) and that memory gets swapped then
there is no protection except to swap to an encrypted filesystem.
 
> What are the encryption units? (one sector? etc.)

Ext2 blocks (1024 bytes)
 
> Does it have to encrypt/decrypt an entire file, or does it strictly
> work on blocks?

Pppd knows nothing about files at all - it sees the device as 1024
byte blocks. 

> I have a suggestion -- you might consider providing a more detailed
> FAQ or HOWTO, since if someone wants to use a cryptographic file
> system, they are likely to want to many answers and to understand
> the details of the system.

This message can form the start of it I guess!

Also please read the documentation in the package. It is not yet as
good as I would like it but it covers a lot of the basic questions
in more detail than an FAQ.

Please send me your comments when you try it out.


=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>

iQCVAwUBNondkuJCY/+xqTOxAQH+kwP+NHmO60t8xxcQXQi+O43vdZ4x/ML2GqoC
MjHFcUR7XQQRzhiitWROdevHFglkZFqHooVVxE1mkh8Apu+/GYb0TUhnrjL9HQfD
mXwYshUMOKMDkv56VGvXq9RFHELbMLUi/+/y5pOao39DiGrkPohGO3gle/sRjTla
Bj+z073cnfk=
=hEg0
=====END PGP SIGNATURE=====


------------------------------

From: [EMAIL PROTECTED] (Florian Erhard)
Subject: "should have" for an encrypting filesystem
Date: 30 Dec 1998 11:12:11 GMT

I'm writing my diploma thesis on the subject of an encrypting file system.
I already looked at many existing products and of course have my own 
thoughts, too. But perhaps you could write me some things, that come
to your mind when you think of what an encrypting file system should
look like. Your ideas shouldn't be lead by the problem how to solve them -
just think you have got some whishes granted.
For example one point on my list is, that I want to have a real multiuser
filesystem.

Thanks for your answers!
Florian

BTW: Since I read this ng, you don't have to reply by email.

------------------------------

From: Mr. Tines <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.java.programmer,comp.lang.java.security
Subject: Re: Open source Crypto algorithms in Java
Date: 29 Dec 1998 15:50 +0000

###

A quick follow-up to self - I've split the pure algorithm
code out from the application archive; to just access the
various algorithms (3Way, Blowfish, CAST5, DES, tripleDES,
Square, SAFER, TEA, MD5 SHA0, SHA1, HAVAL, RIPEM160) these
now stand alone (with the appropriate interface definitions)
at

http://www.windsong.demon.co.uk/crypt.zip

which has signature

=====BEGIN PGP MESSAGE=====
Version: CTCLIB2.1

iQCVAwUANoj4wIoUd45Z7dNFAQEyfwQAjK/9JxTzkO2+W7XK/Zc5H0VasehNRV8O
DfLhHjqE9PH1yLdf+UH6neFdE5RzF7eu78vYuJF1c3MsN7QliSrZ+NSH7pbv7Xx0
rFKnNU6rWnExQ9eN28HwRQBIPMxwgu2Uia1JQiVNS78zmVezocnCRCPJRIX8x5zn
CUHG550rORc=
=khqv
=====END PGP MESSAGE=====

-- PGPfingerprint: BC01 5527 B493 7C9B  3C54 D1B7 248C 08BC --
 _______ {pegwit v8 public key =581cbf05be9899262ab4bb6a08470}
/_  __(_)__  ___ ___     {69c10bcfbca894a5bf8d208d001b829d4d0}
 / / / / _ \/ -_|_-<      www.geocities.com/SiliconValley/1394
/_/ /_/_//_/\[EMAIL PROTECTED]      PGP key on page

### end pegwit v8 signed text
c8e9fb0b662593b641020aeab5a98f41635bb9c9887ac7a63c521236a652
ceb9bb54bb670b18277cad5194747c6ee9c3f4bf6bf5323df4701d9dca1a


------------------------------


** 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
******************************

Reply via email to