[OT] Encryption

[R. A. Hettinga]

--- begin forwarded text


User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Fri, 02 Jan 2004 21:54:33 +0100
Subject: Re: [OT] Encryption
From: Robert Tito <cassiope at wanadoo.nl>
To: Kyle Moffett <mrmacman_g4 at mac.com>
Cc: Cocoa Development <cocoa-dev at lists.apple.com>,
	Shawn Erickson <shawn at freetimesw.com>
Sender: cocoa-dev-admin at lists.apple.com
List-Id: Discussions regarding native Mac OS X application development
using Cocoa frameworks. <cocoa-dev.lists.apple.com>
List-Post: <mailto:cocoa-dev at lists.apple.com>
List-Help: <mailto:cocoa-dev-request at lists.apple.com?subject=help>
List-Subscribe: <http://www.lists.apple.com/mailman/listinfo/cocoa-dev>,
	<mailto:cocoa-dev-request at lists.apple.com?subject=subscribe>
Status:

On 2-1-2004 21:30, "Kyle Moffett" <mrmacman_g4 at mac.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Jan 02, 2004, at 14:59, Robert Tito wrote:
>
>> On 2-1-2004 20:40, "Kyle Moffett" <mrmacman_g4 at mac.com> wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>
>>> On Jan 02, 2004, at 14:11, Robert Tito wrote:
>>>
>>>> On 2-1-2004 20:08, "Shawn Erickson" <shawn at freetimesw.com> wrote:
>>>>> Can you tell us the name of the product?
>>>>>
>>>>> Note that describing the algorithm used in an encryption technology
>>>>> does not imply one has to open your code up but just describe the
>>>>> ciphers methodology. In absence of that it is hard for anyone to
>>>>> verify
>>>>> the ability of the algorithm.
>>>>>
>>>>> For example RSA's RC5 is described [1] yet not open sourced. It is
>>>>> patented and requires licensing to use.
>>>>>
>>>>> It sounds like you may have had some type of public/government
>>>>> verification that has taken place...?
>>>>>
>>>>> -Shawn
>>>>>
>>>> Its called Salutis.
>>>
>>> Do you have a link or a web-page that describes the product?  Where
>>> might one find more information about said product?  Perhaps a link to
>>> the government classification standard you claim to be meeting,
>>> including the identity of the third-party that verified your
>>> classification
>>> level.
>
> You have not answered this question.  Where exactly is additional
> information on this product?  If you intend to sell it, it would be
> wise to
> provide a link to more information.
>
>
>> This is as far as I can go without infringing out pending patent:
>
> Giving out information is not infringing on a patent, pending or not.
> A patent,
> in fact, requires the publishing of all of the details of the engine
> and encryption
> itself.  There might be company policy regarding the issue, but there
> is no law
> against it.
>
>> It is a timedependent polymorphic polymetric engine that changes an
>> engine
>> (randomy chosen out of 10 with a max of 5 engines per file per segment
>> of
>> 256 byte of that file). The timestamp determines for the decrypting
>> engine
>> and the encrypting engine where to start within the file so the start
>> never
>> is at byte 1 but follow a timedependent sequence along the file
>> filling up
>> empty space with white noise.
>
> This makes very little sense, and seems much like marketing babble.  So
> you
> take a file full of garbage, then stick a timestamp somewhere in there
> that
> when hashed indicates where to start in the file, filling up with data.
> Then
> somehow you encrypt the data using a series of engines.  This is utterly
> useless in terms of determining the security level of the engine.
> OTOH, the
> extreme complexity alone, in combination with the obscurity you appear
> to
> be relying on in the encryption software makes me very suspicious.
>
>> Because the key is actually the file itself we do not use a public
>> key, only
>> a key that has to be generated and that is user AND hardware dependent
>> meaning that a change of hard disk enforces you to get your new
>> encryption
>> key, one you generate yourself on your own machine. Networkcards are
>> included as well as BIOS. That way one can safely (more safe as with
>> Verisign et al) the sender indeed is the person who claims he or she
>> is.
>> Per site there has to be a person responsible for distributing this
>> file
>> that in itself has no meaning for anyone who has not been given
>> privileges
>> by that person or who is outside that domain.
>> Because the file is the key itself there exist an immense timing
>> problem the
>> way we solved that is patent pending.
>> So far we have implemented it on all windows version below 2003
>> But we plan to extend to linux and os x
>
> Please read up on the current uses of encryption in the workplace
> (signing
> documents and such).  Something that relied upon recreating the key
> every
> time you upgraded your hardware would be less than useless.
>
>> The problem being: we need the assembler code for the different
>> processors
>> and the proper way to implement them without too much hardware and OS
>> dependency.
>
> Why assembly?  Assembly is only needed in an OS kernel in a few places,
> and
> for efficiency reasons.  Even then, C and C++ compilers are plenty
> efficient/
>
>> The encryption engines used are all publicly available. So I need not
>> elaborate on these.
>
> Which engines?  If you use publicly available software please indicate
> which.
>
>> It was thought not possible to create a polymorphic polymetrical
>> encryption
>> engine, we have done it. And even included a timedependency within it.
>
> The "polymorphic polymetrical" makes little or no sense.  What are you
> talking
> about?
>
>> An other advantage is when the license expires you can still decrypt
>> older
>> messages but cannot encrypt new ones - contrary to all other PKI/PKC
>> implementations.
>
> This too makes no sense
>
>> I hope this gives some insight
>
> Yes it does, that all of this is marketing babble, and since you seem
> unable to
> provide other good information this seems to be either vaporware or
> snake-oil.
>
> Cheers,
> Kyle Moffett
>
> - -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GCM/CS/IT/U d- s++: a16 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
> L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
> PGP? t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r
> !y?(-)
> - ------END GEEK CODE BLOCK------
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (Darwin)
>
> iD8DBQE/9dT9ag7LSGnFq10RAiezAJ9i0xhv2ilsPdyisjRZHLBpOcTkwwCgliMr
> oNAtJh/N2VGHsBhDuyYUbew=
> =0tLv
> -----END PGP SIGNATURE-----
> _______________________________________________
> cocoa-dev mailing list | cocoa-dev at lists.apple.com
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
>
The site: www.vgz.nl

The engines: AES DES Mars Bluefish Reijndaal to name a few, all standard
engines

Assembly is needed else the synchronisation within the encryotion machine
fails utterly (we use another trick besides standard encryption)
And because we use two and more streams within the encryption phase they
need be fast and in time for the other stream to be able to continue else
the timestamps generated are out of synch.
Nothing sales about that but the implementation of this engine.
The (Dutch) site will send you the english docs when asked for (use contact)

In short I will repond in length to all questions raised, I just have to
compose a decent doc that has all the relevant data and links, dont expect
me to do this at home in the evening.

But any further information regarding the engine remains under "the hood"

I might reveal we tear each byte apart into 4 bits and join from two streams
two 4 bits segments. To start encryption we have a rather scrambled file.
Thats the power of this engine.

Because of all the calculus being done it need be done JIT hence assembly
and no C/C++ (on windoze at least) isnt fast enough: we do support windoze
98-XP, and are working on 2003.

The principle is simple: turn the file in a zipper, take each strand glue
them randomly together (as comparison) then encrypt them for each and every
segment.

Clear enough?






Rob Tito
cassiope at wanadoo.nl
rptito at wanadoo.nl
++31 - (0)621 - 824722
"The changes we wish to see need to come from within us"
M. Gandhi
3Freedom is not worth having if it doesn't include the freedom to make
mistakes2
M. Ghandi
3Friends are dear, cherish them2
R.P. Tito
_______________________________________________
cocoa-dev mailing list | cocoa-dev at lists.apple.com
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com