[Mac_crypto] I would like to shut down Mac-Crypto and Net-Thinkers..
--- begin forwarded text To: [EMAIL PROTECTED], [EMAIL PROTECTED] From: Vinnie Moscaritolo [EMAIL PROTECTED] Subject: [Mac_crypto] I would like to shut down Mac-Crypto and Net-Thinkers.. Sender: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] List-Id: Macintosh Cryptography mac_crypto.vmeng.com List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: http://www.vmeng.com/mailman/listinfo/mac_crypto, mailto:[EMAIL PROTECTED] List-Archive: http://www.vmeng.com/pipermail/mac_crypto/ Date: Wed, 31 Dec 2003 10:42:57 -0800 Status: It's been fun folks, but I am tired of dealing with all the spam that these two lists attract.. maybe someone else can volunteer to run such a list. I say this... when we started the list, I was worried about the mac missing the crypto boat, we have come a long way since then, and we still got a long way to go.. I'll leave the lists around for a few weeks, in case a discussion pops up about moving the list elsewhere.. -- Vinnie Moscaritolo ITCB-IMSH PGP: 3F903472C3AF622D5D918D9BD8B100090B3EF042 --- When the pin is pulled, Mr. Grenade is not our friend. - USMC training bulletin. ___ mac_crypto mailing list [EMAIL PROTECTED] http://www.vmeng.com/mailman/listinfo/mac_crypto --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Bowman Aims at Interoperability Target
http://www.mit-kmi.com/print_article.cfm?DocID=347 - Military Information Technology Bowman Aims at Interoperability Target The British military is beginning battalion field tests of a tactical communications system that will not only bring digitization to all U.K. ground units, but also improve interoperability. By Adam Baddeley The British military was scheduled late this fall to begin battalion field tests of a tactical communications system that would not only bring digitization to all U.K. ground units, but also enable it to interoperate with U.S. forces more closely than ever before. Both countries are now working via a recently signed memorandum of understanding to make their Tactical Internets fully interoperable by first adding the waveform for the British program, known as Bowman, to the U.S. Joint Tactical Radio System (JTRS) waveform library. In addition, officials reportedly are now discussing the sharing of each country's crypto, which is something that has never been done before. Computing Devices Canada-now General Dynamics UK (GD UK)-was awarded the $3 billion Bowman contract in 2001. The solution is an improved version of Canada's IRIS System that includes a fourfold increase in data throughput at the VHF level and the introduction of a wideband networking radio to provide a further data transport backbone. Delays, revisions to the requirement and failures by the British government's original selection for Bowman to satisfy concerns about cost, schedule and integration had led to massive overruns for Bowman's original in service date (ISD) of 1995. GD UK promised the entire solution would be fielded over three years, beginning in March 2004. This will extend, for the first time, digitization to each vehicle and squad throughout the British Army, Marines and Royal Air Force ground units, and mark a major change from the current analog Clansman system. The Bowman ISD is really the significant point. That is when the United Kingdom will have a secure, frequency-hopping communications system, with a fairly complex self-organizing network, capable of fairly large amounts of data throughput, said Larry Johnson, managing director of GD UK. The size of the contract is massive. In terms of deliverables, Bowman covers 41,498 HF and VHF Combat Net Radios; 3,458 High Capacity Data Radios (HCDR); 10,669 Local Area Sub-system (LAS) installations; and 26,498 computers. The equipment will be installed on 133 naval vessels in 20 types, 239 aircraft in four types, 22,832 vehicles covering 181 types, and used by 102,244 trained service personnel. One illustration of the size of the program is the fact that for the Harris RF Communications Division, a $200 million Bowman subcontract for more than 10,000 HF radios was the business unit's largest contract ever, explained Chris Aebli, the company's Bowman program manager. As a follow-on to the Bowman contract, GD UK contracted in 2001 to deliver the ComBAT (Common Battlefield Application Toolset) Infrastructure and Platform (CIP) BISA (Battlefield Information System Application), which although contracted separately, is an integral part of Bowman. This provides the battle management functionality and underlying physical and information architecture for other BISA's to plug into, analogous to the applications that are part of the U.S. Army's Army Battle Command System suite of systems. Trans-Atlantic Development Bowman comprises U.S.-designed radios manufactured in Britain. The primary radio used is the ITT Advanced Digital Radio Plus (ADR+), which in effect is a SINCGARS (Single Channel Ground and Airborne Radio Systems) ASIP (Advanced System Improvement Program) radio modified for U.K. requirements. The SINCGARS ASIP radio, in the hands of U.S. forces today, and the U.K.'s ADR+ represent the core of both countries' Tactical Internets for the foreseeable future and share a common heritage. Although the basic SINCGARS was fielded from the late 1980s, work on the next generation SINCGARS for the United States coincided with the British requirements for the ADR+. Developments made by ITT for one user's needs were used to support requirements on the other side of the Atlantic in a de facto co-evolution throughout the 1990s. Peter Bedwin, managing director of ITT's U.K. unit, explained that his company's work on developing the ADR+ baseline in the areas of Internet compatibility, improved waveforms and Forward Error Correction were brought back over the Atlantic for SINCGARS. British requirements for a much smaller radio led to the half sized ground and airborne SIP SINCGARS for the United States, with both countries' requirements for an improved data capability waveform helping each other's needs. There are important differences, however. The British requirement mandated a U.K. waveform, Pritchell cryptography and an embedded Global Positioning System (GPS). The military GPS systems for Bowman are the Rockwell Collins handheld Precision
Re: Non-repudiation (was RE: The PAIN mnemonic)
At 06:24 PM 12/23/03 -0700, Richard Johnson wrote: ... In my eperience, the terminology has more often been confidentiality, integrity, and authentication. Call it CIA if you need an acronym easy to memorize, if only due to its ironic similarity with that for the name of a certain US government agency. :-) Surely a better government-related TLA for this would be derived from Non-changeability, Secrecy, and Authentication :) Richard --John Kelsey, [EMAIL PROTECTED] PGP: FA48 3237 9AD5 30AC EEDD BBC8 2A80 6948 4CAA F259 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: I don't know PAIN...
At 12:38 PM 12/29/03 -0500, Jerrold Leichter wrote: ... Merkle's knapsack systems (which didn't work out for other reasons) had the property that the public key was computed directly from the private key. (The private key had a special form, while the public key was supposed to look like a random instance of the knapsack problem.) This is the same for discrete log schemes, in general. (Maybe there are some for which it's not the case.) Your private key is x, your public key is g^x mod p. Also for one-time signature schemes and their hash-tree based extensions, which use nothing but a hash function, and for all the variants of the Merkle puzzle schemes I can think of. (Which are public key, but just barely.) ... -- Jerry --John Kelsey, [EMAIL PROTECTED] PGP: FA48 3237 9AD5 30AC EEDD BBC8 2A80 6948 4CAA F259 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: why penny black etc. are not very useful (could crypto stop spam??)
At 17:38 30/12/2003, Perry wrote: In my opinion, the various hashcash-to-stop-spam style schemes are not very useful, because spammers now routinely use automation to break into vast numbers of home computers and use them to send their spam. They're not paying for CPU time or other resources, so they True. But, as Ben noted, the user of the machine could and should care about the resource. Now one may claim that many users don't pay attention to viruses stealing huge amounts of their CPU time. So I agree that the `waste CPU time to pay for sending mail` may have limited effect to stop spam. I also rather dislike the notion of wasting resources to send every e-mail. But where I quite disagree with you is when you say... snip... 1. We need public key authentication of all mail. Well, I'll point out that large integers are cheap and plentiful. Authenticated spam is pretty much as bad as non-Authenticated spam. If we use IMHO, your conclusion is wrong: cryptographic authentication could be a critical tool to stop spam; someone in our community should do this (write the software) already... How? E-mail (at least from new correspondents) must be signed by an `anti-spam mail certification authority (ASMCA)` - often the ISP of the sender. Recipient's mail client (or server) will reject mail (from new correspondents) not certified by a trustworthy ASMCA. If the mail was not rejected but later identified (by end user) as spam, the recipient client/ISP will not only know not to trust the sender's ASMCA, they will also have `proof` that this ASMCA approved (signed) this spam, so they can inform other ASMCA's and mail client/servers. Results: - ASMCA's have strong incentive not to approve spam. They'll use appropriate measures, mainly: filtering tools and punishing spammers (blocking accounts, charging fines, etc.) - End users whose machines were broken into will be notified by their ASMCA (usually ISP), when it detects the spamming by filtering tools or by complaints, and will (1) know there's a problem and take measures to get rid of the spamming trojan horse and (2) maybe be a bit more careful about the machine in the future. Desired side effects: - users will also enjoy e-mail authentication (and confidentiality could be added trivially) - which in particular will make it a bit more difficult for e-mail viruses to propagate. What's the bug in this simple solution? If anybody wants to implement I'm willing to assist in developing/validating the protocols. Best regards, Amir Herzberg Computer Science Department, Bar Ilan University Homepage (and lectures in applied cryptography, secure communication and commerce): http://www.cs.biu.ac.il/~herzbea - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
World's most mysterious book may be a hoax: The Voynich manuscript may be elegant gibberish.
http://www.nature.com/nsu/031215/031215-5.html updated at midnight GMTtoday is thursday, january 1 search nature science update advanced search World's most mysterious book may be a hoax The Voynich manuscript may be elegant gibberish. 17 December 2003 JOHN WHITFIELD Using a Cardan grille the manuscript could have been written in three months. © G. Rugg A strange sixteenth-century book may be cunningly crafted nonsense, says a computer scientist. Gordon Rugg has used the techniques of Elizabethan espionage to recreate the Voynich manuscript, which has stumped code-breakers and linguists for nearly a century1. I've shown that a hoax is a feasible explanation, says Rugg, who works at Keele University, UK. Now it's up to believers in a code to produce evidence to support their ideas. He suspects that English adventurer Edward Kelley produced the Voynich to con Rudolph II, Holy Roman Emperor and collector of antiquities, out of a fortune in gold. The explanation is plausible, but not conclusive, say Voynich scholars. It's an excellent piece of work, says Philip Neal, a former medievalist based in London. I haven't given up hope that the manuscript contains meaning, but this makes it less likely. Page turner The Voynich manuscript is often described as the world's most mysterious book. It is hand-written in a unique alphabet, about 250 pages long, and contains pictures of unrecognizable flowers, naked nymphs and astrological symbols. The manuscript first appeared in the late 1500s, when Rudolph II bought it in Prague from an unknown seller for 600 ducats - about 3.5 kilograms of gold, worth more than US$50,000 today. The book passed from Rudolph to noblemen and scholars, before disappearing in the late 1600s. It surfaced again around 1912, when US book dealer Wilfrid Voynich bought it. The manuscript was donated to Yale University after Voynich's death. No one has worked out whether Voynichese is a code, an idiosyncratic translation of a known tongue, or gibberish. The text contains some features that are not seen in any language. The most common words are often repeated two or three times, for example - the equivalent of English using 'and and and' - giving weight to the hoax theory. On the other hand, some aspects, such as the pattern of word lengths and the ways in which characters and syllables occur with each other, are similar to real languages. Many people have believed that it is too complicated to be a hoax - that it would have taken some mad alchemist years to get such regularity, says Rugg. Table setting But this complexity could have been produced easily, Rugg demonstrates, with an encryption device invented around 1550 called a Cardan grille. This is a table of characters. Moving a piece of card with holes cut in it over the table makes words. Gaps in the table ensure different-length words. Using such grilles on table of Voynichese syllables, Rugg has produced a language with many, although not all, of the manuscript's features. About three months' work would have been enough to produce the entire book, he says. It's an interesting angle, but it's too early to say whether it's correct, says Nick Pelling, a computer programmer based in Surbiton, UK, who also studies cryptography and the Voynich. To prove that the manuscript is a hoax, one would need to produce entire sections using this technique, says Pelling. Tweaking the grilles and tables should make this possible, reckons Rugg. Code book It seems that the Voynich resists deciphering attempts because its author knew enough about codes to make the text plausible yet hard to crack. The book appears to contain cross-referencing, just the kind of thing that cryptographers look for. The characters of Voynichese are also ambiguously written, so it is hard to work out how large the alphabet is, and drawing naked figures makes it impossible to date the text by styles of dress. I haven't given up hope that the manuscript contains meaning Philip Neal, medievalist The chief suspect for producing the book is known to have used Cardan grilles. As well as a cryptographer and inventor of languages, Edward Kelley was a forger, mystic, alchemist, mercenary and wife-swapper. He travelled to Prague to meet with Rudolph in 1584, and may have sold him the manuscript then. Kelley was lost to history after escaping from prison at the end of the sixteenth century. If it's a hoax Kelley is the obvious candidate, says Neal. But he adds that Rudolph bought many alchemical texts that are far cruder forgeries than the Voynich manuscript. Rudolph was easily fooled. If the Voynich was a hoax by Kelley, it looks a bit like overkill, Neal says. References 1. Rugg, G. An elegant hoax? A possible solution to the Voynich manuscript. Cryptologia, (in the press).|Homepage| -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA
Review: Cryptography: A Very Short Introduction,
http://www.newsforge.com/print.pl?sid=04/01/02/1341256 NewsForge The Online Newspaper for Linux and Open Source http://www.newsforge.com/ Title Linux Advisory Watch - January 2, 2004 Date 2004.01.02 8:00 Author warthawg Topic Linux http://www.newsforge.com/article.pl?sid=04/01/02/1341256 This week, advisories were released for xsok, cvs, and proftpd. The distributors include Debian, Gentoo, and Mandrake. One of the best parts of having a profession in information security and IT, is the opportunity to continue learning. To survive, one must constantly stay on top of changing technology. The problem with this is that most of us do not have time to read books, journals, or simply conduct adequate research on the Internet. We are constantly trying to extinguish fires and only gather enough information to do a particular job. Unfortunately, it seems there is never enough time to simply read a little deeper, just to satisfy our own curiosities. Being the new year, many of us have made new year's resolutions. For most of us in IT, this involves learning something new. Perhaps you wish to learn a new programming language, diagramming technique, or wish to build a personal server for a particular function. Many of us have no trouble making personal goals, but following through is a different story. Something that has worked well for me in the past is starting small, and trying to accomplish the smallest tasks first. This will give you the feeling that progress is being made and the momentum will push you through the larger tasks. For example, if you have seven books you wish to read this year, read the smallest one first. For those of you who wish to have a better understanding of cryptography in 2004, I have found the perfect book to get you started. It is, Cryptography: A Very Short Introduction, by Fred Piper and Sean Murphy. This book was published by Oxford press in 2002. Rather than give specific implementation examples, this book focuses on how several modern algorithms work, uses of cryptography, and key management. This book will gives the proper foundation of knowledge necessary to evaluate products and vendor claims. Also, if you are planning a large crypto software development project this year, this book is the perfect primer to other more specific cryptography related books. The book is only 142 pages long and can fit in a shirt pocket. It is well written and easy to read. The book is filled with tables, charts, and examples to explain the concepts. This book should be read by upper management and all others down the chain. It could serve to demystify the purpose and uses of cryptography in any organization. The book can be easily found at Amazon.com for $9.95 USD. Until next time, cheers! Benjamin D. Thomas snip... -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: Meander - from penny black back to TCB protections
On Thu, 1 Jan 2004, Ed Reed wrote: I'm curious, Victor - do you use any functions to verify that the sender's email address is live to insure that a valid reply is possible? No, this is not known to scale well to large sites. Also widespread adoption of sender verification encourages joe-jobbing, for the victim the torrent of spam bounces and abuse complaints are worse than spam (one of my users was getting 1 messages for a while...). A high quality open proxy/open relay RBL combined with a good spam detector (Spam Assasin or a commercial offering) are good enough in practice... A lot of the damage to email infrastructure associated with spam is caused by misguided spam-fighters, rather than spam itself. I am waiting for the law to be enforced, not for CPU waste proofs. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: why penny black etc. are not very useful (could crypto stop spam??)
hi Amir Herzberg wrote: E-mail (at least from new correspondents) must be signed by an `anti-spam mail certification authority (ASMCA)` - often the ISP of the sender. Recipient's mail client (or server) will reject mail (from new correspondents) not certified by a trustworthy ASMCA. ok, but is it a 'web of trust' model [pgp] with many decentralized ASMCAs [or whatever they're called], or a 'pay to play' model where an authority [verisign] decides which mail gets the bits or not. the technology exists, and would work. the problem [as is often the case], comes with the human interface to the technology. i am very skeptical of how much better things would be in a 'pay to play' scenario. we'd just get different kinds of spam without lessening the flow. - ASMCA's have strong incentive not to approve spam. if they can make more money by approving it, they will. i wish it were otherwise. -- \js ! VTABE NAPRV FFGER ATGU - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: why penny black etc. are not very useful (could crypto stop spam??)
On Thu, 1 Jan 2004, Amir Herzberg wrote: IMHO, your conclusion is wrong: cryptographic authentication could be a critical tool to stop spam; someone in our community should do this (write the software) already... How? E-mail (at least from new correspondents) must be signed by an `anti-spam mail certification authority (ASMCA)` - often the ISP of the sender. Recipient's mail client (or server) will reject mail (from new correspondents) not certified by a trustworthy ASMCA. If the mail was not rejected but later identified (by end user) as spam, the recipient client/ISP will not only know not to trust the sender's ASMCA, they will also have `proof` that this ASMCA approved (signed) this spam, so they can inform other ASMCA's and mail client/servers. This is impractical. No such infrastructure will exist. Trust management on the scale your propose is not feasible or desirable. The key feature of email and what makes it the Internet's killer application is that anyone can send email to anyone else. No central authority is needed to vouch for the sender or the content. Again, we do not need to cripple email to stop spam. For my mailbox, of the 1000 spam messages a month that get past the RBL, 925 are caught by the spam filter. I am left with 2-3 spam messages a day, why again do we need to cripple the most important application on the Internet? -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [OT] Encryption
--- begin forwarded text User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 02 Jan 2004 21:08:21 +0100 Subject: Re: [OT] Encryption From: Robert Tito [EMAIL PROTECTED] To: Kyle Moffett [EMAIL PROTECTED] Cc: Cocoa Development [EMAIL PROTECTED], Shawn Erickson [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] List-Id: Discussions regarding native Mac OS X application development using Cocoa frameworks. cocoa-dev.lists.apple.com List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: http://www.lists.apple.com/mailman/listinfo/cocoa-dev, mailto:[EMAIL PROTECTED] Status: On 2-1-2004 20:40, Kyle Moffett [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. Please note that I do not want your assembly or C++ code, nor do I even want pseudo-code, though pseudo-code is acceptable if you want to provide it, it's just a little harder to read. All I was asking for was the mathematical procedure(s) you use for encryption. All of the cryptographic experts that I know tell me that anyone who will not provide a description of their encryption system for anyone who asks is just selling snake-oil in the form of a cryptographic application. 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/9ckRag7LSGnFq10RAuIqAKCXliVlmwSwhTJSgwpPFu5r3wYHYgCeIoQN tBWdVOrryJmWNg/qXERBqLA= =fKQw -END PGP SIGNATURE- ___ cocoa-dev mailing list | [EMAIL PROTECTED] 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 information is available at www.vgz.nl, when you use contact an english version and additional information can and will be sent, so far we have just put up a Dutch site as we are a Dutch company working for the Dutch department of justice and Department of Finance and the police. But the FBI and NSA and CIA have tried to crack our solutuion (meaning the encrypted file) but they failed. Because once the encryption starts it is impossible to provide a backdoor the solution is pretty safe. And not very welcomed by those US services: it provides absolute level 4 secrecy. Rob Tito [EMAIL PROTECTED] [EMAIL PROTECTED] ++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 | [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: [OT] Encryption
--- begin forwarded text User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 02 Jan 2004 20:59:14 +0100 Subject: Re: [OT] Encryption From: Robert Tito [EMAIL PROTECTED] To: Kyle Moffett [EMAIL PROTECTED] Cc: Cocoa Development [EMAIL PROTECTED], Shawn Erickson [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] List-Id: Discussions regarding native Mac OS X application development using Cocoa frameworks. cocoa-dev.lists.apple.com List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: http://www.lists.apple.com/mailman/listinfo/cocoa-dev, mailto:[EMAIL PROTECTED] Status: On 2-1-2004 20:40, Kyle Moffett [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. Please note that I do not want your assembly or C++ code, nor do I even want pseudo-code, though pseudo-code is acceptable if you want to provide it, it's just a little harder to read. All I was asking for was the mathematical procedure(s) you use for encryption. All of the cryptographic experts that I know tell me that anyone who will not provide a description of their encryption system for anyone who asks is just selling snake-oil in the form of a cryptographic application. 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/9ckRag7LSGnFq10RAuIqAKCXliVlmwSwhTJSgwpPFu5r3wYHYgCeIoQN tBWdVOrryJmWNg/qXERBqLA= =fKQw -END PGP SIGNATURE- This is as far as I can go without infringing out pending patent: 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. 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 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. The encryption engines used are all publicly available. So I need not elaborate on these. It was thought not possible to create a polymorphic polymetrical encryption engine, we have done it. And even included a timedependency within it. 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. I hope this gives some insight regards Rob Tito [EMAIL PROTECTED] [EMAIL PROTECTED] ++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 | [EMAIL PROTECTED] Help/Unsubscribe/Archives:
Re: [OT] Encryption
--- begin forwarded text Cc: Cocoa Development [EMAIL PROTECTED], Shawn Erickson [EMAIL PROTECTED] From: Kyle Moffett [EMAIL PROTECTED] Subject: Re: [OT] Encryption Date: Fri, 2 Jan 2004 15:30:53 -0500 To: Robert Tito [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] List-Id: Discussions regarding native Mac OS X application development using Cocoa frameworks. cocoa-dev.lists.apple.com List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: http://www.lists.apple.com/mailman/listinfo/cocoa-dev, mailto:[EMAIL PROTECTED] Status: On Jan 02, 2004, at 14:59, Robert Tito wrote: On 2-1-2004 20:40, Kyle Moffett [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: [OT] Encryption
--- begin forwarded text Cc: Cocoa Development [EMAIL PROTECTED], Kyle Moffett [EMAIL PROTECTED], Shawn Erickson [EMAIL PROTECTED] From: Sherm Pendley [EMAIL PROTECTED] Subject: Re: [OT] Encryption Date: Fri, 2 Jan 2004 16:20:50 -0500 To: Robert Tito [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] List-Id: Discussions regarding native Mac OS X application development using Cocoa frameworks. cocoa-dev.lists.apple.com List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: http://www.lists.apple.com/mailman/listinfo/cocoa-dev, mailto:[EMAIL PROTECTED] Status: On Jan 2, 2004, at 3:08 PM, Robert Tito wrote: But the FBI and NSA and CIA have tried to crack our solutuion (meaning the encrypted file) but they failed. How do you know they failed? If they succeeded, they wouldn't tell you about it. One of the basic tenets of applied cryptology is that cracking a code is only useful until your target becomes aware that his code has been cracked. At that point, he will either switch codes, or start feeding you misinformation with the code that's been compromised. Frankly my friend, you're losing credibility with each post you make. Not only do your technical explanations make no sense, you don't seem to have much of a grasp on how encryption is used in the real world. sherm-- ___ cocoa-dev mailing list | [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: [OT] Encryption
--- begin forwarded text Date: Fri, 2 Jan 2004 16:50:44 -0500 To: Robert Tito [EMAIL PROTECTED], Sherm Pendley [EMAIL PROTECTED] From: R. A. Hettinga [EMAIL PROTECTED] Subject: Re: [OT] Encryption Cc: Cocoa Development [EMAIL PROTECTED], Kyle Moffett [EMAIL PROTECTED], Shawn Erickson [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] List-Id: Discussions regarding native Mac OS X application development using Cocoa frameworks. cocoa-dev.lists.apple.com List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: http://www.lists.apple.com/mailman/listinfo/cocoa-dev, mailto:[EMAIL PROTECTED] Status: At 10:37 PM +0100 1/2/04, Robert Tito wrote: We know, because they wouldnt give us a clearance for the us if we didnt include a backdoor Game. Set. And match. Thank you for playing... Someone throw some sand down on the floor before someone slips and falls, RAH -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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' ___ cocoa-dev mailing list | [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
