Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > padding zeros in char *

Reply
Thread Tools

padding zeros in char *

 
 
Martin Ambuhl
Guest
Posts: n/a
 
      10-10-2005
Keith Thompson wrote:
> Martin Ambuhl <(E-Mail Removed)> writes:
>
>>Joe Wright wrote:


>>>How about '0' bytes instead of '\0' bytes?

>>
>>What earthly difference could that make?
>>[Ans: none.]

>
>
> Presumably the difference is that padding with '0' bytes won't work.
> According to the OP, the AES_decrypt requires the last block to be
> padded with '\0' bytes.


Silly me. I read Joe's suggestion as "0 bytes instead of '\0' bytes,"
which of course would make no difference. This sort of reading failure
is why debugging is sometimes difficult. My response was obviously
wrong: the difference that Joe's suggestion makes is that it guarantees
failure.

 
Reply With Quote
 
 
 
 
Joe Wright
Guest
Posts: n/a
 
      10-11-2005
Keith Thompson wrote:
> Martin Ambuhl <(E-Mail Removed)> writes:
>
>>Joe Wright wrote:
>>
>>>(E-Mail Removed) wrote:

>>
>>>>Again, my problem is NOT the AES_decrypt(). My problem is padding the
>>>>input with trailing \0 bytes.
>>>>
>>>
>>>How about '0' bytes instead of '\0' bytes?

>>
>>What earthly difference could that make?
>>[Ans: none.]

>
>
> Presumably the difference is that padding with '0' bytes won't work.
> According to the OP, the AES_decrypt requires the last block to be
> padded with '\0' bytes.
>
> Joe, what did you have in mind?
>

The problem seems to be that OP needs 16-byte strings. Clearly an
arbitrarily placed '\0' may shorten the string. Padding with '0'
characters will solve length problem.

The OP may be mis-reading the requirement. Demanding 16-byte strings and
padding with '\0' doesn't make sense.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      10-11-2005
Joe Wright <(E-Mail Removed)> writes:
> Keith Thompson wrote:
>> Martin Ambuhl <(E-Mail Removed)> writes:
>>
>>>Joe Wright wrote:
>>>
>>>>(E-Mail Removed) wrote:
>>>
>>>>>Again, my problem is NOT the AES_decrypt(). My problem is padding the
>>>>>input with trailing \0 bytes.
>>>>>
>>>>
>>>>How about '0' bytes instead of '\0' bytes?
>>>
>>>What earthly difference could that make?
>>>[Ans: none.]

>> Presumably the difference is that padding with '0' bytes won't work.
>> According to the OP, the AES_decrypt requires the last block to be
>> padded with '\0' bytes.
>> Joe, what did you have in mind?
>>

> The problem seems to be that OP needs 16-byte strings. Clearly an
> arbitrarily placed '\0' may shorten the string. Padding with '0'
> characters will solve length problem.
>
> The OP may be mis-reading the requirement. Demanding 16-byte strings
> and padding with '\0' doesn't make sense.


I strongly suspect that AES_decrypt() requires 16-byte character
arrays, not strings (at least not the way C defines the term
"string"). Padding a character array with '\0' does make sense; in
fact, this may be one of the few good uses for strncpy().

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      10-11-2005
Keith Thompson wrote:
>
> I strongly suspect that AES_decrypt() requires 16-byte character
> arrays, not strings (at least not the way C defines the term
> "string"). Padding a character array with '\0' does make sense; in
> fact, this may be one of the few good uses for strncpy().


Unlikely, as strncpy() will stop reading the source when it
encounters the first '\0' character. I gather from the thread
that the source may contain multiple '\0' characters at
various points.

 
Reply With Quote
 
Joe Wright
Guest
Posts: n/a
 
      10-11-2005
Keith Thompson wrote:
> Joe Wright <(E-Mail Removed)> writes:
>
>>Keith Thompson wrote:
>>
>>>Martin Ambuhl <(E-Mail Removed)> writes:
>>>
>>>
>>>>Joe Wright wrote:
>>>>
>>>>
>>>>>(E-Mail Removed) wrote:
>>>>
>>>>>>Again, my problem is NOT the AES_decrypt(). My problem is padding the
>>>>>>input with trailing \0 bytes.
>>>>>>
>>>>>
>>>>>How about '0' bytes instead of '\0' bytes?
>>>>
>>>>What earthly difference could that make?
>>>>[Ans: none.]
>>>
>>>Presumably the difference is that padding with '0' bytes won't work.
>>>According to the OP, the AES_decrypt requires the last block to be
>>>padded with '\0' bytes.
>>>Joe, what did you have in mind?
>>>

>>
>>The problem seems to be that OP needs 16-byte strings. Clearly an
>>arbitrarily placed '\0' may shorten the string. Padding with '0'
>>characters will solve length problem.
>>
>>The OP may be mis-reading the requirement. Demanding 16-byte strings
>>and padding with '\0' doesn't make sense.

>
>
> I strongly suspect that AES_decrypt() requires 16-byte character
> arrays, not strings (at least not the way C defines the term
> "string"). Padding a character array with '\0' does make sense; in
> fact, this may be one of the few good uses for strncpy().
>


Go for it. Your suspicion is every bit as good as mine. I have no idea
of AES_decrypt() and what it requires. I hope I haven't reduced the S/N
too much.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-11-2005
"Old Wolf" <(E-Mail Removed)> writes:
> Keith Thompson wrote:
>> I strongly suspect that AES_decrypt() requires 16-byte character
>> arrays, not strings (at least not the way C defines the term
>> "string"). Padding a character array with '\0' does make sense; in
>> fact, this may be one of the few good uses for strncpy().

>
> Unlikely, as strncpy() will stop reading the source when it
> encounters the first '\0' character. I gather from the thread
> that the source may contain multiple '\0' characters at
> various points.


Good point.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Michael Wojcik
Guest
Posts: n/a
 
      10-11-2005

In article <(E-Mail Removed)>, Keith Thompson <(E-Mail Removed)> writes:
> Joe Wright <(E-Mail Removed)> writes:
> > Keith Thompson wrote:
> >> Martin Ambuhl <(E-Mail Removed)> writes:
> >>
> >>>Joe Wright wrote:
> >>>
> >>>>(E-Mail Removed) wrote:
> >>>
> >>>>>Again, my problem is NOT the AES_decrypt(). My problem is padding the
> >>>>>input with trailing \0 bytes.
> >>>>
> >>>>How about '0' bytes instead of '\0' bytes?
> >>

> > The problem seems to be that OP needs 16-byte strings.


Unfortunately, the problem is that OP needs to be operating on
contiguous sequences of 128 bits, and not strings at all (as defined
by C).

> > Clearly an
> > arbitrarily placed '\0' may shorten the string. Padding with '0'
> > characters will solve length problem.
> >
> > The OP may be mis-reading the requirement. Demanding 16-byte strings
> > and padding with '\0' doesn't make sense.


Yes, but not in the way that your suggestion corrects, unfortunately.

> I strongly suspect that AES_decrypt() requires 16-byte character
> arrays, not strings (at least not the way C defines the term
> "string").


More precisely, it requires 128 bits of ciphertext, and not strings
at all.

> Padding a character array with '\0' does make sense; in
> fact, this may be one of the few good uses for strncpy().


I think strncpy's the wrong approach here. Even where CHAR_BIT is 8,
using strncpy implies that the function operates on strings, which is
not true.

The OP should be passing AES_decrypt a buffer of 128 bits of
ciphertext. If fewer than 128 bits of ciphertext remain, the buffer
should be padded at the end with zero bits. memset and memcpy are
the appropriate functions to use here; if it's necessary to support
platforms where CHAR_BIT is not 8, the code will need to use bit
operations as well, since AES is an octet-granular encoding.

--
Michael Wojcik (E-Mail Removed)

Recently, they appeared at the reopening of the Brookdale Library,
luring passersby with the opportunity to be anonymously silly.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Padding bits and char, unsigned char, signed char Ioannis Vranos C Programming 6 03-29-2008 10:55 AM
Padding bits and char, unsigned char, signed char Ioannis Vranos C++ 11 03-28-2008 10:47 PM
(const char *cp) and (char *p) are consistent type, (const char **cpp) and (char **pp) are not consistent lovecreatesbeauty C Programming 1 05-09-2006 08:01 AM
/usr/bin/ld: ../../dist/lib/libjsdombase_s.a(BlockGrouper.o)(.text+0x98): unresolvable relocation against symbol `std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostre silverburgh.meryl@gmail.com C++ 3 03-09-2006 12:14 AM
Number padding... (trailing zeros'.) ThePotPlants Perl Misc 4 05-23-2004 10:19 PM



Advertisments