+ Post New Thread
Results 1 to 7 of 7
  1. #1
    Member level 2
    Points: 866, Level: 6

    Join Date
    Mar 2015
    Posts
    48
    Helped
    1 / 1
    Points
    866
    Level
    6

    [moved] appropriate algorithm for video encryption

    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?

    •   AltAdvertisment

        
       

  2. #2
    Super Moderator
    Points: 29,306, Level: 41
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    6,770
    Helped
    1608 / 1608
    Points
    29,306
    Level
    41

    Re: [moved] appropriate algorithm for video encryption

    Well you could use the lightweight encryption that was brought up in a recent post https://www.edaboard.com/showthread....l-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.


    1 members found this post helpful.

    •   AltAdvertisment

        
       

  3. #3
    Member level 3
    Points: 491, Level: 4

    Join Date
    Dec 2017
    Location
    Bydgoszcz - Poland
    Posts
    62
    Helped
    11 / 11
    Points
    491
    Level
    4

    Re: [moved] appropriate algorithm for video encryption

    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


    1 members found this post helpful.

    •   AltAdvertisment

        
       

  4. #4
    Advanced Member level 3
    Points: 5,515, Level: 17

    Join Date
    Feb 2015
    Posts
    914
    Helped
    263 / 263
    Points
    5,515
    Level
    17

    Re: [moved] appropriate algorithm for video encryption

    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.


    1 members found this post helpful.

  5. #5
    Member level 2
    Points: 866, Level: 6

    Join Date
    Mar 2015
    Posts
    48
    Helped
    1 / 1
    Points
    866
    Level
    6

    Re: [moved] appropriate algorithm for video encryption

    Well you could use the lightweight encryption that was brought up in a recent post https://www.edaboard.com/showthread....l-cryptography, 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.



  6. #6
    Super Moderator
    Points: 27,654, Level: 40
    andre_teprom's Avatar
    Join Date
    Nov 2006
    Location
    Brazil
    Posts
    8,253
    Helped
    1045 / 1045
    Points
    27,654
    Level
    40
    Blog Entries
    5

    Re: [moved] appropriate algorithm for video encryption

    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.
    --------------------------------------------------------------------------------------------------
    Part of the world that you live in, You are the part that you're giving ( Renaissance )



    •   AltAdvertisment

        
       

  7. #7
    Advanced Member level 3
    Points: 5,515, Level: 17

    Join Date
    Feb 2015
    Posts
    914
    Helped
    263 / 263
    Points
    5,515
    Level
    17

    Re: [moved] appropriate algorithm for video encryption

    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 by vGoodtimes; 16th June 2018 at 07:59.



--[[ ]]--