Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[moved] appropriate algorithm for video encryption

Status
Not open for further replies.

amin5659

Member level 3
Joined
Mar 28, 2015
Messages
55
Helped
1
Reputation
2
Reaction score
1
Trophy points
8
Activity points
522
hi every one. I wanna to encrypt stream full-HD video with FPGA. can anyone suggest me an efficient FPGA algorithm with easy or medium level of hardness?
:-D
 

Well you could use the lightweight encryption that was brought up in a recent post https://www.edaboard.com/showthread.php?377986-key-scheduling-present-80-vhdl-cryptography, which looks interesting for simple hardening of data. From what the paper discusses the whole idea was to design a robust but computationally light algorithm to use on low end processing engines. I don't consider an FPGA a low end processing device, but that is your requirement and is probably there due to the amount of data you will need to encrypt/decrypt to support full-HD.
 
Hello,

on opencores.org in section projects -> "Crypt core" you have for choose more than forty projects:

https://opencores.org/projects

I used in one of my project AES with 256 bit key (I needed strong encryption), but it is up to you.

Regards
 
This depends on your attack surface. There is a guideline to avoid writing your own crypto. This is because side-channel attacks are a thing. Your implementation cannot use more or less power/time when any bit of the key is correct vs incorrect. Well, this can also applies to bit pairs, and bit tuples.

But if you don't care and just want money, sure, just use whatever cores are out there. You're probably going to assume crypto solves other problems that it doesn't and your product will just be "secure-ish" and any issue will be not your problem.

In short, real crypto is weird. advertisement-crypto is easy.
 
Well you could use the lightweight encryption that was brought up in a recent post, which looks interesting for simple hardening of data.
I think this is too easy! Actually i'm looking for an algorithm that is specific to the video encryption.
I used in one of my project AES with 256 bit key (I needed strong encryption), but it is up to you.
AES works for me but i think it's too much! can i use this core to encrypt full bandwidth of 100Mbit Ethernet Data in spartan3? and is this algorithm works for video?(I mean is this a typical algorithm for video encryption??) as i said i want to know is there any efficient algorithm with almost strong encryption that is specific to the video encryption.
This is because side-channel attacks are a thing
Yes you are right.
The algorithm has to be one-way and the encryption keys will update permanently. I think RSA-64 bit is good one. but is this good for video?

the algorithm's that are based in changing pixel's location don't work for me because far example if some one just sniff the encrypted data he probably could gain information about the encrypted video.
 

You are perhaps referring not to an encryption algorithm, but rather to a lossless image compression algorithm, which is more often referred to as a video codec.
 

100mbps is fairly low rate. aes-gcm and chacha20-poly1305 should both be easy enough for an s3. you would still need some initial slow crypto for the key exchange. But you can write a multi-cycle processor for that.

i'm not familiar with rsa-64. rsa has never been 64 bit. 64 bit rsa would have been unacceptable 40 years ago.

If you need to do a full async encryption on a big message, well, good luck with that. There is a reason the sync key is encrypted with the async encryption and then the bulk data uses the faster method.

--edit:

you'll not likely find any legitimate encryption algorithms for video. The closest I can think is "don't use non-auth'd stream-encryption." That is only because of the mutable properties of stream ciphers. app-specific encryption is probably not a thing to trust. It implies a weaker attack model than traditional encryption and I would suspect is held to much lower standards.
 
Last edited:

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top