Encryption *As Recorded* can anyone give me a clue?

[dE|_]

Can anyone give me a lead for this;

As the audio comes in to drive, the stream itself needs to be encrypted to
be made tamper-proof, not just read-only. If anyone does as much as change a
meta value or cut a sample, it must ring alarm bells. (It's a
security/evidence thing)

I'm not getting far on google with this, have you been here before?

--
dE|_

[Scott Dorsey]

dE|_ > wrote:
>Can anyone give me a lead for this;
>
>As the audio comes in to drive, the stream itself needs to be encrypted to
>be made tamper-proof, not just read-only. If anyone does as much as change a
>meta value or cut a sample, it must ring alarm bells. (It's a
>security/evidence thing)
>
>I'm not getting far on google with this, have you been here before?

There's really no completely tamperproof solution. Checksums are a reasonable
notion, but may not stand up in court. Ask an evidence attorney.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[John Williamson]

Scott Dorsey wrote:
> dE|_ > wrote:
>> Can anyone give me a lead for this;
>>
>> As the audio comes in to drive, the stream itself needs to be encrypted to
>> be made tamper-proof, not just read-only. If anyone does as much as change a
>> meta value or cut a sample, it must ring alarm bells. (It's a
>> security/evidence thing)
>>
>> I'm not getting far on google with this, have you been here before?
>
> There's really no completely tamperproof solution. Checksums are a reasonable
> notion, but may not stand up in court. Ask an evidence attorney.
>
Might a pair of analogue security copies, made on a verified machine in
parallel with the digital working copy, then immediately placed in a
sealed package, stand up in court?

It worked in the opposite direction on the Watergate tapes, and the
British police use a similar system for both audio and video records of
interviews.

--
Tciao for Now!

John.

[dE|_]

"Scott Dorsey" wrote:
>>Can anyone give me a lead for this;
>>
>>As the audio comes in to drive, the stream itself needs to be encrypted to
>>be made tamper-proof, not just read-only. If anyone does as much as change
>>a
>>meta value or cut a sample, it must ring alarm bells. (It's a
>>security/evidence thing)
>>
>>I'm not getting far on google with this, have you been here before?
>
> There's really no completely tamperproof solution. Checksums are a
> reasonable
> notion, but may not stand up in court. Ask an evidence attorney.

Thanks for that. Until a friend suggested stream encryption, which I don't
really understand, my initial thought was to run a constant stream of tiny
signature blibs into all recordings. A bit old fashioned.

--
dE|_

[dE|_]

"John Williamson" wrote:
>>> Can anyone give me a lead for this;
>>>
>>> As the audio comes in to drive, the stream itself needs to be encrypted
>>> to be made tamper-proof, not just read-only. If anyone does as much as
>>> change a meta value or cut a sample, it must ring alarm bells. (It's a
>>> security/evidence thing)
>>>
>>> I'm not getting far on google with this, have you been here before?
>>
>> There's really no completely tamperproof solution. Checksums are a
>> reasonable
>> notion, but may not stand up in court. Ask an evidence attorney.
>>
> Might a pair of analogue security copies, made on a verified machine in
> parallel with the digital working copy, then immediately placed in a
> sealed package, stand up in court?
>
> It worked in the opposite direction on the Watergate tapes, and the
> British police use a similar system for both audio and video records of
> interviews.

Good point, back to solid analogue. I'll put that on the paper for when we
talk and I think my best tool is going to bring the attorney along.

--
dE|_

[Scott Dorsey]

dE|_ > wrote:
>"Scott Dorsey" wrote:
>>>Can anyone give me a lead for this;
>>>
>>>As the audio comes in to drive, the stream itself needs to be encrypted to
>>>be made tamper-proof, not just read-only. If anyone does as much as change
>>>a
>>>meta value or cut a sample, it must ring alarm bells. (It's a
>>>security/evidence thing)
>>>
>>>I'm not getting far on google with this, have you been here before?
>>
>> There's really no completely tamperproof solution. Checksums are a
>> reasonable
>> notion, but may not stand up in court. Ask an evidence attorney.
>
>Thanks for that. Until a friend suggested stream encryption, which I don't
>really understand, my initial thought was to run a constant stream of tiny
>signature blibs into all recordings. A bit old fashioned.

That's called watermarking. There are some ways it can be used to prove
source, but it's not effective against proving lack of tampering.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[dE|_]

"Scott Dorsey" wrote:
>>>>Can anyone give me a lead for this;
>>>>
>>>>As the audio comes in to drive, the stream itself needs to be encrypted
>>>>to
>>>>be made tamper-proof, not just read-only. If anyone does as much as
>>>>change
>>>>a
>>>>meta value or cut a sample, it must ring alarm bells. (It's a
>>>>security/evidence thing)
>>>>
>>>>I'm not getting far on google with this, have you been here before?
>>>
>>> There's really no completely tamperproof solution. Checksums are a
>>> reasonable
>>> notion, but may not stand up in court. Ask an evidence attorney.
>>
>>Thanks for that. Until a friend suggested stream encryption, which I don't
>>really understand, my initial thought was to run a constant stream of tiny
>>signature blibs into all recordings. A bit old fashioned.
>
> That's called watermarking. There are some ways it can be used to prove
> source, but it's not effective against proving lack of tampering.

A more cut/fade tamper resistant method of watermarking might be to record
through a slow flanger. Any interruptions would stick out like a sore thumb
then surely? I still like John's idea of parallel analogue tapes, these can
be compared to the flanging & checksummed digital media and be used in
court.

?

--
dE|_

[Richard Crowley]

"dE|_" wrote ...
> A more cut/fade tamper resistant method of watermarking might be to record
> through a slow flanger. Any interruptions would stick out like a sore
> thumb then surely? I still like John's idea of parallel analogue tapes,
> these can be compared to the flanging & checksummed digital media and be
> used in court.

Mechanical (not magnetic) recordings like those old dictation machine loops
were once considered pretty tamper-proof. But not practical these days. I
would consider running a flash recorder and immediately handing the SD card
(or whatever) to the attorney to seal as evidence before leaving the room.

I'm confident that spending some quality time with Google would reveal
what are considered legally acceptable forms of recording these days.
Seems quite likely that any DIY, home-made scheme would never be
deemed admissible.

[Les Cargill[_2_]]

dE|_ wrote:
> Can anyone give me a lead for this;
>
> As the audio comes in to drive, the stream itself needs to be encrypted to
> be made tamper-proof, not just read-only. If anyone does as much as change a
> meta value or cut a sample, it must ring alarm bells. (It's a
> security/evidence thing)
>
> I'm not getting far on google with this, have you been here before?
>
> --
> dE|_
>
>

Ironkey USB sticks are alleged to be secure. Ask them if they offer a
harddisk equivalent. I really think that a secure escrow is a better
strategy...

--
Les Cargill

[Mark]

On Oct 30, 7:55*pm, Les Cargill > wrote:
> dE|_ wrote:
> > Can anyone give me a lead for this;
>
> > As the audio comes in to drive, the stream itself needs to be encrypted to
> > be made tamper-proof, not just read-only. If anyone does as much as change a
> > meta value or cut a sample, it must ring alarm bells. (It's a
> > security/evidence thing)
>
> > I'm not getting far on google with this, have you been here before?
>
> > --
> > dE|_
>
> Ironkey USB sticks are alleged to be secure. Ask them if they offer a
> harddisk equivalent. I really think that a secure escrow is a better
> strategy...
>
> --
> Les Cargill

record the interview on video with a TV set on in the background with
the national 7PM network news on the TV...

Mark

[Richard Crowley]

"dE|_" wrote ...
> Can anyone give me a lead for this; As the audio comes in to drive, the
> stream itself needs to be encrypted to be made tamper-proof,

Encryption does NOT imply "tamper-proof".

> not just read-only. If anyone does as much as change a meta value or cut a
> sample, it must ring alarm bells. (It's a security/evidence thing)

You don't need encryption to detect changes. A simple (or
complex if you wish) checksum will do that.

> I'm not getting far on google with this, have you been here before?

You are going in with a faulty assumption. Google is probably
confirming that it isn't a viable solution.

[soundhaspriority]

"dE|_" > wrote in message
...
> Can anyone give me a lead for this;
>
> As the audio comes in to drive, the stream itself needs to be encrypted to
> be made tamper-proof, not just read-only. If anyone does as much as change
> a meta value or cut a sample, it must ring alarm bells. (It's a
> security/evidence thing)
>
> I'm not getting far on google with this, have you been here before?
>
> --
> dE|_
The courts are not leading edge as far as technology is concerned. It is
established by lengthy precedent. Even if something like this did exist, it
would just instigate a battle of expert witnesses. By contrast, certain
forms of technology are admissible, having become part of common law. An
example of this is the taking of depositions via video conferencing.
Attorneys from both sides must be present, and the operator of the equipment
must be approved by the court.

In an actual trial, even words in the courtroom are not admissible unless
they have been taken down by an official court reporter. The reporter has a
little audio recorder, but only for his own use, to double check. He
frequently interrupts to ask for clarification of words just spoken. What he
takes down then becomes the official transcript of the trial. The trial
recordings are never used.

So, as you can see, admissible evidence is not an issue of technology. It
has been established over many centuries. It varies according to the type of
evidence. If the evidence is testimony, but, say, collected from a crime
scene, the issue would be to establish a chain of custody of the evidence
encompassing the time it was collected, the storage of the evidence under
lock and key (and who possessed the key), and who accessed it before it was
presented to the court.

Bob Morein
(310) 237-6511

[Peter Larsen[_3_]]

Richard Crowley wrote:

> "dE|_" wrote ...
>> Can anyone give me a lead for this; As the audio comes in to drive,
>> the stream itself needs to be encrypted to be made tamper-proof,

> Encryption does NOT imply "tamper-proof".

More like acccess-proof if not authorized.

I use instant ftp-upload of security cam images on a site, I support since
it is better that the images of the burglars are somewhere else than at the
site burgled. It is simple and it is cheap. Some of the time I think that
the largest risk with encryption is loss of authorized access if something
goes really wrong ...

>> not just read-only. If anyone does as much as change a meta value or
>> cut a sample, it must ring alarm bells. (It's a security/evidence
>> thing)

> You don't need encryption to detect changes. A simple (or
> complex if you wish) checksum will do that.

I would have thought that windows auditing - and if relevant file system
encryption - had deccent mileage, it would then be about protecting the
event-log from tampering. And of course from preventing physical acess to
the media. FTP upload to a suitable location has the neatness of putting it
directly on physical media inside a presumed reasonably safe server-center.

>> I'm not getting far on google with this, have you been here before?

> You are going in with a faulty assumption. Google is probably
> confirming that it isn't a viable solution.

Quite possibly rather "not quite the problem" as pr. your suggestion.
Anyway, one probably should ask an audio forensics consultant about
acceptable strategies, they're the ones in the know.

Kind regards

Peter Larsen

[dE|_]

"Peter Larsen" say:

> Richard Crowley wrote:
>
>> "dE|_" wrote ...
>>> Can anyone give me a lead for this; As the audio comes in to drive,
>>> the stream itself needs to be encrypted to be made tamper-proof,
>
>> Encryption does NOT imply "tamper-proof".
>
> More like acccess-proof if not authorized.
>
> I use instant ftp-upload of security cam images on a site, I support since
> it is better that the images of the burglars are somewhere else than at
> the site burgled. It is simple and it is cheap. Some of the time I think
> that the largest risk with encryption is loss of authorized access if
> something goes really wrong ...
>
>>> not just read-only. If anyone does as much as change a meta value or
>>> cut a sample, it must ring alarm bells. (It's a security/evidence
>>> thing)
>
>> You don't need encryption to detect changes. A simple (or
>> complex if you wish) checksum will do that.
>
> I would have thought that windows auditing - and if relevant file system
> encryption - had deccent mileage, it would then be about protecting the
> event-log from tampering. And of course from preventing physical acess to
> the media. FTP upload to a suitable location has the neatness of putting
> it directly on physical media inside a presumed reasonably safe
> server-center.

Live internet streaming to a supreme 3rd Party, only they have access to the
server. Now there's an idea.

Trouble with this one is it's not just for planned interviews, it's 24/7
recording of all radio communication. There'd have to be some kind of
over-writing method after a couple of days or you'd run out of disk space
pretty quick.

--
dE|_

[dE|_]

"DougD" wrote:
>
>>Live internet streaming to a supreme 3rd Party, only they have access to
>>the
>>server. Now there's an idea.
>>
>>Trouble with this one is it's not just for planned interviews, it's 24/7
>>recording of all radio communication. There'd have to be some kind of
>>over-writing method after a couple of days or you'd run out of disk space
>>pretty quick.
>>
>
> There's a company up here in Canada called HaiVision. They market
> video/audio streaming and compression systems geared towards
> secured govt. applications, universities, hospitals, as well as plain
> old set top boxes. One of the methods that they provide for their
> secured streaming is not only encryption, but also that until a secure
> user makes a request for the data, there is no perm. play app on
> the playback machine. The playback app is sent as part of the data
> stream, and has encoding/decrypt info that is encoded particular to
> that one event, and the particular decoder app. As soon as playback
> has stopped, the application wipes itself and since there is no local
> caching on the play machine, no chance to manipulate the data.
> I'm only covering the basics, and probably am not giving a very
> accurate overview, so I'd go read their info yourself.. They do seem
> to have gotten the blessings of the USG for secure video conferencing,
> so they at least have their foot in the door on that. They also have an
> office/plant in Chicago. It does seem to be a pretty good method of
> providing secure streams, and it does have real time logging of users,
> what was watched and by "whom", and as well multiple paths as to
> how data is distributed and even what levels of compression can be
> applied or not depending on client needs or bandwith limits, on a
> user by user basis. We are getting their encoding hardware put in
> here in Victoria as part of our underwater Neptune research system,
> where they will be encoding both SD and HD streams of the live
> HD underwater video to go over our edu nets within the province
> and country.
> And of course, this is not an endorsment, and I have no association
> with this company..

A new codec with each stream, that's cool. Whether that would be applicable
here I'm not sure, but I'll keep it in mind.

--
dE|_

[DougD]

In article >, "dE|_" > wrote:

>Live internet streaming to a supreme 3rd Party, only they have access to the
>server. Now there's an idea.
>
>Trouble with this one is it's not just for planned interviews, it's 24/7
>recording of all radio communication. There'd have to be some kind of
>over-writing method after a couple of days or you'd run out of disk space
>pretty quick.
>

There's a company up here in Canada called HaiVision. They market
video/audio streaming and compression systems geared towards
secured govt. applications, universities, hospitals, as well as plain
old set top boxes. One of the methods that they provide for their
secured streaming is not only encryption, but also that until a secure
user makes a request for the data, there is no perm. play app on
the playback machine. The playback app is sent as part of the data
stream, and has encoding/decrypt info that is encoded particular to
that one event, and the particular decoder app. As soon as playback
has stopped, the application wipes itself and since there is no local
caching on the play machine, no chance to manipulate the data.
I'm only covering the basics, and probably am not giving a very
accurate overview, so I'd go read their info yourself.. They do seem
to have gotten the blessings of the USG for secure video conferencing,
so they at least have their foot in the door on that. They also have an
office/plant in Chicago. It does seem to be a pretty good method of
providing secure streams, and it does have real time logging of users,
what was watched and by "whom", and as well multiple paths as to
how data is distributed and even what levels of compression can be
applied or not depending on client needs or bandwith limits, on a
user by user basis. We are getting their encoding hardware put in
here in Victoria as part of our underwater Neptune research system,
where they will be encoding both SD and HD streams of the live
HD underwater video to go over our edu nets within the province
and country.
And of course, this is not an endorsment, and I have no association
with this company..

d.

[hank alrich]

dE|_ > wrote:

> Live internet streaming to a supreme 3rd Party, only they have access to the
> server. Now there's an idea.
>
> Trouble with this one is it's not just for planned interviews, it's 24/7
> recording of all radio communication. There'd have to be some kind of
> over-writing method after a couple of days or you'd run out of disk space
> pretty quick.

How many channels of radio to be tracked?

--
ha
shut up and play your guitar

[dE|_]

"hank alrich" > wrote in message
...
> dE|_ > wrote:
>
>> Live internet streaming to a supreme 3rd Party, only they have access to
>> the
>> server. Now there's an idea.
>>
>> Trouble with this one is it's not just for planned interviews, it's 24/7
>> recording of all radio communication. There'd have to be some kind of
>> over-writing method after a couple of days or you'd run out of disk space
>> pretty quick.
>
> How many channels of radio to be tracked?

Dunno, not got the job yet. Check this out, I reckon this will be the
recording medium of choice;
http://www.cedaraudio.com/products/cambridge/forensic.html
This can record 8 simultaneous.

I've emailed them a query as to whether this can be set to 24/7 'standby'
and have network recording triggered by the start of radio transmission.

--
dE|_

[Scott Dorsey]

hank alrich > wrote:
>dE|_ > wrote:
>
>> Live internet streaming to a supreme 3rd Party, only they have access to the
>> server. Now there's an idea.
>>
>> Trouble with this one is it's not just for planned interviews, it's 24/7
>> recording of all radio communication. There'd have to be some kind of
>> over-writing method after a couple of days or you'd run out of disk space
>> pretty quick.
>
>How many channels of radio to be tracked?

The radio or other verification signal HAS to be mixed in with the main
track, so there's no way it can be separated out.

Turns out AC power line hum is actually pretty good for this, because the
hum frequency changes slightly but measurably, and there are existing
databases of the frequency error.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Anahata]

On Sat, 31 Oct 2009 15:26:13 +0000, dE|_ wrote:

> Dunno, not got the job yet. Check this out, I reckon this will be the
> recording medium of choice;
> http://www.cedaraudio.com/products/cambridge/forensic.html This can
> record 8 simultaneous.

The application of Cedar equipment to surveillance and forensic work is
typically for stuff recorded with mics in suboptimal concealed positions
where noise removal is needed to make recorded speech intelligible. It
doesn't seem to have any tamper-proofing features, which is what I
thought you wanted.

They make a selling point of ease of editing and manipulation of the
recorded audio - surely the exact opposite of what you want.

--
Anahata
-+- http://www.treewind.co.uk
Home: 01638 720444 Mob: 07976 263827

[dE|_]

"Anahata" > wrote in message
o.uk...
> On Sat, 31 Oct 2009 15:26:13 +0000, dE|_ wrote:
>
>> Dunno, not got the job yet. Check this out, I reckon this will be the
>> recording medium of choice;
>> http://www.cedaraudio.com/products/cambridge/forensic.html This can
>> record 8 simultaneous.
>
> The application of Cedar equipment to surveillance and forensic work is
> typically for stuff recorded with mics in suboptimal concealed positions
> where noise removal is needed to make recorded speech intelligible. It
> doesn't seem to have any tamper-proofing features, which is what I
> thought you wanted.
>
> They make a selling point of ease of editing and manipulation of the
> recorded audio - surely the exact opposite of what you want.

I have been given a good lead to tamper-proofing equipment now, with a
better keyword to search for, but the ultimate line of thought was to ftp
copies of the radio recordings straight to a 3rd party secure database as
recorded.

Doing more research today.

--
dE|_

[Swanny[_2_]]

dE|_ wrote:
> Can anyone give me a lead for this;
>
> As the audio comes in to drive, the stream itself needs to be encrypted to
> be made tamper-proof, not just read-only. If anyone does as much as change a
> meta value or cut a sample, it must ring alarm bells. (It's a
> security/evidence thing)
>
> I'm not getting far on google with this, have you been here before?
>
> --
> dE|_
>
>

The stream itself does not require encryption, unless privacy is required.
Instead, blocks of audio (or the entire recording) have a hash (eg
SHA-256) created from it and then the hash is encrypted to prevent
tampering.
It is the hash (encrypted digital signature of the recording) which
provides a 'fingerprint' of the recording.
The trick is the manangement of the encryption keys, since whoever
possesses the means to decrypt the hash could conceivably create a new
one to sign a new, tampered, audio file.

[Sean Conolly]

"Richard Crowley" > wrote in message
...
> "dE|_" wrote ...
>> Can anyone give me a lead for this; As the audio comes in to drive, the
>> stream itself needs to be encrypted to be made tamper-proof,
>
> Encryption does NOT imply "tamper-proof".

Depends on the encryption used. PPK encryption is used to both protect the
data from both unauthorized viewing and from tampering. There are two keys
used - data encoded with either key can only be decoded with the other key.
If you can decode the data with the public (i.e. distributed) key you are
assured that the data has not been tampered with since it was last encoded
using the private key.

The data then becomes as secure as the private key used at the source end.
If it is truly secured then you can trust that the data was encoded at the
source.

Sean

[Richard Crowley]

"Sean Conolly" wrote ...
> The data then becomes as secure as the private key used

Do you know what the letters "NSA" stand for? :-)

[Arkansan Raider]

Richard Crowley wrote:
> "Sean Conolly" wrote ...
>> The data then becomes as secure as the private key used
>
> Do you know what the letters "NSA" stand for? :-)
>
>

No Such Agency.

<g>


---Jeff

[dE|_]

"Richard Crowley" > wrote in message
. ..
> "Sean Conolly" wrote ...
>> The data then becomes as secure as the private key used
>
> Do you know what the letters "NSA" stand for? :-)

Numpty Space Association?

[dE|_]

"Sean Conolly" wrote in message
> ...
>> "dE|_" wrote ...
>>> Can anyone give me a lead for this; As the audio comes in to drive, the
>>> stream itself needs to be encrypted to be made tamper-proof,
>>
>> Encryption does NOT imply "tamper-proof".
>
> Depends on the encryption used. PPK encryption is used to both protect the
> data from both unauthorized viewing and from tampering. There are two keys
> used - data encoded with either key can only be decoded with the other
> key. If you can decode the data with the public (i.e. distributed) key you
> are assured that the data has not been tampered with since it was last
> encoded using the private key.
>
> The data then becomes as secure as the private key used at the source end.
> If it is truly secured then you can trust that the data was encoded at the
> source.

That's one for me to look into. If the public decryption key is held by the
courts then that has a similar effect as my current plan. I am assuming that
the first encryption key will still allow playback but not editing?

The staff still need to have access to playback, which then pulls up that
old doubt of whether the audio has just been played back analogue to another
editor, tampered with, then played back again into the secure recorder. That
is the ultimate wall to climb. Don't get me wrong I'm not not trying to pull
your efforts apart I'm just playing lawyer's advocate ;-)

--
dE|_

[John Williamson]

dE|_ wrote:
> "Sean Conolly" wrote in message
>> ...
>>> "dE|_" wrote ...
>>>> Can anyone give me a lead for this; As the audio comes in to drive, the
>>>> stream itself needs to be encrypted to be made tamper-proof,
>>> Encryption does NOT imply "tamper-proof".
>> Depends on the encryption used. PPK encryption is used to both protect the
>> data from both unauthorized viewing and from tampering. There are two keys
>> used - data encoded with either key can only be decoded with the other
>> key. If you can decode the data with the public (i.e. distributed) key you
>> are assured that the data has not been tampered with since it was last
>> encoded using the private key.
>>
>> The data then becomes as secure as the private key used at the source end.
>> If it is truly secured then you can trust that the data was encoded at the
>> source.
>
> That's one for me to look into. If the public decryption key is held by the
> courts then that has a similar effect as my current plan. I am assuming that
> the first encryption key will still allow playback but not editing?
>
> The staff still need to have access to playback, which then pulls up that
> old doubt of whether the audio has just been played back analogue to another
> editor, tampered with, then played back again into the secure recorder. That
> is the ultimate wall to climb. Don't get me wrong I'm not not trying to pull
> your efforts apart I'm just playing lawyer's advocate ;-)
>
Split the streams, with one branch going to a secure server for later
use in court, the other to an accessible server for routine monitoring.

I'm assuming the playback for the staff doesn't need to be secure,
although it'll not be too hard to arrange a duplicate secure stream
using a different pair of keys.

It's possible to find a way round *any* scheme, though, if the incentive
is high enough.

--
Tciao for Now!

John.

[Swanny[_2_]]

dE|_ wrote:
> "Sean Conolly" wrote in message
>> ...
>>> "dE|_" wrote ...
>>>> Can anyone give me a lead for this; As the audio comes in to drive, the
>>>> stream itself needs to be encrypted to be made tamper-proof,
>>> Encryption does NOT imply "tamper-proof".
>> Depends on the encryption used. PPK encryption is used to both protect the
>> data from both unauthorized viewing and from tampering. There are two keys
>> used - data encoded with either key can only be decoded with the other
>> key. If you can decode the data with the public (i.e. distributed) key you
>> are assured that the data has not been tampered with since it was last
>> encoded using the private key.
>>
>> The data then becomes as secure as the private key used at the source end.
>> If it is truly secured then you can trust that the data was encoded at the
>> source.
>
> That's one for me to look into. If the public decryption key is held by the
> courts then that has a similar effect as my current plan. I am assuming that
> the first encryption key will still allow playback but not editing?
>
> The staff still need to have access to playback, which then pulls up that
> old doubt of whether the audio has just been played back analogue to another
> editor, tampered with, then played back again into the secure recorder. That
> is the ultimate wall to climb. Don't get me wrong I'm not not trying to pull
> your efforts apart I'm just playing lawyer's advocate ;-)
>
> --
> dE|_
>
>

Unless there's a privacy issue, you don't need to encrypt the audio. It
just needs to be signed, using a hash and encryption so that the
signature can be verified and authenticated. Once the signature can be
authenticated then it can be matched against the signature of the audio
to determine whether it has been tampered or not.

[Sean Conolly]

"Richard Crowley" > wrote in message
. ..
> "Sean Conolly" wrote ...
>> The data then becomes as secure as the private key used
>
> Do you know what the letters "NSA" stand for? :-)

My mother was a mathmatician for them back in the 60's, coincidentally :-)

We don't care if the NSA can crack keys - it just needs to be beyond the
means of anyone with a motive. Try cracking a 4096 bit key on your home PC.

Sean

[Sean Conolly]

"Swanny" > wrote in message
...
> Unless there's a privacy issue, you don't need to encrypt the audio. It
> just needs to be signed, using a hash and encryption so that the
> signature can be verified and authenticated. Once the signature can be
> authenticated then it can be matched against the signature of the audio
> to determine whether it has been tampered or not.

Personally, I think there's merit to have the encrypted because it becomes
completely unusable if modifed. Then it's not an issue of whether the audio
can be trusted, if there's audio at all it can be trusted.

Plus (thinking as a developer here) I'd probably do this in packets, with
each packet having at least a sequence number and timestamp. Enrypt the
whole packet to hide the underlying data structure making it that much
harder to tanper with. If nothing is exposed it's much harder to crack.

Sean

[dE|_]

"Sean Conolly" > wrote in message
...
> "Swanny" > wrote in message
> ...
>> Unless there's a privacy issue, you don't need to encrypt the audio. It
>> just needs to be signed, using a hash and encryption so that the
>> signature can be verified and authenticated. Once the signature can be
>> authenticated then it can be matched against the signature of the audio
>> to determine whether it has been tampered or not.
>
> Personally, I think there's merit to have the encrypted because it becomes
> completely unusable if modifed. Then it's not an issue of whether the
> audio can be trusted, if there's audio at all it can be trusted.
>
> Plus (thinking as a developer here) I'd probably do this in packets, with
> each packet having at least a sequence number and timestamp. Enrypt the
> whole packet to hide the underlying data structure making it that much
> harder to tanper with. If nothing is exposed it's much harder to crack.

I'm going to go with 3 simultaneous copies of recordings.
1. Goes PPK fully encrypted to court Archive via VPN
2. Gets saved local as .TRC file by Cedar machine, available for all to ref.
3. Gets archived local as PPK fully encrypted, secure server with access to
head of office only to check date stamping etc.

--
dE|_