Now that we all seem to be connected via SocNet, everyone is pouring their hearts out online about the frustrating process of auditioning for voiceover work. For years, I used to share the feeling until one day, in 2003, I turned a corner on the whole matter. Since then my Audition Conversion Metric (ACM) has tripled, and I also get way more FIGs (Found-Gigs, where they just called and booked without any audition) than I used to.
What happened on that fateful summer day in 2003? I made these three changes of attitude:
1) I decided that NONE of this business is about me!
Instead, I began to look at myself as a highly-trained professional capable of doing whatever it is the producer or writer is asking without balking, flinching, wincing, or whining. In the case of auditions, the written direction and the direction from your agent(or room producer), are the only things you have to go by and you must trust them completely.
2) I treat each audition as seriously as I treat a regular VO job.
I discovered that it helps dramatically if you can get as much "back story" about the company: their market share, their quarterly earnings, their product/service pipeline, their weaknesses, strengths, competition, and so forth, as possible.
Then, do your best to distill that data into a nice thesis by which you can translate the direction provided by the writer. Everything you can learn will ultimately help you be the race-horse that can win it for the company and help them achieve their ad campaign objectives. This approach is very powerful, and it can be heard and felt in your audition performance.
3) Do not, under any circumstances, look back at the audition once it leaves your lips or your studio.
Stop wondering or worrying about whether you'll get the job. The old adage here is really very true: A watched pot never boils. Simply put, you approached the audition with selfless confidence, an abundance of knowledge, and an ever-improving skillset, and you did the absolute best job you could do. Now, forget about it, and move on to the next audition.
I truly believe that if you shed the typical ironic duality of narcissism/insecurity we as actors seem to drag around with us, you will discover who you really are behind the mic. It will shine through, and your ACM and FIG numbers will climb sky-high.
Thursday, December 17, 2009
Saturday, July 12, 2008
MCC Algorithm performance results
Performance results of the MCC algorithm have been approximately as I expected. Since MCC is a block cipher, it should be expected to perform competitively against AES. I recently ran just over a half-million benchmark tests on Perl implementations of both MCC and AES on a dual/dual machine. With very short plaintext messages under 50 characters, AES was only 4.2 ms faster than MCC. On a message of just over 6,000 characters, AES was only 1.4 ms faster than MCC. And working on a 32kB message, MCC was 10.3 ms faster than AES. MCC's speed on longer messages results from its ability to process the entire message as a single block.
Friday, February 29, 2008
The MCC Algorithm - author bio
The MCC Algorithm is the creation of Richard Ervasti, Cofounder and CTO of MCC Security LLC, and was first published on February 27, 2008.
In the early days, the company’s name was Quty, LLC, and its core business was an internet auction service for nonprofit organizations. When the time came in 2005 to tighten the security of users’ personal information on Quty’s servers, Ervasti began to scrutinize the various available encryption modules, and found them lacking. As he put it, “There are a handful of wonderfully robust solutions out there, but none of them have been able to properly address the inevitable explosive growth in computer resources and its profound impact on data security over the next 30 to 40 years.”
The solution, Ervasti felt, was to create an algorithm that might offer some realistic hope of thwarting present and future attacks by exponentially raising the level of complexity for adversaries.
MCC’s inspiration comes from the field of audio recording. With 25 years of audio engineering experience, Ervasti chose to use signal processing techniques as the starting point for his new algorithm. As a result, he concluded that multiple inputs, or channels, of data would be required in order to sufficiently raise the level of the program’s complexity without sacrificing performance.
Initial code for the algorithm was terribly bloated at over 80 times its present size. Processing was sluggish and the number of functions was quite unwieldy. “So, I completed my transformation to the dark side”, Ervasti explained, “by adding some classic confusion and diffusion methods which alone are trivial to crack, but when blended in with the rest of the Cursor functions, they help to cut the code size dramatically and improve on the mysterious S box schemes I envisioned.”
Naturally, the jury is still out on MCC until the cryptographic community can get its hands on it and try to break Ervasti’s little monster. But he remains confident it will withstand a majority of the analytical scrutiny. “The instant I had a stable version,” he states with a smile, “I deployed it on several machines, and fortunately it is still in active production to this day.” He hopes it can stay that way for decades to come.
In the early days, the company’s name was Quty, LLC, and its core business was an internet auction service for nonprofit organizations. When the time came in 2005 to tighten the security of users’ personal information on Quty’s servers, Ervasti began to scrutinize the various available encryption modules, and found them lacking. As he put it, “There are a handful of wonderfully robust solutions out there, but none of them have been able to properly address the inevitable explosive growth in computer resources and its profound impact on data security over the next 30 to 40 years.”
The solution, Ervasti felt, was to create an algorithm that might offer some realistic hope of thwarting present and future attacks by exponentially raising the level of complexity for adversaries.
MCC’s inspiration comes from the field of audio recording. With 25 years of audio engineering experience, Ervasti chose to use signal processing techniques as the starting point for his new algorithm. As a result, he concluded that multiple inputs, or channels, of data would be required in order to sufficiently raise the level of the program’s complexity without sacrificing performance.
Initial code for the algorithm was terribly bloated at over 80 times its present size. Processing was sluggish and the number of functions was quite unwieldy. “So, I completed my transformation to the dark side”, Ervasti explained, “by adding some classic confusion and diffusion methods which alone are trivial to crack, but when blended in with the rest of the Cursor functions, they help to cut the code size dramatically and improve on the mysterious S box schemes I envisioned.”
Naturally, the jury is still out on MCC until the cryptographic community can get its hands on it and try to break Ervasti’s little monster. But he remains confident it will withstand a majority of the analytical scrutiny. “The instant I had a stable version,” he states with a smile, “I deployed it on several machines, and fortunately it is still in active production to this day.” He hopes it can stay that way for decades to come.
The MCC Algorithm - executive summary
I believe faster and more efficient computer resources coupled with inevitable advances in factorization techniques are likely to make insufficient the continued linear use of large primes for creating strong encryption keys, particularly for long-term implementations.
So, I got busy back in 2005 and wrote a new, unpatented, freely available, complete, and highly portable encryption algorithm, Multiple Channel Cryptography (MCC), that may offer an exponential and sustainable advance in the development of cryptographic systems. The term “multiple channel” refers to the algorithm’s multiple configuration inputs. The MCC framework calls for a block-cipher-style non-linear utilization of 5 inputs (the channels). Pieces of each channel can be utilized within the keyspace, or to manipulate the keyspace or the message, or both, as it processes the input signal.
Consequently, the challenge then for adversaries is to discover the target's inputs to the algorithm. Unlike block ciphers, MCC encryption does not require fixed key size or message size. In fact, MCC does not use a key in the classic cryptographic sense. MCC key pairs are a mathematical representation of the algorithm’s required inputs.
The internal formulae of the central algorithm are such that various classic mathematically-based and pattern-based attack methods might be less likely to provide adversaries sufficient advantage to justify their utilization in the discovery process and attackers would then resort to plain brute-force discovery attempts.
In a typical installation, sysadmins can then have, in one MCC class, any necessary number of concurrent independent inherited classes such that adversaries will be incapable of succeeding at a brute-force or even shortcut birthday attack to discover one or more instantiations of any target class.
It'll probably take years for the crypto community to kick the tires on MCC ecryption and bless it (or not). So, to get the ball rolling, I have created a PDF file of the MCC white paper and placed it here for downloading.
So, I got busy back in 2005 and wrote a new, unpatented, freely available, complete, and highly portable encryption algorithm, Multiple Channel Cryptography (MCC), that may offer an exponential and sustainable advance in the development of cryptographic systems. The term “multiple channel” refers to the algorithm’s multiple configuration inputs. The MCC framework calls for a block-cipher-style non-linear utilization of 5 inputs (the channels). Pieces of each channel can be utilized within the keyspace, or to manipulate the keyspace or the message, or both, as it processes the input signal.
Consequently, the challenge then for adversaries is to discover the target's inputs to the algorithm. Unlike block ciphers, MCC encryption does not require fixed key size or message size. In fact, MCC does not use a key in the classic cryptographic sense. MCC key pairs are a mathematical representation of the algorithm’s required inputs.
The internal formulae of the central algorithm are such that various classic mathematically-based and pattern-based attack methods might be less likely to provide adversaries sufficient advantage to justify their utilization in the discovery process and attackers would then resort to plain brute-force discovery attempts.
In a typical installation, sysadmins can then have, in one MCC class, any necessary number of concurrent independent inherited classes such that adversaries will be incapable of succeeding at a brute-force or even shortcut birthday attack to discover one or more instantiations of any target class.
It'll probably take years for the crypto community to kick the tires on MCC ecryption and bless it (or not). So, to get the ball rolling, I have created a PDF file of the MCC white paper and placed it here for downloading.
Subscribe to:
Posts (Atom)
Posts
