Cryptography-Digest Digest #383, Volume #13      Fri, 22 Dec 00 17:13:00 EST

Contents:
  Re: WinGPG 1.0 - A free, compact, non-ADK Windows alternative to PGP 
([EMAIL PROTECTED])
  Re: Algorithm for check SAC complience (Tom St Denis)
  Re: Why primes? (Simon Johnson)
  Re: WinGPG 1.0 - A free, compact, non-ADK Windows alternative to PGP ("Ryan 
Phillips")
  Re: All irreducible polys of degree 32 over GF(2) ("Matt Timmermans")
  Re: WinGPG 1.0 - A free, compact, non-ADK Windows alternative to PGP ("Ed Suominen")
  Re: Steganography using text as carrier (Andre van Straaten)
  AIM Password Encryption (John Stanford)
  Re: Visual Basic Source Code (Paul Schlyter)
  Re: AIM Password Encryption ([EMAIL PROTECTED])

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

From: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp
Subject: Re: WinGPG 1.0 - A free, compact, non-ADK Windows alternative to PGP
Date: Fri, 22 Dec 2000 19:05:37 GMT

In article <G0E06.387$[EMAIL PROTECTED]>,
  "Ed Suominen" <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The first "actual" release of WinGPG, a Windows 9x, ME, NT, 2K
installation
> package of GPG and Timo Schulz's great little WinPT program, is now
> available at ftp://eepatents.com/clients/wingpg.exe. The ZIP archive
is
> available at ftp://eepatents.com/clients/wingpg.zip for those who
just want
> to browse through the files. Though this is probably still a "beta"
release,
> it seems to work OK on a couple of PCs and seems to be very easy to
use.
> Included in this release is my first public disclosure of a passphrase
> selection scheme I've invented and a user's guide ("ABC MANUAL")
written in
> simple, clear language for the average computer user who doesn't know
(or
> care) anything about cryptography.
> Timo and I plan to work together on the next release, and look
forward to
> comments, suggestions, and the inevitable bug reports.

is the patch for the gpg signature bug
http://lists.gnupg.org/gnupg-announce-200011/msg00002.html
included in your windows build?

vedaal


Sent via Deja.com
http://www.deja.com/

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

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Algorithm for check SAC complience
Date: Fri, 22 Dec 2000 19:21:44 GMT

In article <9205h9$jj2$[EMAIL PROTECTED]>,
  Simon Johnson <[EMAIL PROTECTED]> wrote:
> In article <91uc5d$85h$[EMAIL PROTECTED]>,
>   Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <91tuqj$t7h$[EMAIL PROTECTED]>,
> >   Simon Johnson <[EMAIL PROTECTED]> wrote:
> > > The topic basically states the question?
> > >
> > > In websites i should visit?
> >
> > Well checking for SAC is normally done with a simple monte carlo
test
> > flipping input bits and checking the result.
> >
> > For example in for a n-bit block cipher you should construct an n
by n
> > matrix where each row represents flipping a different input bit and
> > each column the change in the output bit.
> >
> > If you add a '1' when it changes and a '-1' when it remains the same
> > you can perform the test easily.  After N tests (N == BIG) the
> quotient
> > (i.e element of the matrix over N) should approach zero.  IF not
there
> > is a problem.
> >
> > Tom
> >
> > Sent via Deja.com
> > http://www.deja.com/
> >
> This sounds like it'll work.....
> Only, it sounds very computationally intensive. Does your s-box
> generator use this method, its seems quite fast you see :)

Well testing an sbox and a cipher while conceptually the same are very
different.  An sbox is just a lookup table while a cipher has a more
complex structure.

Also my sboxgen program (which I assume is what you are reffering to)
does fast-out testing which means it doesn't complete a test it knows
will fail.

Tom


Sent via Deja.com
http://www.deja.com/

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

From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Why primes?
Date: Fri, 22 Dec 2000 19:50:06 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] wrote:
>
> [The irritating little gnome is
> back with new silly questions. :)]

These questions are not silly, but i agree with your gnome like
appearance :)

> I've understood it that in public/private
> key ciphering one uses quite big prime numbers.

Yes, most public key systems use large primes... Some do not, e.g. the
knapsack algorithms.

> Well, why use primes? Why can't any two quite
> big numbers (QBN [tm]) be used?

Hrm, well this really depends on the semantics of how the primes are
used. Lets look an example, RSA. RSA can be summarized as follows:

C=M^e mod n
M = C^d mod n

M -> Plain-text block
C -> Cipher-text block
e -> Public exponent
d -> Private exponent
n -> Modulo.

Now the ability to find e from d (and d from e) is conjectured to lie
in the problem of factoring 'n'. There is good evidence of this, but no-
one has proved it. Lets say n is composed of two factors: p and q, both
of which are prime. Then if we fix e to some number relatively prime to
and less than 'n', then we compute d as follow:

if n=pq, and the number of numbers relatively prime to n is given by 0
(n) then:

0(n) = (p-1)(q-1)

and it can be shown that:

d=e^(0(n)-1) mod 0(n)

Now if we pick n at random, we would have two problems. In order to
find a public d, from a selected e we would have to factor 'n'.
Clearly, if you can do it someone else can, so this negates the purpose
of designing the entire system. Secondly, the factors of 'n' may be
small, which makes for quick factoring.

This is why it is a bad idea to use more than two primes for 'n',
because you can factor a composite comprised of three factors faster
than you can two, in general.

> What is the relationship between the public
> key and the private? Is it that the public
> key is the product of the two QBNs? If so,
> what does the private key consist of?
> (the actual two QBNs?)

This depends on the algorithm that you use. However, i've answered this
question above for the most comonly used algorithm, RSA.

Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File


Sent via Deja.com
http://www.deja.com/

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

From: "Ryan Phillips" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: WinGPG 1.0 - A free, compact, non-ADK Windows alternative to PGP
Date: Fri, 22 Dec 2000 12:02:15 -0800

Is the source going to be available?

-Ryan

"Ed Suominen" <[EMAIL PROTECTED]> wrote in message
news:bUM06.1646$[EMAIL PROTECTED]...
> My apologies for posting incorrect URLs to WinGPG. The correct ones are:
>
> Installation file: ftp://eepatents.com/clients/wingpg-v1-00.exe
> ZIP archive for browsing individual files:
> ftp://eepatents.com/clients/wingpg-v1-00.zip
>
> I would appreciate any comments (positive and negative alike) from those
who
> find the installation package (and the enclosed user's guide and
passphrase
> selection worksheet) useful. Please copy Timo Schulz, the author of WinPT,
> at mailto:[EMAIL PROTECTED].
>
> Ed Suominen
> Registered Patent Agent
> Web Site: http://eepatents.com
> PGP Public Key: http://eepatents.com/key
>
>
>



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

From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: All irreducible polys of degree 32 over GF(2)
Date: Fri, 22 Dec 2000 20:01:19 GMT

"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:91v78i$ovf$[EMAIL PROTECTED]...
> Question:
>   Is there a distribution on N-bit vectors of weight <= k
>   (for some fixed constant k) so that, with high probability,
>   O(N) randomly chosen vectors suffice to span the space?

As John mentioned, it's not possible, but using vectors with large weight
doesn't necessarily imply quadratic complexity. Certain vector bases may
have an FFT-like construction, for example, that lets you calculate N random
dot products in O(N log M) time, where M is the number of vectors you have
to choose from.





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

From: "Ed Suominen" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: WinGPG 1.0 - A free, compact, non-ADK Windows alternative to PGP
Date: Fri, 22 Dec 2000 13:41:32 -0700

"Ryan Phillips" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Is the source going to be available?

Yes - it's available now. The installation package is actually just a bunch
of cleverly (?) hidden DOS batch files assembled into an "Encryption
Workspace" with a self-executing archive. The GPG source is available at
http://www.gnupg.org and the WinPT source is available at
http://people.freenet.de/joesixpack/winpt-en.html

The source for the compression utilities used during encryption/decryption
does not appear to be available but the those utilities are interchangeable
with any open-source command-line ZIP utilities, if such exist. (Let me know
of any, please!) All the actual encryption/decryption is done with
open-source, GPL'd software. (I wouldn't have it any other way!)

Ed Suominen
Registered Patent Agent
Web Site: http://eepatents.com
PGP Public Key: http://eepatents.com/key





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

From: Andre van Straaten <[EMAIL PROTECTED]>
Subject: Re: Steganography using text as carrier
Date: 22 Dec 2000 14:48:51 -0600

[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
>   Andre van Straaten <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>> > In article <[EMAIL PROTECTED]>,
>> >   Andre van Straaten <[EMAIL PROTECTED]> wrote:
>> >> Steganography is to hide your plain- or ciphertext at all. It's
> like
>> >> camouflage. It's like crossing a border illegally. Being seen means
>> >> the end of the game.
>> >> The problem here is, how distrustfully is the adversary to
> distinguish
>> >> the hidden object from the environment.
>> >> A company which transmits a lot of information can easier add some
>> >> hidden information than a private person which starts suddenly
>> >> interchanging large texts of Shakespeare or other stuff which makes
>> >> no sense.
>>
>> > I don't see an advantage over an OTP. You transpose the ASCII
> characters
>> in a constant way into a proprietary number scheme and generate
> finally
>> an MPI string out of an operation of two texts.
>> Security is given only by applying an operation between a unique
> plaintext
>> and a unique key text.
>>
>> I suggest you give a short example with your translation of characters
>> and your operation which applies.

> assume the following carrier text:

> <received your e-mail, will respond soon>

> assume the following message text:

> <delete and wipe everything in your z folder immediately!>

> the algorithm would first transform the two messages into ascii three
> digit strings:

> carrier text:

> 114101099101105118101100032121111117114032101045109097105108044032119105
> 108108032114101115112111110100032115111111110


> message text:

> 100101108101116101032097110100032119105112101032101118101114121104105110
> 103032105110032121111117114032122032102111108100101114032105109109101100
> 105097116101108121033


> the algorithm now compares the strings of the two texts, sees that the
> carrier text is shorter, and adds the 032 representation for empty
> space to make the two texts of equal length:

> 114101099101105118101100032121111117114032101045109097105108044032119105
> 108108032114101115112111110100032115111111110032032032032032032032032032
> 032032032032032032032

> it would then compute the offset, and represent it as a MPI.

I see you use the ASCII character set. In former posting, you suggested
an operation like this: 
resulting string = 256 - message text + carrier text

I leave spaces between the 3-digit-numbers for better reading.

270 256 247 256 245 ... ... ... 183 191 172 187 180 167 255 

I calculated only the beginning and the end to avoid writing a program
for that.

You see that the tail looks different from the head.

If you meant another operation, please show it here instead.

But I don't see any difference to an OTP.

> This example is with the intent of hiding the MPI within the carrier e-
> mail text.

Using an XOR operation instead of the one you proposed, the values keep
at least between 0 and 256, but most of them won't be sensible letters
(33 through 126 decimal), eitherway.

> If this were done for cryptography, then the carrier would have to be
> longer than the message text, or an attacker could find the end of the
> plaintext by just having the MPI and assuming a repeating sequence of
> 032 for the end of the carrier.
> But, if the carrier were an agreed upon random text that the recipient
> already knows, there would be no way for an attacker to reconstruct the
> message from just knowing the MPI.

That's a feature of the OTP.

> The advantage of this form of cryptography is that it is not dependent
> on any keys or vulnerable to any new mathematical breakthroughs.

The key is your reference text, or the "text that the recipient already
knows", as you describe it.

I'm not a mathematician, but there is a proof that the OTP is 100%
secure. Well, I think it's easily to understand even without being
a mathematician.

> This disadvantage is that it is not a public key system, and requires
> the initial secure agreement on a starting carrier text. Once this is
> done, the carrier texts can be changed each time as instructed within
> the previous message.

If you reuse the carrier text, you will weaken the security.

>> I doubt that you can hide a text within a large amount of empty space,
>> because you apply always the operation with the same empty space
>> character.
>> An OTP uses generally the ASCII character set with the XOR operation.
>>
>> This book is mainly about steganography, and it generates messages in
>> that way that it breaks up sentences in its grammatical parts and
>> constructs new sentences depending on the plaintext input like:
>> Bob drives to Washington, D.C.
>> Alice is driving to New York.
>> Carol arrives tomorrow in New York.
>>
>> I don't see a way to hide a message within a text message by adding
>> or changing some bits in a byte as it is done with graphic files.
>> If you change only one bit in an ASCII file you have another
> character,
>> i.e. a typo.

This is important. See below.

>> You could use another set of characters with a wider range of possible
>> characters, instead of 256 you could 64 kB. But this representation
>> doesn't fit in any ASCII or HTML application.

> There are many possible ways to unobtrusively hide/mark things in
> carrier text.

Not on a byte basis as you describe it.
E.g.: 
You have two ASCII characters: "re"
This is decimal 114, 101
or bitwise 
r: 0111 0010
e: 0110 0101

You can change only a bit, as this is the smallest atomic unit
in computer memories.
There is nothing to hide in between, or like that.
And if you flip only one bit, you have another ASCII character.
So, there is not even one way to "unobtrusively hide/mark things".

> i would prefer to see what has been done or tried already before
> proposing something new,

> but offhand, it is possible to send a message in html, with values
> assigned to font sizes, font types, and background stationery, that a
> short enough string could be denoted by the unique combination of those
> factors with values assigned to them,
>  {e.g. Italicized subject word, appropriate underlining, larger font
> for heading, specific font type and size chosen for body of text, color
> of font,[navy, black, blue, or unobtrusive choices entirely plausible
> as a personalization of one's e-mail stationery ]
> *without* changing the text body or sequence of text or syntax at all.

Well, there are thousands proprietary ways to setup a special crypto
system, but this is generally not purpose of this newsgroup as it
depends on personal circumstances and is not applicable in general.

Example: 
The key management for your home is quite different to that for a bank
building with 1000 employees.

>> You cannot disguise an elephant as a mouse.

> this would be more like disguising hidden meaning in the running
> pattern the mouse is using

This means you can only change bits where they are redundant or quasi-
redundant as in color bytes of grahics, e.g.
In ASCII text, there are no redundant bits. You can only insert
whitespace or typos.

>> That's why steganography is in most cases with large binary files.
>>
> and why it would most benefit from a new creative approach

> have not formulated this scheme concretely yet, but seems intuitively
> possible.

> suggestions/criticisms welcome

> vedaal

One suggestion:
Try all your ideas explicitely, for example writing down bytes bit by
bit.
Intuition is good for having ideas, but to proof them you have to show
it explicitely. Mathematics are very helpful to strongly needed.
"Elementary Cryptanalysis" from Abraham Sinkov is good book for beginners
with a weak math background. It treats only out-dated ciphers but that's
the way things start.

 -- avs
  
 Andre van Straaten
 http://www.vanstraatensoft.com

 The signs and the omens are everywhere
 But too few see them - too few even care
 (Lee Clayton - singer/songwriter, 1979)



====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
=======  Over 80,000 Newsgroups = 16 Different Servers! ======

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

From: John Stanford <[EMAIL PROTECTED]>
Subject: AIM Password Encryption
Date: Fri, 22 Dec 2000 21:04:45 GMT

If I go into the Registry and go to the AOL Instant Messenger folder,
there is a password feild.  It has a value that i suppose represents the
password.  Here are some examples:

Password: know
Ciphertext: ˙˙CJOKGHGH

Password: ocean
Ciphertext: ˙˙CNOHGNHBEP

Is this use of a cipher that could be cracked through cryptanalysis, or
is it something else?  Sorry if this is a stupid question, but I'm a
begginer in cryptanalysis.  Thanks in advance.


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

From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Visual Basic Source Code
Date: 22 Dec 2000 21:14:41 +0100

In article <3a437e02$0$36808$[EMAIL PROTECTED]>,
Jason Bock <[EMAIL PROTECTED]> wrote:
 
> Paul Schlyter <[EMAIL PROTECTED]> wrote in message
> news:91v4i9$5r6$[EMAIL PROTECTED]...
>
>> From what you wrote above it appears you have no control over the
>> project even minutes after you left....
> 
> Well, if a customer wants me to work after the agreed-upon deadline is done,
> that's fine.  But when the contract is complete, that's it.  I personally
> don't see a problem with this.
 
So you're saying most of your contracts don't include some guarantee
after the project has been delivered?  Perhaps I should try to get
such contracts too -- it'll probably spare you a lot of trouble if
you take no responsibility whatsoever for the errors you make in your
code which remain undiscovered until delivery....
 
> The average lifetime at a job is very short these days.
 
Then I must be an unusual person: the other week I received a gift from
my employer because I had been employed there for 10 years.....
 
>> Not quite: Java has no pointers for instance.  Pointers is VERY
>> central to both C and C++.  C++ is a C mutation, but Java is a much
>> more different language.  Also in Java arrays are "first-class
>> citizens" but not so in C and C++, where they are implicitly
>> converted to pointers quite often.  Yes, Java's syntax is quite
>> similar to the syntax of C and C++, but its semantics is quite
>> different.  Actually the run-time semantics of Java reminds me quite
>> a lot of the run-time semantics of UCSD Pascal some 20 years ago...
> 
> I know all of this - I programmed in Java for over a year ;).
 
I guess that corresponds to my experience of that language too... :-)
 
> Yes, Java is not exactly like C++.  It's quite different in some
> areas, and very similar in others.  That's why I used the word mutation.
 
Well, the same is valid for most procedural programming languages,
so C++ isn't unique in being "quite different in some areas and very
similar in others" to Java.....
 
>>> My point is that, you can claim that C# is a non-standard language.
>>
>> It's not merely a claim -- it's a fact.
> 
> Right now, yes, it isn't standard.  But the "rumors" abound that it will be,
> eventually.  Those who know MS or are just skeptical by nature wonder if
> this will go through, but so far it does.
 
Time will tell....  there are so many rumours out there.
 
>> There is no document authored
>> by a standards body which describe the C# language.  This fact may of
>> course change in the future, but right now C# is non-standard.  If
>> you want to dispute this fact, please provide the document number
>> and the name of the standardisation body of the C# language.
> 
> You asked:
> 
> <http://msdn.microsoft.com/voices/deepc11272000.asp>
> 
> See the "Standards News" section.
 
OK I'll check that web site later.  However Microsoft is NOT a
standardisation body, even if it attempts to be one...
 
>> There are many "but if it is..." games one can play.  If C# receives
>> an official standard, it will of couse be a standard language - but
>> we're not there today.  Also, if C# becomes a standard language, then
>> MS will lose much of its control over it, and it remains to be seen
>> whether MS will allow this to happen.  Sun didn't want it to happen
>> to Java...
> 
> And yet, Java is still held as the "open, portable language" by many.
> grrrrr....
 
Just like UCSD Pascal in the early 1980'ies.  However Java uses the idea
of portable binary code, and most languages does NOT employ that paradigm.
 
Also, Sun provides a free Java system for several environments, so in
that respect the language is portable.  But of course there's a lot
of hype surrounding this.
 
UCSD Pascal, which also used portable binaries which were to be
interpreted at runtime, failed probably because of bad efficiency.
It'll be interesting to see what will happen to Java in this respect.
However the typical CPU power today is much greater compared to 20
years ago, thus today it's more acceptable to waste CPU cycles.
 
> Well, we're not going to agree on this.  I'm a real programmer; you don't
> think so.  We'll never meet eye-to-eye on this.  Period.
 
Check the Jargon file and see if their definition of "real programmer"
agree with yours....
 
-- 
================================================================
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf dot se   or    paul.schlyter at ausys dot se
WWW:     http://hotel04.ausys.se/pausch    http://welcome.to/pausch

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

From: [EMAIL PROTECTED]
Subject: Re: AIM Password Encryption
Date: Fri, 22 Dec 2000 21:33:42 GMT

In article <[EMAIL PROTECTED]>,
  John Stanford <[EMAIL PROTECTED]> wrote:
> Is this use of a cipher that could be cracked through cryptanalysis,
or
> is it something else?  Sorry if this is a stupid question, but I'm a
> begginer in cryptanalysis.  Thanks in advance.

Theoretically it could be cryptanalyzed. However that would certainly
be the more difficult way to go about it. I assume that password has to
be decrypted, or it is the password equivalent (used in the stead of
the password). Therefore either you already have the correct answer, or
you simply have to reverse engineer the portion of the AIM code that
decrypts the password. I use the term simply because reverse
engineering given full access to an executable, is a much easier
problem than cryptanalysis given no algorithm. Once the algorithm has
been reverse engineered, then cryptanalysis becomes much easier. You
might also consider that it may be simply base-64 encoding or something
similar.
         Joe


Sent via Deja.com
http://www.deja.com/

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


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

Reply via email to