[resolved] Re: Encrypt & decrypt blobs
Keisuke, Thanks using UTF-8 text without length resolved the extra 2 nulls being appended. Chip On Fri, 19 Apr 2019 23:26:38 +, Keisuke Miyako via 4D_Tech wrote: > I wouldn't convert the text to MacRoman, max 32,000 bytes (i.e. v2004 > format) text > risking data loss - even if the possibility was minimal with small US > ASCII - just to be safe (and fast). > > TEXT TO BLOB($Text_Ptr->;$Blob;Mac text without length) > $Destination->:=BLOB to text($Blob;Mac text without length) > > either specify UTF-8 which has no length limit or data loss, > or even better, VARIABLE TO BLOB which does no conversion at all. > > but I can not say how the 0x00 terminator was introduced, > whether by OpenSSL which does the encryption or the BLOB/TEXT > conversion done by 4D. > > > > ** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ** --- Gas is for washing parts Alcohol is for drinkin' Nitromethane is for racing ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Encrypt & decrypt blobs
Peter, I found it because the encrypted data is a password. and "ABCDEFG" is not equal to "ABCDEFG(null)(null)" Chip > Chip, > > How you found that text is 2 bytes longer? If you wrote the text to > file, 4D would put BOM before text, which is 2 bytes. Normally, BOM > is used by text editors and is not displayed, to check if there is > BOM prepended I had to use hex editor and look at the file. > > While most text editors know what to do with BOM, I have run into > programs where that caused problems. > > Regards, > > Peter Bozek > > On Sat, Apr 20, 2019 at 12:14 AM Chip Scheide via 4D_Tech > <4d_tech@lists.4d.com> wrote: >> I am putting text into a blob >> TEXT TO BLOB($Text_Ptr->;$Blob;Mac text without length) >> I encrypt the blob >> ENCRYPT BLOB($Blob;$Private_Key) >> >> I later extract this text >> DECRYPT BLOB($Blob;$Public_Key) >> $Destination->:=BLOB to text($Blob;Mac text without length) >> >> The text is extracted - and APPEARS to be the same, however >> the length of the extracted text is 2 characters longer then the >> original text. >> The extra 2 characters are: >> Character code = 0 >> And are appended to end of the extracted text. >> >> Anyone have an Idea?? >> >> Thanks >> Chip >> --- >> Gas is for washing parts >> Alcohol is for drinkin' >> Nitromethane is for racing >> ** >> 4D Internet Users Group (4D iNUG) >> Archive: http://lists.4d.com/archives.html >> Options: https://lists.4d.com/mailman/options/4d_tech >> Unsub: mailto:4d_tech-unsubscr...@lists.4d.com >> ** Hell is other people Jean-Paul Sartre ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Encrypt & decrypt blobs
Chip, How you found that text is 2 bytes longer? If you wrote the text to file, 4D would put BOM before text, which is 2 bytes. Normally, BOM is used by text editors and is not displayed, to check if there is BOM prepended I had to use hex editor and look at the file. While most text editors know what to do with BOM, I have run into programs where that caused problems. Regards, Peter Bozek On Sat, Apr 20, 2019 at 12:14 AM Chip Scheide via 4D_Tech < 4d_tech@lists.4d.com> wrote: > I am putting text into a blob > TEXT TO BLOB($Text_Ptr->;$Blob;Mac text without length) > I encrypt the blob > ENCRYPT BLOB($Blob;$Private_Key) > > I later extract this text > DECRYPT BLOB($Blob;$Public_Key) > $Destination->:=BLOB to text($Blob;Mac text without length) > > The text is extracted - and APPEARS to be the same, however > the length of the extracted text is 2 characters longer then the > original text. > The extra 2 characters are: > Character code = 0 > And are appended to end of the extracted text. > > Anyone have an Idea?? > > Thanks > Chip > --- > Gas is for washing parts > Alcohol is for drinkin' > Nitromethane is for racing > ** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ** -- -- Peter Bozek ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Encrypt & decrypt blobs
Keisuke, Thanks. I'll try on Monday. The text will likely never be more than 100 characters, so length is not really an issue. I did some quick testing - and it must be the encrypt/decrypt process, and Text to blob -> blob to text did not add the extra characters. Also - I will have to check the docs, but the text is a field rather then a variable, so I do not know if Variable to blob work in that situation. I could create a local text copy and then Variable to Blob... Chip > I wouldn't convert the text to MacRoman, max 32,000 bytes (i.e. v2004 > format) text > risking data loss - even if the possibility was minimal with small US > ASCII - just to be safe (and fast). > > TEXT TO BLOB($Text_Ptr->;$Blob;Mac text without length) > $Destination->:=BLOB to text($Blob;Mac text without length) > > either specify UTF-8 which has no length limit or data loss, > or even better, VARIABLE TO BLOB which does no conversion at all. > > but I can not say how the 0x00 terminator was introduced, > whether by OpenSSL which does the encryption or the BLOB/TEXT > conversion done by 4D. > > > > ** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ** Hell is other people Jean-Paul Sartre ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Encrypt & decrypt blobs
I wouldn't convert the text to MacRoman, max 32,000 bytes (i.e. v2004 format) text risking data loss - even if the possibility was minimal with small US ASCII - just to be safe (and fast). TEXT TO BLOB($Text_Ptr->;$Blob;Mac text without length) $Destination->:=BLOB to text($Blob;Mac text without length) either specify UTF-8 which has no length limit or data loss, or even better, VARIABLE TO BLOB which does no conversion at all. but I can not say how the 0x00 terminator was introduced, whether by OpenSSL which does the encryption or the BLOB/TEXT conversion done by 4D. ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Encrypt & decrypt blobs
I am putting text into a blob TEXT TO BLOB($Text_Ptr->;$Blob;Mac text without length) I encrypt the blob ENCRYPT BLOB($Blob;$Private_Key) I later extract this text DECRYPT BLOB($Blob;$Public_Key) $Destination->:=BLOB to text($Blob;Mac text without length) The text is extracted - and APPEARS to be the same, however the length of the extracted text is 2 characters longer then the original text. The extra 2 characters are: Character code = 0 And are appended to end of the extracted text. Anyone have an Idea?? Thanks Chip --- Gas is for washing parts Alcohol is for drinkin' Nitromethane is for racing ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
